RAISE paper ranks OSS-Fuzz project-days for extra fuzzing
Original title: Raise or Check? Predicting the Necessity of Additional Fuzzing for Continuous Fuzzing
A Random Forest reached ROC-AUC 0.74, and Simple-Regression used 91.60 extra sessions per detected vulnerability versus 171.89 for a median heuristic.
Researchers propose RAISE, a just-in-time framework that estimates whether a vulnerability is introduced on a given project-day so continuous fuzzing can spend more time on higher-risk days. The dataset joins OSV vulnerability-introducing commits with OSS-Fuzz coverage and change metrics for 15 C/C++ projects and 15,210 project-days, 347 of them vulnerability-introducing. In cross-project validation, a Random Forest using VCCFinder-style static features and dynamic fuzzing features beat a random baseline, with PatchCoverage the leading feature. A simulation over 968 vulnerabilities found Simple-Regression more cost-efficient than prediction-agnostic heuristics.
- Google's OSS-Fuzz is described as fuzzing over 1,300 projects and finding more than 10,000 vulnerabilities.
- Only 2.28 percent of the 15,210 project-days were vulnerability-introducing.
- Best reported ROC-AUC was 0.74 for the combined Random Forest.
- Simple-Regression spent roughly half the extra fuzzing sessions of the Median heuristic.
From the original article
1 min read at arxiv.orgContinuous fuzzing is used for vulnerability detection in Open Source Software (OSS). Large-scale services such as Google's OSS-Fuzz fuzz over 1,300 projects and have revealed more than 10,000 vulnerabilities. Despite this, a considerable time lag often exists between when a vulnerability is introduced and when it is detected (i.
By Riku Kato · arxiv.org
A short excerpt; the article and its images belong to the publisher. Summary, key facts and assessment above are AI-written from the article and can be wrong.