Continuous fuzzing has become a standard tool for finding vulnerabilities in open-source software. The scale of this practice is large: Google's OSS-Fuzz alone has fuzzed more than 1,300 projects and reported over 10,000 vulnerabilities. But running fuzzing indefinitely consumes computing resources, so knowing when to stop or continue matters.
The new arXiv paper, "Raise or Check? Predicting the Necessity of Additional Fuzzing for Continuous Fuzzing," addresses this resource-allocation problem. Rather than fuzzing on a fixed schedule, the authors look at how to predict whether an additional round of fuzzing is likely to yield new findings.
Given the abstract is truncated, the exact methodology is not fully described in the available text. Still, the core motivation is clear: make continuous fuzzing more efficient by avoiding unnecessary runs while not missing vulnerabilities that extra fuzzing would reveal.