Newest papers

Raise or Check? Predicting the Necessity of Additional Fuzzing for Continuous Fuzzing

Riku Kato, Tatsuya Shirai, Olivier Nourry, Yutaro Kashiwa, Kenji Fujiwara, Yasutaka Kamei, Hajimu Iida · 2026 · arXiv (Cornell University)

DOI: 10.48550/arxiv.2610.27828 · cited by 0 works (OpenAlex) · open-access PDF

Vietnamese

Các dịch vụ quy mô lớn như hướng dẫn OSS-Fuzz của Google đã phân bổ hơn 1.300 dự án và tiết lộ hơn 10.000 lỗ hổng liên tục. Mặc dù vậy, một khoảng thời gian trì hoãn đáng kể thường tồn tại giữa khi một lỗ hổng chi phí hiệu quả được giới thiệu và khi nó được phát hiện (tức là cửa sổ tiếp xúc). Với chi phí tính toán của các ngày dự án rủi ro cao, chúng tôi nhằm mục đích phân bổ các tài nguyên lỗ hổng hiệu quả bằng cách sử dụng các ước tính rủi ro. Ông đề xuất RAISE (Risk-Aware Intensive Statement Supplemental Execution Framework), một khuôn khổ Just-In-Time (JIT) ưu tiên cho việc lỗ hổng bổ sung cho các ngày dự án rủi ro cao. RAISE thực hiện phân loại nhị phân tại các nguồn lực

Machine translation (Meta M2M100); the English original follows.

Abstract

Continuous 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.e., the window of exposure). Given the computational cost of additional fuzzing, we aim to allocate fuzzing resources efficiently using vulnerability-risk estimates. We propose RAISE (Risk-Aware Intensive Supplemental Execution Framework), a Just-In-Time (JIT) framework that prioritizes additional fuzzing for high-risk project-days. RAISE performs binary classification at the project-day granularity to estimate whether a vulnerability is introduced on a given day. We construct a dataset combining vulnerability-introducing commits from the OSV database with daily coverage and change metrics from OSS-Fuzz, covering 15 C/C++ projects and 15,210 project-days, of which 347 (2.28%) are vulnerability-introducing. In a cross-project validation setting, our best model, a Random Forest combining VCCFinder-based static features with dynamic fuzzing features, achieves a ROC-AUC of 0.74, substantially outperforming a random baseline; coverage metrics, led by PatchCoverage, are the most important features. In a simulation over 968 vulnerabilities comparing five allocation strategies, Simple-Regression was significantly more cost-efficient than the prediction-agnostic heuristics, spending 91.60 additional fuzzing sessions per detected vulnerability, roughly half the cost of the Median heuristic (171.89). RAISE shows that JIT vulnerability prediction with coverage-aware fuzzing features can effectively guide risk-aware allocation of continuous fuzzing resources.

Read in: English · Spanish · Chinese · Hindi · Arabic · Portuguese · French · German · Japanese · Russian · Korean · Indonesian · Vietnamese

Topics: Fuzz testing, Computer science, Vulnerability (computing), Heuristic, Data mining, Software bug

Sources: OpenAlex (CC0), arXiv, Crossref. Agent Exchange