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

arXiv:2610.27828v1 [cs.SE] 20 Oct 2026

Raise or Check? Predicting the Necessity of Additional Fuzzing for Continuous Fuzzing RIKU KATO, Nara Institute of Science and Technology, Japan TATSUYA SHIRAI, Nara Institute of Science and Technology, Japan OLIVIER NOURRY, The University of Osaka, Japan YUTARO KASHIWA, Nara Institute of Science and Technology, Japan KENJI FUJIWARA, Nara Women’s University, Japan YASUTAKA KAMEI, Kyushu University, Japan HAJIMU IIDA, Nara Institute of Science and Technology, Japan 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 the widespread adoption of continuous fuzzing, 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 by 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 project-days (2.28%) are labeled as vulnerability-introducing. We evaluate RAISE in a cross-project validation setting and use a simulation framework to compare five strategies for allocating additional fuzzing sessions. Our best model, a Random Forest classifier combining VCCFinder-based static features with dynamic fuzzing features, achieves a ROC-AUC of 0.74, substantially outperforming a random baseline. Coverage metrics receive the highest importance scores, with PatchCoverage ranking first. In a simulation over 968 vulnerabilities, the Simple-Regression strategy 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 sessions). RAISE demonstrates that JIT vulnerability prediction augmented with coverage-aware fuzzing features can effectively guide risk-aware allocation of continuous fuzzing resources, enabling more efficient use of computation in large-scale OSS fuzzing environments. CCS Concepts: • Software and its engineering → Maintaining software; • Security and privacy → Software security engineering. Additional Key Words and Phrases: Just-In-Time Vulnerability Detection, Security, Fuzzing Authors’ Contact Information: Riku Kato, Nara Institute of Science and Technology, Ikoma, Japan, kato.riku.ks5@naist.ac.jp; Tatsuya Shirai, Nara Institute of Science and Technology, Ikoma, Japan, shirai.tatsuya.sp1@naist.ac.jp; Olivier Nourry, The University of Osaka, Suita, Japan, nourry@ist.osaka-u.ac.jp; Yutaro Kashiwa, Nara Institute of Science and Technology, Ikoma, Japan, yutaro.kashiwa@is.naist.jp; Kenji Fujiwara, Nara Women’s University, Nara, Japan, kenjif@ics.nara-wu.ac.jp; Yasutaka Kamei, Kyushu University, Fukuoka, Japan, kamei@ait.kyushu-u.ac.jp; Hajimu Iida, Nara Institute of Science and Technology, Ikoma, Japan, iida@naist.ac.jp. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from permissions@acm.org. © 2026 Copyright held by the owner/author(s). Publication rights licensed to ACM. ACM XXXX-XXXX/2026/10-ART https://doi.org/10.1145/nnnnnnn.nnnnnnn , Vol. 1, No. 1, Article . Publication date: October 2026.

2

Kato et al.

ACM Reference Format: Riku Kato, Tatsuya Shirai, Olivier Nourry, Yutaro Kashiwa, Kenji Fujiwara, Yasutaka Kamei, and Hajimu Iida. 2026. Raise or Check? Predicting the Necessity of Additional Fuzzing for Continuous Fuzzing. 1, 1 (October 2026), 23 pages. https://doi.org/10.1145/nnnnnnn.nnnnnnn

1

Introduction

Numerous large-scale security incidents have recently exploited vulnerabilities in Open Source Software (OSS), including well-known cases such as Heartbleed [34] and RegreSSHion [35]. In modern software development, OSS components are extensively reused across a wide range of software projects, including other OSS projects, thereby amplifying the potential impact of software vulnerabilities. Early identification of vulnerabilities prior to their exploitation is therefore an essential aspect of software security maintenance. Among the various techniques proposed for vulnerability detection, fuzz testing (or fuzzing) has emerged as a particularly promising approach in recent literature [1, 25, 30]. Fuzzing is a dynamic analysis technique that systematically generates and sends malformed or unexpected data to software systems with the goal of provoking anomalous behaviors such as crashes or exceptions that may indicate underlying security flaws. Cui et al. [11] reported that fuzzing can discover more previously unknown vulnerabilities than other vulnerability discovery techniques, such as static analysis and concolic testing. They also surveyed 57 papers focusing on fuzzing techniques, collected 1,600 confirmed vulnerabilities, and found that 635 (39.7%) of them were assigned Common Vulnerabilities and Exposures (CVE) IDs. Their field survey results also showed that only 13.2% of vulnerabilities detected using static-approaches were later assigned a CVE ID, suggesting that vulnerabilities found via fuzzing are more likely to be assigned a CVE ID. Fuzzing also has its drawbacks. Specifically, it is known to require significant execution time, as it involves generating and executing a large number of inputs against the target software system [3, 38]. To mitigate the drawbacks of traditional fuzzing, continuous fuzzing integrates directly into the CI pipeline, running in short, frequent bursts rather than lengthy sessions. This approach minimizes the delay between code commits and fuzzing results, enabling developers to catch vulnerabilities closer to when they are introduced. Since 2016, Google has been conducting largescale fuzzing through OSS-Fuzz [43], a service that performs continuous fuzzing on OSS to improve security. As of 2023, OSS-Fuzz has targeted over 1,000 projects and discovered more than 10,000 vulnerabilities and 36,000 bugs [16]. Continuous fuzzing, however, does not accelerate the fuzzer’s inherent search process. Therefore, even with continuous fuzzing, significant time may pass between when a vulnerability is introduced and when it is discovered, leaving the code exposed to long-term exploitation. In fact, prior work has reported detection latencies under continuous fuzzing. For example, Keller et al. [23] found that in OSS-Fuzz, the median time from bug introduction to fix was 324 days, despite fixes typically being applied within 2 days of detection. To reduce the risk of exploitation, we should therefore aim to discover vulnerabilities as soon as they are introduced into the code. However, a previous study has shown that discovering bugs and vulnerabilities hidden deep in source code may require exponentially more executions [3] compared to surface-level faults. Although continuous fuzzing may reduce the latency between code changes and bug detection, it does not lessen the expected time-to-detection and computational effort needed to uncover hard-to-reach faults. To guide the allocation of additional fuzzing resources using vulnerability-risk estimates, we propose RAISE (Risk-Aware Intensive Supplemental Execution Framework), a Just-In-Time approach that operates at the day level to match daily build cycles in large-scale fuzzing infrastructures (e.g., OSS-Fuzz). RAISE estimates the risk of each project-day from fuzzing-based dynamic features in addition to the traditional code-change features used in previous studies. While most prior JIT , Vol. 1, No. 1, Article . Publication date: October 2026.

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

3

prediction work stops at predicting whether changes include bugs or vulnerabilities (i.e., binary classification), RAISE uses the estimated risk to decide whether and how much additional fuzzing should be performed. The title borrows two moves from poker: for each project-day, RAISE either checks, keeping the regular fuzzing budget when the estimated risk is low, or raises, allocating additional fuzzing sessions when the risk is high. In this way, fuzzing effort is concentrated on high-risk changes and little is spent on low-risk ones, improving the cost efficiency of vulnerability detection in continuous fuzzing. The main contributions of this research are as follows: (1) Just-In-Time Risk-Aware Resource Allocation for Continuous Fuzzing (RAISE). We develop RAISE, a JIT approach that uses vulnerability-risk estimates to determine whether and how much additional fuzzing should be performed in continuous fuzzing workflows. (2) Fuzzing-Derived Dynamic Features for Vulnerability-Risk Estimation. We introduce the use of fuzzing-derived dynamic features (e.g., PatchCoverage) into vulnerability-risk estimation and prediction. To the best of our knowledge, prior work has not evaluated their use as predictive signals for vulnerability-introducing project-day changes and supplementalfuzzing allocation in continuous-fuzzing environments. We therefore empirically evaluate their added value over established static features. (3) Empirical Evaluation on a Large-scale Continuous-Fuzzing Dataset. We construct a real-world dataset collected from OSS-Fuzz and the OSV, covering 15 C/C++ projects, 15,210 project-days, and 968 vulnerability reports, and use it to evaluate both vulnerability-risk estimation and additional fuzzing resource allocation in continuous fuzzing environments. (4) Optimizing Resource Allocation Strategies for Additional Fuzzing. We simulate five budget-constrained allocation strategies that schedule additional fuzzing on high-risk days. We show that the Simple-Regression strategy is significantly more cost-efficient than the prediction-agnostic heuristics, achieving the lowest pooled cost per vulnerability (91.60 fuzzing sessions). (5) Replication Package for Open Science. To support replication and further studies, we make our data and scripts available in a replication package on GitHub.1 Structure of this paper: Section 2 covers background and related work. Section 3 describes our methodology, and Section 4 details the evaluation setup. Section 5 presents the empirical results. Section 6 discusses threats to validity, and Section 7 concludes the paper. 2

Background and Related Work

This section introduces continuous fuzzing and JIT defect/vulnerability prediction, and reviews related studies. 2.1

Fuzzing and Continuous Fuzzing

In the early 1990s, Miller et al. evaluated 88 programs and found that over 24% crashed when executed with random input strings [31]. In that work, they introduced the concept of fuzzing, an automated approach for generating such inputs. Since then, fuzzing has evolved into a widely adopted technique, with several strategies proposed to improve both source code coverage and input generation. Despite its conceptual simplicity, fuzzing has proven highly effective in uncovering software vulnerabilities, often outperforming traditional static analysis approaches [11]. Although fuzzing is effective for vulnerability detection, it often requires significant computational resources, involves long execution times [3], and poses challenges due to the complexity 1 https://github.com/kr37577/RAISE

, Vol. 1, No. 1, Article . Publication date: October 2026.

4

Kato et al. 4.Fuzz 1.Pull

2.Upload

3.Deploy

5.Report

Issue Report

Target GitHub repository

Builder(Cloud Build)

GCS bucket

ClusterFuzz 6.Analysis

1.Pull

Issue Tracker Well identi ed vulnerability publish to OSV

{} Coverage Report

Con guration

OSS-Fuzz GitHub repository

srcmap Vulnerability Report

Fuzz-introspector

Open source vulnerabilities

Fig. 1. Overview of Fuzzing Process Using OSS-Fuzz

of setting up fuzzing environments [38]. To alleviate these challenges, continuous fuzzing has emerged as a practical approach that integrates fuzzing into continuous integration (CI) workflows. This technique executes short fuzzing sessions either periodically or in batches within CI systems. One of the most popular implementations of continuous fuzzing is OSS-Fuzz. As of August 2025, OSS-Fuzz conducts large-scale continuous fuzzing on 1,320 OSS projects. Figure 1 shows the overview of the fuzzing process with OSS-Fuzz. Based on the target OSS repository and the build configuration stored in the OSS-Fuzz repository, OSS-Fuzz builds each project by default once per day (Step 1). The generated build artifacts are uploaded to cloud storage and utilized for tasks such as identifying regressions (Step 2). As part of this upload step, OSS-Fuzz also generates a metadata file, srcmap.json, for each build. This file maps source directories inside the build container to their corresponding version-control repositories (including the VCS type, repository URL, and commit hash for the main project and its dependencies), and is uploaded to the same cloud storage bucket so that downstream tools can reconstruct the exact project and dependency revisions used in a given fuzzing run. The built projects are then fuzzed using ClusterFuzz, a tool for distributed fuzzing (Step 3, 4). In this process, not only are new fuzzing bugs detected, but previously identified bugs are also verified to ensure they no longer occur. When ClusterFuzz discovers a defect, an issue report is automatically generated and provided to developers (Step 5). The issue report includes information such as the “Project Name”, “Issue Number”, “Detection Date and Time”, and “Fix Date and Time”, in addition to “Regressed range” and “Fixed range”. The Regressed range refers to a set/range of commits that could have introduced the vulnerability, while the Fixed range refers to a set/range of commits in which the fuzzing bug was likely fixed. The Regressed range is estimated using a binary search to identify which commits introduced the code where the vulnerability was detected. Specifically, ClusterFuzz repeatedly rebuilds and runs the minimized reproducer on midpoint revisions between a known non-crashing and crashing revision, halving the interval until it establishes the crashing window. The fixed range is determined similarly by bisecting between a crashing revision and a later non-crashing revision to locate where the reproducer stops crashing. Once a fix is confirmed or 90 days have passed since detection, the fuzzing bug is made public by creating an issue report in the official OSS-Fuzz issue tracker, and the corresponding report is updated. Security bugs detected by OSS-Fuzz are automatically ingested and published as vulnerability entries in the OSV database following a defined disclosure process. In addition, OSS-Fuzz generates coverage reports at the end of each fuzzing session. Fuzz Introspector analyzes these reports by combining dynamic coverage data with static reachability information, after which the reports are published to provide insights such as line, function, and region coverage (Step 6). fi

fi

, Vol. 1, No. 1, Article . Publication date: October 2026.

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

2.2

5

Just-In-Time Defect and Vulnerability Prediction

Defect prediction aims to estimate which parts of a software system are likely to contain defects. Just-In-Time (JIT) defect prediction focuses specifically on code changes and predicts whether a newly committed change is likely to introduce a defect. By making predictions at the time of change, JIT defect prediction can support quality assurance activities by identifying changes that may require additional review or testing. A representative JIT defect prediction model was proposed by Kamei et al. [22]. Their model uses 14 metrics organized into five dimensions: diffusion, size, purpose, history, and developer experience. For example, these metrics capture how widely a change is distributed across files, how many lines are added or deleted, whether the change fixes a defect, and the experience of the developer who made the change. These metrics characterize the risk of a change primarily from its modifications and development history. JIT prediction has also been applied to security-related code changes. VCCFinder [40], for example, predicts vulnerability-contributing commits using not only repository metadata but also information extracted from the contents of code changes. Its features include characteristics such as the number of modified functions, C/C++ keywords appearing in a patch, and textual information from the patch itself. VCCFinder therefore extends change-risk prediction with information about what was actually modified in the source code. This study uses these JIT prediction metrics to estimate vulnerability risk and uses it to determine whether and how much additional fuzzing should be allocated during continuous fuzzing. 2.3

Related Work

2.3.1 Continuous Fuzzing. With the release of OSS-Fuzz, empirical studies on fuzzing and continuous fuzzing have become increasingly popular. Ding et al. [13] analyzed OSS-Fuzz issue reports to investigate the characteristics of detected bugs and their lifecycle. Their findings showed that OSSFuzz discovers most regressions within one week. Keller et al. [23] also investigated the lifecycle of bugs using issue reports from OSS-Fuzz. Their analysis revealed that while the median time from detection to fix was relatively short (around 2 days), the median time from bug introduction to fix was substantially longer, with a median of 324 days. Zhu et al. [54] investigated the characteristics of bugs detected by OSS-Fuzz and found that 77% of the bugs were recently introduced. This indicates that continuous fuzzing is particularly effective at identifying newly introduced faults. Beyond bug detection, researchers have also examined the infrastructure of continuous fuzzing. Görz et al. [17] conducted a large-scale analysis of harness degradation in OSS-Fuzz using harness update information and coverage data. Their study revealed that the average coverage improvement remains marginal at only 0.26%. Nourry et al. [39] analyzed OSS-Fuzz build logs to investigate the nature of build failures in fuzzing. Their study revealed that approximately 9.41% of builds fail. Our work differs by using continuous fuzzing data to detect vulnerabilities in source code changes. 2.3.2 Vulnerability Prediction. Extensive research has been conducted on software vulnerability detection. Russell et al. [42] applied deep representation learning to OSS functions. They showed that vulnerability detection achieves high performance on both the SATE IV benchmark and realworld code by combining CNNs/RNNs with random forests. Zhou et al. [53] focused on capturing semantic features of code structure for function-level vulnerability detection and proposed Devign. By combining a Gated Graph Recurrent Network with a convolutional module, their proposed model achieves over 10% higher accuracy and F1 score than previous methods. Fu et al. [14] proposed LineVul, a Transformer-based approach leveraging CodeBERT. They achieved a 160–379% improvement over existing methods in function-level vulnerability detection and realized a 12–25% improvement in Top-10 accuracy for line-level localization. Yildiz et al. [50] constructed the JITVUL , Vol. 1, No. 1, Article . Publication date: October 2026.

6

Kato et al.

benchmark to evaluate vulnerability detection under practical conditions. Their comparison of LLMs and ReAct agents revealed that relying solely on F1 score can lead to overestimation, highlighting the importance of incorporating pairwise precision. Furthermore, extensive work on Just-In-Time (JIT) defect prediction has proposed commitlevel models for identifying risky changes. Hoang et al. [20] developed DeepJIT, which predicts defects by using both commit messages and code changes. Their evaluation showed that DeepJIT achieved up to 13% improvement over the state-of-the-art model, highlighting the critical role of commit messages in defect prediction. Guglielmi et al. [19] investigated incorporating developercentric features into JIT defect prediction models and showed that such features improve prediction performance. Recent studies have also explored vulnerability detection using JIT approaches. Lomio et al. [29] investigated how effectively JIT bug prediction can be applied to vulnerability prediction. They concluded that vulnerability prediction based on commit-level bug prediction is not yet practical and emphasized the importance of investigating features for identifying vulnerabilities. Perl et al. [40] proposed VCCFinder, which detects risky commits by integrating code-difference features with development process metadata. Their results showed that leveraging both code features and metadata is effective in improving detection performance. Nguyen et al. [37] focused on the semantics of code changes and proposed CODEJIT, a framework for vulnerability detection that considers not only modified code but also its impact on unmodified segments. Nguyen et al. [36] found that evaluating on vulnerability-introducing or -fixing commits inflates performance, with existing methods degrading substantially when non-vulnerability-inducing commits are included. 2.3.3 Prediction-Guided Fuzzing. Several studies have incorporated prediction or risk estimation into fuzzing to improve its efficiency. Zong et al. [56] proposed FuzzGuard, which predicts whether generated inputs can reach target code and filters out unreachable inputs before execution. Their evaluation on 45 real vulnerabilities showed that FuzzGuard achieved a speedup of up to 17.1× over AFLGo. Lipp et al. [26] proposed Green Fuzzing, which uses vulnerability prediction and coverage saturation to determine when a fuzzing campaign should be stopped. Their evaluation showed that 24-hour fuzzing campaigns could be terminated 6–12 hours earlier while missing fewer than 0.5 bugs on average. Cui et al. [12] proposed DPFuzz, which predicts defect-prone modules and allocates more fuzzing resources to test cases that exercise those modules. In their evaluation on mJS, DPFuzz triggered 26.1% more crashes on average than FairFuzz. Lee et al. [24] proposed SyzRisk, a continuous kernel regression fuzzer that estimates the risk of recent code changes based on recurring change patterns and prioritizes fuzzing toward risky changes. Their evaluation on Linux kernel v6.0 showed a 61% improvement in bug exposure time compared with Syzkaller. Prior work uses coverage to guide input generation, prioritize code regions, or stop fuzzing campaigns. In contrast, RAISE uses coverage observations from regular continuous fuzzing as predictive features to estimate whether recently introduced changes are vulnerability-prone and to determine whether supplemental fuzzing should be scheduled. Our work differs from prior studies in two key aspects. First, while existing vulnerability prediction methods are designed for general software development contexts, RAISE is tailored specifically to continuous fuzzing environments. RAISE incorporates execution feedback from regular fuzzing, such as coverage metrics, into vulnerability-risk estimation and predicts vulnerability-inducing changes on a daily basis to match the daily fuzzing cycle of systems like OSS-Fuzz. Second, while prior prediction-guided fuzzing studies use prediction or risk information to prioritize inputs, target code regions, or to determine when a fuzzing campaign should be stopped, RAISE addresses a different decision: whether, and to what extent, additional fuzzing sessions should be performed after regular continuous fuzzing. This enables more efficient use of computational resources in large-scale OSS fuzzing environments. , Vol. 1, No. 1, Article . Publication date: October 2026.

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

Open source vulnerabilities

GitHub repository

7 Prediction

Feature Extraction

VIC Label Vulnerability report

RQ1 Performance

Traditional features

Commit

Machine-learning Coverage features

GCS bucket

RQ2 Importance

Coverage report

Preparation for RQ3

OSS-Fuzz GitHub repository

Number of fuzzing sessions per project Con guration

Simulation 1

2

3 4 5 Five strategies

RQ3 Resource allocation

Fig. 2. Overview of Risk-Aware Intensive Supplemental Execution Framework

3

RAISE: Risk-Aware Intensive Supplemental Execution Framework

fi

3.1

Overview

We propose Risk-Aware Intensive Supplemental Execution Framework (RAISE), which estimates the vulnerability risk of code changes and adaptively allocates additional fuzzing to high-risk changes. The model guides decisions to maintain standard fuzzing or perform additional fuzzing when vulnerability-prone changes occur. Figure 2 illustrates the overall framework of our approach. RAISE utilizes features extracted from various software processes, target software systems, and fuzzing. These features are preprocessed and fed into a machine learning model to solve a binary classification problem: whether the provided code changes include at least one vulnerability or not. Once RAISE detects vulnerability-prone changes, one of five strategies can be applied to increase the amount of fuzzing performed. 3.2

Vulnerability-prone Change Detection

3.2.1 Feature extraction. We build RAISE using an 88-dimensional feature set that combines established static code metrics with fuzzing-derived dynamic features, focusing on commits modifying C/C++ source files. Baseline Features: Given a code change, we characterize its static properties by employing 77 features from two previous studies on JIT defect and vulnerability prediction. • Change Features: Kamei et al. [22] developed a set of 14 process and product quality metrics. These features measure the size of the change (e.g., lines added/deleted) and the experience of the developers making the change. Developer-experience metrics are automatically extracted from each project’s Git history using the commit author’s e-mail and prior commit history. • C/C++ Syntax-based Change Features: Using parts of Riom et al.’s publicly available replication package [41] for VCCFinder proposed by Perl et al. [40], we extracted the available VCCFinderbased features. We excluded the four “Expressions” metrics (F30–F33) because they were not implemented in the released feature extractor. Consequently, the impact of excluding these four metrics on predictive performance was not evaluated in this study. Fuzzing-based Dynamic Features: To enhance the performance of JIT vulnerability prediction, we introduce dynamic features derived from fuzzing activities. Although fuzzing can uncover many vulnerabilities, it often fails to achieve full coverage of the target software system or of the code changes made by a commit. Therefore, the extent of achieved coverage provides a critical signal , Vol. 1, No. 1, Article . Publication date: October 2026.

8

Kato et al.

Table 1. Fuzzing-based Dynamic Features Feature Name

Definition

Rationale

LineCoverage

The percentage of executable code lines that have been executed at least once [27].

Lines must be executed for vulnerabilities to be found; commonly used to compare fuzzer effectiveness [8].

FunctionCoverage

The percentage of functions that have been executed at least once [27].

A function must be executed during fuzzing to detect its vulnerabilities.

RegionCoverage

The percentage of code regions that have been executed at least once [27].

Code region denotes a compiler generated coverage mapping unit [28]. Region coverage may offer finer granularity than line coverage and can therefore assist in tracking day-to-day fuzzing progress and in revealing newly untested code.

BranchCoverage

The percentage of conditional branches that have been executed at least once [27].

Fuzzer evaluations have reported a very strong correlation between branch coverage and bug discovery [5].

InstantiationCoverage

The percentage of function template instances that were executed at least once [27].

C++ function templates are instantiated as multiple functions at compile time, depending on the type arguments. Function coverage does not distinguish between these concrete instantiations. InstantiationCoverage reveals whether there are any unexecuted instantiations of functions remaining.

PatchCoverage

The percentage of lines added or modified in the current commit’s patch that were executed at least once.

Targeting patch regions improves regression detection efficiency [4]. Patch coverage shows how much newly modified code is executed, which in continuous fuzzing is more directly tied to vulnerability detection than existing coverage [44].

CoverageDelta

The change in coverage compared to the previous day (e.g., 𝐶𝑜𝑣𝑒𝑟𝑎𝑔𝑒 (𝑑𝑎𝑦𝑖 ) − 𝐶𝑜𝑣𝑒𝑟𝑎𝑔𝑒 (𝑑𝑎𝑦𝑖 −1 )).

CoverageDelta is used to detect sudden drops or increases in testing coverage. Day-to-day changes in coverage reveal test progress or degradation; sudden drops may indicate untested new code, while steady gains reflect effective exploration.

regarding the reliability of the code. To capture this information, we leverage code coverage reports published by OSS-Fuzz [43]. Using the commit date, we associate each commit with its corresponding coverage report. As shown in Table 1, we extract 7 types of coverage metrics across several levels of granularity: line, function, region, branch, instantiation, and patch coverage. Because CoverageDelta is computed for the five project-level metrics (i.e., all metrics except PatchCoverage), these feature types yield 11 dynamic features in total. Combined with the 77 static features (14 Kamei et al. features and 63 VCCFinder-based features), they form the 88-dimensional feature set. 3.2.2 Label Creation. To identify vulnerability-introducing commits (VICs), we leverage the Open Source Vulnerabilities (OSV) database, which catalogs known vulnerabilities in open-source software [46]. Specifically, we extract the SHAs of VICs from the “introduced” fields of OSV entries. These commits are labeled as VICs. In our classification setup, a positive label denotes that the commit introduces at least one vulnerability, while a negative label indicates the absence of any known vulnerabilities. 3.3

Strategies for Additional Fuzzing

This section defines five strategies to increase the amount of fuzzing when RAISE predicts that a set of commits/changes committed on a given day contains vulnerabilities. Note that, for all strategies, RAISE recommends increases in terms of additional fuzzing sessions to conduct (rounded to the , Vol. 1, No. 1, Article . Publication date: October 2026.

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

9

nearest integer). To avoid information leakage, all strategies are parameterized in a leave-oneproject-out manner: the statistics and regression models used for a target project are derived only from the other projects. (1) Median Strategy: This strategy suggests additional fuzzing sessions based on the median number of fuzzing sessions that were required to find past vulnerabilities in projects participating in OSS-Fuzz. (2) Randomized Strategy: This strategy suggests additional fuzzing sessions by assigning a random number between the first and third quartiles when calculating the required number of fuzzing sessions that were required to identify past vulnerabilities across the other projects. (3) Line-Change Proportional Strategy: Inspired by Monden et al. [32], this strategy allocates additional fuzzing sessions proportionally to the size of changes. The number of additional fuzzing sessions is calculated as follows: log(𝐷𝑖 + 1) 𝑎𝑖 = 𝐹𝑚𝑒𝑑𝑖𝑎𝑛 · log(𝐷𝑚𝑒𝑑𝑖𝑎𝑛 + 1) where 𝑎𝑖 represents the number of additional sessions allocated to day 𝑖. 𝐹𝑚𝑒𝑑𝑖𝑎𝑛 is the median number of additional fuzzing sessions that were required to find past vulnerabilities in projects participating in OSS-Fuzz. 𝐷𝑖 is the size of changes (measured in lines of code modified) on day 𝑖, and 𝐷𝑚𝑒𝑑𝑖𝑎𝑛 is the median change size within the same project. This proportional allocation ensures that days with larger code changes undergo more fuzzing, reflecting the assumption that larger modifications have a higher potential for introducing vulnerabilities. (4) Simple-Regression Strategy: This strategy predicts the number of additional fuzzing sessions required using a simple regression model. The simple linear regression model is trained using the number of modified source code lines on a given day and the number of fuzzing sessions required to find previous vulnerabilities. (5) Multi-Regression Strategy: This strategy predicts the number of additional fuzzing sessions required using a multiple regression model. The multiple linear regression model is trained using all the metrics used for RAISE (See Section 3.2.1) and historical data (i.e., the number of sessions that were required to find previous vulnerabilities). 4

Experimental Setup

This section details the approach and experimental design adopted to answer our research questions. 4.1

Research Questions

We address three research questions to evaluate the feasibility and practical utility of RAISE. 𝑅𝑄 1 : How accurately can we identify when vulnerabilities were introduced? Several studies have attempted to identify commits that introduce defects or vulnerabilities, an approach known as JIT bug prediction. Kamei et al. [22] proposed an approach to detect defectinducing commits using 14 metrics extracted from version control systems, while Perl et al. [40] predicted vulnerability-inducing commits using code diffs and commit messages. In the context of continuous fuzzing, Zhu et al. [54] reported that 77% of 23,000 bugs discovered by OSS-Fuzz were regressions introduced by recent code changes. This finding indicates that recently introduced changes account for a substantial fraction of bugs discovered during continuous fuzzing. However, existing JIT prediction models have mainly been evaluated using defects or vulnerabilities collected from general software-development data. It therefore remains unclear how effectively these models , Vol. 1, No. 1, Article . Publication date: October 2026.

10

Kato et al.

can identify vulnerability-introducing changes that are subsequently discovered through continuous fuzzing. Therefore, in RQ1, we investigate whether established JIT prediction techniques can identify vulnerability-introducing project-days in a continuous fuzzing environment. 𝑅𝑄 2 : What metrics are effective for vulnerability prediction? Prior JIT defect and vulnerability prediction studies primarily rely on static metrics derived from code changes and development history [22, 40]. In continuous fuzzing, however, regular fuzzing performed after code changes provides execution feedback, such as code coverage. Because fuzzing explores program behavior through dynamically generated inputs and its exploration progress can vary across executions, code-change and development-process metrics alone do not reveal how thoroughly the current revision, particularly the modified code, has actually been exercised. Prior large-scale empirical work on continuous fuzzing has shown that changes in code coverage are associated with fuzzing bug discovery [44]. This suggests that execution feedback from continuous fuzzing may provide useful information for identifying vulnerability-prone changes. In RQ2, we investigate whether incorporating fuzzing-derived execution feedback improves vulnerability prediction beyond established static metrics, and which metrics contribute most to the prediction. 𝑅𝑄 3 : Which allocation strategy is most effective for fuzzing? Prior studies have used defect or vulnerability predictions to improve fuzzing resource decisions. For example, DPFuzz allocates more testing resources to modules predicted to be defect-prone, while Green Fuzzing uses predicted vulnerable functions to determine when a fuzzing campaign should be stopped [12, 26]. However, these studies focus on how resources are used during a fuzzing campaign; they do not address whether additional fuzzing should be performed after regular continuous fuzzing nor how much additional effort should be allocated. This decision is important because predicting vulnerability-prone changes does not guarantee that regular fuzzing will expose the corresponding vulnerabilities and indiscriminately increasing fuzzing efforts would incur unnecessary computational cost. In RQ3, we investigate how vulnerability-risk estimates can be leveraged to dedicate additional fuzzing effort. Specifically, we compare five allocation strategies and evaluate them based on their efficiency at discovering vulnerabilities. 4.2

Data Collection

4.2.1 Vulnerability Labeling. To train models, we need to create labels indicating whether a set of commits made on a given day 𝑖 has at least one vulnerability. To do so, we utilize the OSV database [46], which compiles reports of vulnerabilities discovered in the wild. The database includes the project name, the publication timestamp of the vulnerability entry, aliases (e.g., CVE and GitHub Security Advisory (GHSA) identifiers), affected versions and commit ranges (including the introduced and fixed commits), the repository URL, and references to advisories, bug reports, and fixing commits. In total, we collected 3,822 OSV vulnerability reports from the database. The publication timestamp in OSV indicates when an entry was published or updated, not when the vulnerability was actually detected. To obtain the detection date and detailed information, we refer to the OSS-Fuzz issue reports associated with each OSV entry. OSS-Fuzz generates an issue report upon discovering a vulnerability, and each report contains the stack trace, a reproducible test case, regression ranges, and metadata such as the fuzzing engine, sanitizers used, fuzz target name, and platform. The issue description also includes a reported timestamp, which we use as the vulnerability detection time, following the same approach as prior work [13]. All 3,822 OSV entries included at least one reference to the corresponding OSS-Fuzz issue report. 4.2.2 Project Selection. To compare our results with previous work that supports only C/C++ features (e.g., VCCFinder [40]), we restricted our data collection to OSV vulnerability reports that are linked to OSS-Fuzz issue reports and whose repositories are primarily written in C/C++. This , Vol. 1, No. 1, Article . Publication date: October 2026.

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

11

resulted in 3,512 OSV vulnerability reports (91.9% of total reports) from 268 repositories. After filtering out repositories that were not publicly available and could not be cloned, we were left with 3,439 OSV vulnerability reports from 255 repositories. Because RAISE makes daily predictions, we need projects with sufficient historical data for reliable predictions. We therefore filtered out projects with fewer than 10 vulnerability introducing days. As a result, our dataset consists of 15 projects and 347 vulnerability introducing days, derived from 968 distinct OSV vulnerability reports. 4.2.3 Coverage Data Collection. Because our model leverages code coverage metrics from fuzzing, we also collected daily coverage reports archived in the public OSS-Fuzz Google Cloud Storage (GCS) bucket. Our coverage report dataset consists of 30,312 coverage reports collected from the aforementioned 15 projects dating from August 22, 2018 to June 1, 2025. These coverage reports contain project wide coverage metrics for each day, such as executed lines, functions, regions, branches, and instantiation coverage. To compute the patch coverage defined in Table 1, we mined 29,879 srcmap.json files generated during our studied period. A srcmap.json file maps source directories in the build container to their version-control metadata (e.g., repository URL and commit hash). We parse each srcmap.json file generated by the daily coverage builds to identify the exact project revisions that were built. After identifying the exact revisions, we then extract the source code diffs between each revision and its parent. Finally, we measure the daily PatchCoverage by calculating the percentage of added/modified lines from the diff that were executed at least once. Note that the srcmap.json file is used to identify the exact revision built for coverage reporting, not to infer when a vulnerability was introduced. Table 2 summarizes the statistics of the final dataset. Table 2. Statistics of the Studied Dataset

4.3

Metric

Value

Number of Projects Total Days (Instances) # Positive Days (with VICs) # Negative Days (without VICs) Ratio of Positive Days Number of coverage report Number of srcmap Number of vulnerability report

15 15,210 347 14,863 2.28% 30,312 29,879 968

Feature Extraction

In this experiment, we predict whether or not the set of commits made on a given day 𝑖 contains at least one vulnerability. While most JIT defect prediction models operate at the individual commit level, our approach aggregates commits on a daily basis. This design choice is motivated by the operational characteristics of OSS-Fuzz, which evaluates coverage daily rather than per commit, making it impractical to compute accurate coverage-related metrics for individual commits. We therefore aggregate commit-level metrics into daily-level metrics. We excluded days with no commits and days for which no OSS-Fuzz coverage report was generated. The aggregation logic varies depending on the feature type in order to best capture the characteristics of the changes made on a given day. Table 3 summarizes the transformation rules applied to each feature type. , Vol. 1, No. 1, Article . Publication date: October 2026.

12

Kato et al.

Table 3. Daily Feature Aggregation Rules Category

Rule

Rationale / Hypothesis

Kamei & VCCFinder

sum

For size-based and count-based Kamei metrics and all VCCFinder features, sum aggregates the total magnitude of code modifications and the total count of potentially risky patterns introduced throughout the day.

Kamei

mean

For developer experience and entropy-related Kamei metrics, mean provides the average characteristic of the day’s commits, smoothing out the influence of any single outlier commit.

Coverage

last

Metrics that represent a final state capture the definitive state of test coverage at the end of the day. This value provides the most appropriate baseline for subsequent development.

Similarly, we assign a binary label (1: includes at least one vulnerability; 0: includes none) for any given day 𝑖 based on whether the set of commits made on that day is known to contain at least one vulnerability. 4.4

Model Construction

We employ two machine learning algorithms that have demonstrated strong performance in JIT defect prediction [15, 47, 49, 52], Random Forest [6] and XGBoost [9]. These algorithms are known for their effectiveness with limited data and robustness against overfitting [6, 9, 18]. Moreover, they provide interpretable feature-importance scores, supporting our goal of improving our understanding of which features are effective for vulnerability prediction. We use fixed hyperparameter settings for Random Forest and XGBoost across all projects and feature configurations, without hyperparameter tuning. By intentionally holding model settings constant, we isolate the effect of the feature configurations and prevent differences in tuning from confounding their comparison. Since only 2.28% of the samples belong to the positive class in our dataset, we applied random undersampling to address class imbalance during model training. Specifically, we randomly selected a subset of the majority class (i.e., negative class) to match the size of the minority class (i.e., positive class), thereby balancing the training data. 4.5

Evaluation

To simulate a realistic deployment scenario in which a model is applied to a new project that lacks historical labeled data, we adopt a cross-project setting [21]. Unlike within-project, cross-project prediction models are trained on historical data from other projects to predict vulnerabilities in new, unseen target projects. Given a set of 𝑁 projects, we iteratively select one project as the target and use the remaining 𝑁 − 1 projects as the training set. For the testing phase, we strictly preserve the chronological order of days within the target project. This approach ensures that the evaluation respects temporal dependencies, which is critical for time-sensitive evaluation settings, as emphasized by recent research [51]. Furthermore, to mitigate the impact of random variations inherent to machine learning algorithms (e.g., initialization seeds in RF and XGBoost) and data sampling, we repeat the training and evaluation procedure 30 times with different random seeds for each target project and report the mean performance. This evaluation protocol follows recent work on JIT defect prediction [33]. While the prediction model outputs a probability 𝑝 ∈ [0, 1] indicating whether a given instance contains a vulnerability, we convert these probabilistic outputs into binary labels using a default , Vol. 1, No. 1, Article . Publication date: October 2026.

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

13

decision threshold of 𝑝 = 0.5, as is commonly done in defect and vulnerability prediction studies [14, 22]. Following this practice, instances with 𝑝 ≥ 0.5 are classified as positive when computing threshold-dependent evaluation metrics. Under this setting, RAISE performs a binary classification task to determine whether the set of code changes made on a given day contains at least one vulnerability-introducing change. Given the class imbalance in our dataset, we adopt ROC-AUC, PR-AUC, and Matthews Correlation Coefficient (MCC) as our primary performance measures, rather than traditional metrics such as precision and recall. ROC-AUC and PR-AUC are threshold-independent ranking-based measures, and MCC is a complementary confusion-matrix-based statistic that is often recommended for imbalanced defect/vulnerability prediction. These metrics are better suited for evaluating models under imbalanced conditions, as demonstrated in recent studies [7, 36, 45]. For completeness, we also report traditional metrics as a reference. The detailed definitions for each performance measure are described below. Precision, Recall, and F1-Score: These metrics provide insight into the trade-offs of the model. Precision measures the correctness of positive predictions, which is critical for minimizing developer effort spent on false alarms. Recall (or sensitivity) measures the model’s ability to find actual positive instances, which is paramount for security. The F1-Score provides the harmonic mean of Precision and Recall, offering a balanced view of performance. PR-AUC: PR-AUC (Area Under the Precision-Recall Curve) summarizes the trade-off between precision and recall across all classification thresholds. Unlike ROC-AUC, PR-AUC focuses on the performance of the minority class, making it highly informative for imbalanced datasets. ROC-AUC: ROC-AUC (Area Under the ROC Curve) is a metric that measures the model’s ability to distinguish between positive and negative classes across all thresholds. It is worth noting that it can be overly optimistic on imbalanced data due to the large number of true negatives [52]. MCC: MCC (Matthews Correlation Coefficient) is a correlation coefficient between the observed and predicted classifications, calculated from all four entries of the confusion matrix. It is widely regarded as one of the most reliable single-score metrics for imbalanced binary classification. Statistical analysis: To determine whether the observed differences are statistically significant rather than due to chance, we treat each of the 15 projects as a single paired observation and compare configurations using the two-sided Wilcoxon signed-rank test [48]. We choose this non-parametric, paired test because our samples are small (𝑁 =15), not normally distributed, and naturally paired by project (the same project is evaluated under every configuration). For each project, the 30 repetitions and cross-validation folds are not independent observations; they repeatedly remeasure the same underlying project data under different random seeds. We therefore average them into a single value per project before testing because treating each repetition/fold outcome as an independent sample would otherwise inflate the effective sample size (i.e., pseudo-replication) and make the test appear more significant than it really is. We complement each test with the Cliff’s 𝛿 effect size [10], interpreting |𝛿 | as negligible (< 0.147), small (< 0.33), medium (< 0.474), or large otherwise. Because we perform many pairwise comparisons, we control the false discovery rate using the Benjamini–Hochberg procedure [2] and report BH-adjusted 𝑝-values, considering a difference statistically significant when the adjusted 𝑝 < 0.05. We apply this same protocol uniformly across all three RQs. In RQ3, each project contributes one cost-per-vulnerability value per strategy, and projects in which either strategy of a pair detected no vulnerability are excluded from that pair; strategies are therefore compared with the same project-paired test. , Vol. 1, No. 1, Article . Publication date: October 2026.

14

Kato et al.

Table 4. Ablation Results: Daily Vulnerability Prediction Performance Across Six Feature Sets Feature Set ID Feature Set

Model

ROC-AUC

PR-AUC

MCC

Precision

Recall

F1-Score

fs0

Random

—

0.50

0.03

0.00

0.03

0.02

0.02

Kamei

RF XGB

0.60 0.59

0.05 0.05

0.04 0.04

0.04 0.04

0.51 0.51

fs1

0.07 0.07

fs2

Kamei + Coverage

RF XGB

0.71 0.70

0.10 0.10

0.11 0.10

0.06 0.06

0.62 0.63

0.11 0.10

fs3

VCCFinder

RF XGB

0.66 0.65

0.06 0.06

0.08 0.07

0.05 0.05

0.66 0.66

0.09 0.08

fs4

VCCFinder + Coverage

RF XGB

0.74 0.72

0.10 0.11

0.12 0.11

0.06 0.06

0.66 0.68

0.11 0.11

fs5

Coverage

RF XGB

0.69 0.68

0.09 0.09

0.08 0.09

0.05 0.05

0.64 0.66

0.09 0.09

5

Results

This section presents the experimental results to answer our three research questions (RQs). First, we evaluate the performance of our proposed vulnerability prediction model in comparison to baseline approaches (RQ1). Next, we analyze which features are effective for predicting vulnerabilities (RQ2). Finally, we assess the practical value of our approach by evaluating the efficiency of allocating additional fuzzing resources based on vulnerability-risk estimates (RQ3). 5.1 𝑅𝑄 1 : How accurately can we identify when vulnerabilities were introduced? Approach. To answer RQ1, we evaluate the optimal performance achievable by our proposed vulnerability prediction model. Specifically, we follow the cross-project setting detailed in Section 4. For prediction, we use Random Forest and XGBoost models because they have been widely reported to achieve strong performance in JIT bug and vulnerability prediction studies [15, 21, 29, 47, 51, 52]. The feature sets are compared across six configurations: Kamei et al.’s features only, VCCFinder’s features only, either of these two feature sets augmented with fuzzing-based dynamic features (denoted as Coverage in Table 4), fuzzing-based dynamic features only, and random prediction as the baseline. Results. Table 4 summarizes the performance of the six configurations (fs0–fs5) with Random Forest and XGBoost classifiers. The best configuration is a Random Forest model trained on the combined VCCFinder and coverage features (fs4), which achieves an average MCC of 0.12, an F1-Score of 0.11, a Recall of 0.66, and a PR-AUC of 0.10. Its PR-AUC is substantially higher than the random baseline of 0.03, indicating that the model learned patterns that separate high-risk code changes from lower-risk ones. Precision is nevertheless limited, so a notable share of warnings would be false positives. This is a well-known challenge in JIT vulnerability prediction: a recent study [36] reported PR-AUC values of 0.013 for Linux and 0.071 for FFmpeg, and MCC values of 0.030 and 0.122.2 The low Precision, PR-AUC, MCC, and F1-Score reflect the difficulty of identifying vulnerability-introducing project-days under severe class imbalance, as only 2.28% of the instances in our dataset are positive. Our model thus performs comparably to current state-of-the-art JIT vulnerability prediction models. 2 The precision values were not reported in the previous study [36].

, Vol. 1, No. 1, Article . Publication date: October 2026.

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

15

To assess the contribution of the fuzzing-based dynamic features, we compare configurations with and without them for each base feature set. Adding these features to VCCFinder (fs3→fs4) improves the average MCC from 0.08 to 0.12 and the PR-AUC from 0.06 to 0.10; adding them to Kamei et al.’s features (fs1→fs2) improves the average ROC-AUC from 0.60 to 0.71 and the PR-AUC from 0.05 to 0.10. These improvements are statistically significant. Across the 15 projects, each of the five feature-based configurations (fs1–fs5) significantly outperforms the random baseline on all three primary metrics (Wilcoxon signed-rank test, Benjamini–Hochberg-adjusted 𝑝 < 0.05), with large effect sizes for ROC-AUC and MCC (Cliff’s 𝛿). Both fs3→fs4 and fs1→fs2 also yield significant gains on all three metrics (adjusted 𝑝 < 0.05; e.g., 𝛿 = 0.70 for ROC-AUC on fs3→fs4). The gains also hold at the project level: PR-AUC improves in 14 of 15 projects for fs3→fs4 and in all 15 for fs1→fs2 (median paired differences of 0.032 and 0.028), although the magnitude varies across projects. Fuzzing-based dynamic features thus add predictive information beyond static ones. Answer to RQ1 Our best model (Random forest with VCCFinder + Coverage features) achieved a mean MCC of 0.12 and an F1-Score of 0.11. It significantly outperformed the random baseline (Wilcoxon signed-rank test, Benjamini–Hochberg-adjusted 𝑝 < 0.05; large effect sizes for ROC-AUC and MCC) across all three primary metrics (ROC-AUC, PR-AUC, and MCC). 5.2 𝑅𝑄 2 : What metrics are effective for vulnerability prediction? Approach. To answer RQ2, we conduct an ablation study to assess the impact of different feature combinations on model performance. Specifically, we compare the results of six experimental configurations (fs0–fs5). Additionally, we further investigate the importance of individual features in the best-performing model configuration. For each target project, we extract feature-importance scores (e.g., Gini importance for RandomForest) from the trained model and aggregate these scores across all projects. This aggregation allows us to examine the distribution of feature importance and identify the features that are most influential for prediction. Results. Table 4 summarizes the ablation results across the six feature configurations (fs0–fs5). For MCC, we report only the raw scores, as percentage improvements are not meaningful when the baseline is close to zero or negative. (a) Comparison of Feature Sets: Table 4 shows that the VCCFinder + Coverage configuration (fs4) achieves the best overall performance across ROC-AUC, MCC, Precision and F1-Score. These results indicate that combining fuzzing-based dynamic features and traditional features is the most effective approach for vulnerability prediction. A pairwise analysis (paired Wilcoxon test with Benjamini– Hochberg correction) confirms this ranking while clarifying where the gains originate. No other configuration significantly outperforms fs4 on any of the three primary metrics. However, fs4 significantly outperforms Kamei+Coverage (fs2) on ROC-AUC (𝛿 = 0.27, adjusted 𝑝 < 0.05), while no statistically significant difference was detected for PR-AUC or MCC. This indicates that, once coverage features are included, the choice of static feature set (Kamei vs. VCCFinder) has little effect on performance, with coverage being the dominant signal, consistent with the feature-importance analysis below. However, adding static features to the coverage-only features (fs5→fs4) still yields a small but significant improvement for ROC-AUC and MCC (adjusted 𝑝 < 0.05), indicating that the two feature families remain complementary. Furthermore, the inferior performance of the configuration that used only fuzzing-based dynamic features (when compared to configurations that used both dynamic and traditional features) highlights the importance of using both static and dynamic features. , Vol. 1, No. 1, Article . Publication date: October 2026.

16

Kato et al.

PatchCoverage InstantiationCoverage RegionCoverage RegionCoverage FunctionCoverage LineCoverage LineCoverage InstantiationCoverage BranchCoverage FunctionCoverage 0.00

0.01

0.02

0.03

0.04

0.05

Gini importance

0.06

0.07

0.08

Fig. 3. Feature importance of the top 10 most important features in the best-performing model (fs4: VCCFinder + Coverage).

(b) Feature importance of the best model (fs4): Figure 3 presents the top-10 features for the best-performing model (fs4, Random forest). PatchCoverage had the highest feature importance, followed by other coverage metrics. In particular, absolute coverage metrics (e.g., PatchCoverage, InstantiationCoverage, RegionCoverage, FunctionCoverage, and LineCoverage) provide a critical baseline for assessing the risk of vulnerability-inducing code changes. Several delta-based coverage metrics also appeared among the top-ranked features. Their importance scores were generally lower than PatchCoverage’s score, while some delta-based metrics, such as RegionCoverageDelta and LineCoverageDelta, showed importance scores comparable to several absolute coverage metrics. Absolute coverage reflects the extent to which code is exercised by fuzzing, whereas day-to-day coverage fluctuations may indicate changes in testing progress or regression following code changes. Answer to RQ2 Our results show that incorporating fuzzing-derived dynamic features improves vulnerability prediction over static features alone. Coverage-related features, particularly PatchCoverage, are among the most influential features in the best-performing model. 5.3 𝑅𝑄 3 : Which allocation strategy is most effective for fuzzing? Approach. In RQ3, for each project-day predicted by RAISE to contain vulnerability-prone changes in the RQ1 simulation, we apply five strategies to determine to what extent additional fuzzing should be performed. Because fuzzing time varies across projects due to differences in project size and the number of fuzzing harnesses, we define a fuzzing session as one day of fuzzing for a given project. For example, if a project is typically fuzzed for 10 minutes per day (the default value in CIFuzz) and a strategy recommends two additional fuzzing sessions, this corresponds to conducting two additional 10-minute fuzzing sessions. To evaluate the allocation strategies, we must first determine how many fuzzing sessions were required to detect each vulnerability. We use the OSV Database to find the commit when a vulnerability was introduced. We then use the OSS-Fuzz report creation date as the detection date. , Vol. 1, No. 1, Article . Publication date: October 2026.

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

17

Table 5. Efficiency of Vulnerability Detection Under Simulated Fuzzing-Session Allocation Strategies (RQ3)

Strategy S1 Median S2 Random S3 Line-Change Proportional S4 Simple Regression S5 Multi Regression

Total Cost Vulnerabilities Effective Trigger Cost per (session) found Rate (%) vulnerability 35,925 188,985 38,334 11,084 18,861

209 278 213 121 107

2.32 2.78 2.32 1.72 2.34

171.89 679.80 179.97 91.60 176.27

Since one fuzzing session corresponds to one day, the number of sessions required to detect a vulnerability equals the number of days elapsed between its introduction and detection. Based on this ground truth, we assess each strategy as follows. If a strategy’s suggested number of additional fuzzing sessions equals or exceeds the number of sessions actually required to detect a vulnerability, we consider that the allocation was successful. If the suggested number exceeds the true number required, the excess sessions are treated as wasted. If the suggested number falls short of the true number, all suggested sessions are treated as wasted. Note that if RAISE mistakenly predicts a set of changes as likely to be vulnerable, all additional suggested sessions are considered wasted. Thus, our resource-allocation evaluation explicitly accounts for the cost of both false-positive predictions and over-allocation as wasted fuzzing effort. Since RAISE is intended to guide automated fuzzing-resource allocation rather than manual developer inspection, the primary cost of false positives is additional computational effort. To keep our evaluation rigorous, we applied some constraints. First, in our simulation, each daily prediction is treated independently and does not influence additional fuzzing decisions on subsequent days. We therefore only evaluate vulnerabilities that were introduced on the day being predicted and exclude cases where vulnerabilities from previous days were discovered coincidentally. Second, if no code changes occur on a given day, no additional fuzzing prediction is made. Results. Table 5 summarizes the effectiveness of the five strategies across 968 target vulnerabilities. “Total Cost (Sessions)” and “Vulnerabilities Found” represent the total number of allocated additional fuzzing sessions and the total count of successfully detected vulnerabilities, respectively. “Cost per Vulnerability” is calculated by dividing the total cost by the number of vulnerabilities found. “Effective Trigger Rate” is defined as the percentage of triggers (i.e., executions of additional fuzzing sessions) that successfully identified a vulnerability. Among the baseline strategies, Median (S1) spends 35,925 sessions to find 209 vulnerabilities at a cost of 171.89 sessions per vulnerability (effective trigger rate: 2.32%). Random (S2) increases resource usage to 188,985 sessions for 278 vulnerabilities. It achieves the highest effective trigger rate (2.78%) because it often allocates more sessions than the other strategies, which increases the chance of reaching the number of sessions required for detection; however, this results in the highest cost per vulnerability at 679.80. LineChange Proportional (S3) shows performance comparable to S1, detecting 213 vulnerabilities within 38,334 sessions. Its effective trigger rate is 2.32% and the cost per vulnerability is 179.97. The regression-based strategies show different trade-offs. Simple Regression (S4) has the lowest total cost (11,084 sessions), but also the lowest effective trigger rate (1.72%) and fewer vulnerabilities found (121). Nevertheless, it achieves the lowest cost per vulnerability (91.60) among all tested strategies. Multi Regression (S5) detects 107 vulnerabilities with 18,861 sessions, resulting in a cost per vulnerability of 176.27, comparable to those of S1 and S3. , Vol. 1, No. 1, Article . Publication date: October 2026.

18

Kato et al.

Figure 4 shows the per-project differences in cost per vulnerability between S4 and the other strategies, with positive values indicating lower costs for S4. Projects in which either strategy of a pair detected no vulnerability are excluded from that pair, because their cost per vulnerability is undefined. S4 had a lower cost per vulnerability than S1, S2, S3, and S5 in 13 of 14, 14 of 14, 13 of 14, and 12 of 13 projects, respectively. Thus, the advantage of S4 is consistent across projects. To test whether these differences are statistically significant, we compare the strategies on their per-project cost per vulnerability using the paired Wilcoxon signed-rank test with Benjamini– Hochberg correction (Section 4.5). Simple Regression (S4) is significantly more cost-efficient than each of the three prediction-agnostic heuristics, Median (S1), Random (S2), and Line-Change Proportional (S3) (adjusted 𝑝 < 0.05; large effect against S2), and also than Multi Regression (S5) (𝛿 = 0.43, adjusted 𝑝 = 0.004). Multi Regression is significantly more cost-efficient only than Random (S2). The key finding is therefore that Simple Regression (S4) is the most efficient strategy, whereas the additional features of Multi Regression do not improve allocation efficiency. Overall, Simple Regression (S4) is the most cost-efficient strategy, with both the lowest total session cost and the lowest cost per vulnerability. Random (S2) is the most expensive per vulnerability. Answer to RQ3 Simple Regression (S4) was the most cost-efficient strategy and was significantly more costefficient than the prediction-agnostic heuristics and Multi Regression (S5). S5 did not significantly outperform the Median (S1) and Line-Change Proportional (S3) heuristics. Among all strategies, the Random strategy (S2) was the least cost-efficient, with the highest cost per vulnerability. 6

Threats to validity

In this section, we discuss the potential threats to the validity of our study. We categorize these threats into three main types: internal validity, construct validity, and external validity. Internal validity: A significant threat in cross-project prediction is the heterogeneity of data distributions; metrics such as code size or commit frequency can vary drastically between projects (e.g., libraries vs. applications), potentially biasing the model [55]. To address this, we employed tree-based models (Random Forest and XGBoost), which are invariant to monotonic transformations of feature values and thus relatively robust to scale differences across projects [6, 9]. Construct validity: The accuracy of our ground truth labels relies on the VICs identified via the OSV database [46]. OSV’s “introduced” field in OSV entries is sometimes recorded as an unknown, potentially introducing noise. To mitigate this threat, we strictly filtered our dataset to include only cases with explicit commit SHAs, ensuring that positive labels are tied to specific code changes. We formulated the risk prediction at a daily granularity. While this aggregation inevitably poses a risk of signal dilution where benign commits could mask a vulnerability introduced on the same day, our data source, OSS-Fuzz, reports coverage metrics as daily snapshots rather than per-commit. We however believe that this granularity aligns with practical operational workflows in Continuous Fuzzing, where resource allocation decisions (e.g., scheduling extended fuzzing campaigns) are typically made on a daily or nightly basis rather than per commit. Consequently, whether the same findings would hold at commit-level granularity remains unclear, and evaluating this would require per-commit coverage information that is not available in OSS-Fuzz. Coverage features are obtained from reports generated after the corresponding code changes. In our dataset, 16.1% of the 968 vulnerabilities were detected on the same day as their introduction, so the corresponding coverage reports may include executions that contributed to the detection itself. This temporal dependency may lead to optimistic estimates of the coverage-aware model’s , Vol. 1, No. 1, Article . Publication date: October 2026.

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

S1 - S4 S4 cheaper on 13 / worse on 1 (n=14) icu wireshark wolfssl serenity php poppler libjxl mruby arrow ghostscript ndpi harfbuzz libxml2 openthread

median = +49.0

100

0

S2 - S4 S4 cheaper on 14 / worse on 0 (n=14) wolfssl wireshark serenity php icu poppler arrow mruby openthread libjxl harfbuzz ndpi libxml2 ghostscript

100 200 300 400

median = +517.3

0

Cost-per-vulnerability difference (sessions)

1000

2000

Cost-per-vulnerability difference (sessions)

S3 - S4 S4 cheaper on 13 / worse on 1 (n=14)

icu wolfssl wireshark serenity php poppler libjxl arrow mruby ghostscript ndpi libxml2 harfbuzz openthread

19

S5 - S4 S4 cheaper on 12 / worse on 1 (n=13)

serenity openthread mruby icu harfbuzz php libjxl poppler ndpi wolfssl ghostscript libxml2 median = +56.2

100

0

100

200

300

400

Cost-per-vulnerability difference (sessions)

arrow

median = +111.5

0

500

1000 1500 2000

Cost-per-vulnerability difference (sessions)

Fig. 4. Per-project paired differences in cost per vulnerability between S4 and each comparison strategy. Each point represents the comparison strategy’s cost per vulnerability minus that of S4 for one project. Positive values favor S4, and dashed lines indicate median paired differences.

performance. In RQ3, we also quantified fuzzing effort using the number of daily fuzzing sessions. We acknowledge that this metric simplifies the heterogeneity of actual computational costs (e.g., CPU time), which varies by fuzzing target. However, granular resource consumption data (e.g., , Vol. 1, No. 1, Article . Publication date: October 2026.

20

Kato et al.

precise CPU hours per fuzzing session) is not publicly available. Consequently, we approximate the amount of additional fuzzing required relative to the usual amount conducted using the number of fuzzing sessions as a proxy for resource allocation. External validity: The dataset used in this study is limited to 15 C/C++ projects integrated into OSS-Fuzz. These projects tend to have a strong focus on security and well-established testing infrastructures. These characteristics and the small number of projects may limit the generalizability of our findings to a broader range of software projects. The predictive utility of the coverage features and the effectiveness of the allocation strategies may also vary across continuous fuzzing environments. Moreover, the results primarily concern memory corruption vulnerabilities that are characteristic of fuzzing; memory corruption vulnerabilities typically involve unintended modification of memory contents, whereas other types such as injection or improper access control involve exploiting flaws in input handling or authorization logic. It is unclear whether the same feature sets or models would be effective for different classes of vulnerabilities that are prevalent in other languages (e.g., injection, improper access control). Therefore, caution is required when applying the findings of this study to other languages or projects. 7

Conclusion

In this paper, we proposed RAISE, a Risk-Aware Intensive Supplemental Execution Framework that uses project-day-level JIT vulnerability-risk estimates to guide the allocation of additional fuzzing resources in continuous fuzzing. Using vulnerability-introducing commits derived from OSV and coverage and change data from OSS-Fuzz, we constructed a daily-level dataset comprising 15 C/C++ projects, 15,210 project days, and 347 vulnerability-introducing days (2.28% positive rate). On top of this dataset, we empirically evaluated both the predictive performance of RAISE and its impact on fuzzing resource allocation. Our results show that it is possible to identify days on which vulnerabilities are introduced substantially better than random and traditional baselines, although the task remains challenging. For RQ1, Random Forest achieves ROC-AUC of up to about 0.74 and PR-AUC of about 0.10, clearly outperforming a random baseline (ROC-AUC = 0.50, PR-AUC = 0.03) despite the extreme imbalance in the data. For RQ2, we find that syntax-based static features, combined with Fuzzing-based Dynamic Features, consistently yield the best performance. In the Random Forest model, the individual feature importance scores further indicate that coverage-related features are the most influential predictors. For RQ3, we compared five resource allocation strategies using our newly designed simulation framework over 968 vulnerabilities across 15 target projects. The SimpleRegression strategy was significantly more cost-efficient than the prediction-agnostic heuristics, requiring 91.60 fuzzing sessions per detected vulnerability. Future work includes several directions. First, we plan to extend RAISE to finer-grained units such as individual commits or fuzz targets, once richer per-commit coverage information becomes available, and to explore more expressive representations of code changes (e.g., learned embeddings or graph-based models) that may further improve predictive performance under realistic evaluation protocols. Second, evaluating RAISE in an industrial CI/CD setting where developers interact with risk estimates and resource allocation decisions in real time would provide valuable insights into usability, trust, and organizational impact, and could lead to user-facing tools for risk-aware continuous fuzzing. Acknowledgments We gratefully acknowledge the financial support of JSPS KAKENHI grants (JP24K02921, JP25K03100, JP26K23818, JP26H02500), as well as ASPIRE grant (JPMJAP2415), JST CREST grant (JPMJCR23M1, , Vol. 1, No. 1, Article . Publication date: October 2026.

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

21

JPMJCR26X7), JST FOREST (JPMJFR252W), and the Inamori Research Institute for Science for supporting Yasutaka Kamei via the InaRIS Fellowship. References [1] Craig Beaman, Michael Redbourne, J. Darren Mummery, and Saqib Hakak. 2022. Fuzzing vulnerability discovery techniques: Survey, challenges and future directions. Computers & Security 120 (2022), 102813. [2] Yoav Benjamini and Yosef Hochberg. 1995. Controlling the False Discovery Rate: A Practical and Powerful Approach to Multiple Testing. Journal of the Royal Statistical Society: Series B (Methodological) 57, 1 (01 1995), 289–300. [3] Marcel Böhme and Brandon Falk. 2020. Fuzzing: on the exponential cost of vulnerability discovery. In Proceedings of the 28th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE’20). 713–724. [4] Marcel Böhme, Van-Thuan Pham, Manh-Dung Nguyen, and Abhik Roychoudhury. 2017. Directed Greybox Fuzzing. In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security (CCS’17). 2329–2344. [5] Marcel Böhme, László Szekeres, and Jonathan Metzman. 2022. On the Reliability of Coverage-Based Fuzzer Benchmarking. In Proceedings of the 44th IEEE/ACM 44th International Conference on Software Engineering (ICSE’22). 1621–1633. [6] Leo Breiman. 2001. Random Forests. Machine Learning 45, 1 (2001), 5–32. [7] Sicong Cao, Xiaobing Sun, Lili Bo, Rongxin Wu, Bin Li, Xiaoxue Wu, Chuanqi Tao, Tao Zhang, and Wei Liu. 2024. Learning to Detect Memory-related Vulnerabilities. ACM Transactions on Software Engineering and Methodology 33, 2 (2024), 43:1–43:35. [8] Peng Chen and Hao Chen. 2018. Angora: Efficient Fuzzing by Principled Search. In Proceedings of the 2018 IEEE Symposium on Security and Privacy (SP’18). 711–725. [9] Tianqi Chen and Carlos Guestrin. 2016. XGBoost: A Scalable Tree Boosting System. In Proceedings of the 22nd ACM SIGKDD International Conference on Knowledge Discovery and Data Mining (KDD’16). 785–794. [10] Norman Cliff. 1993. Dominance statistics: Ordinal analyses to answer ordinal questions. Psychological Bulletin 114, 3 (11 1993), 494–509. [11] Lei Cui, Jiancong Cui, Zhiyu Hao, Lun Li, Zhenquan Ding, and Yongji Liu. 2022. An empirical study of vulnerability discovery methods over the past ten years. Computers & Security 120 (2022), 102817. [12] Zhanqi Cui, Haochen Jin, Xiang Chen, Rongcun Wang, and Xiulei Liu. 2024. DPFuzz: A fuzz testing tool based on the guidance of defect prediction. Sci. Comput. Program. 238 (2024), 103170. [13] Zhen Yu Ding and Claire Le Goues. 2021. An Empirical Study of OSS-Fuzz Bugs. In Proceedings of the 18th IEEE/ACM International Conference on Mining Software Repositories (MSR’21). 131–142. [14] Michael Fu and Chakkrit Tantithamthavorn. 2022. LineVul: A Transformer-based Line-Level Vulnerability Prediction. In Proceedings of the 19th IEEE/ACM International Conference on Mining Software Repositories (MSR’22). 608–620. [15] Takafumi Fukushima, Yasutaka Kamei, Shane McIntosh, Kazuhiro Yamashita, and Naoyasu Ubayashi. 2014. An empirical study of just-in-time defect prediction using cross-project models. In Proceedings of the 11th Working Conference on Mining Software Repositories (MSR’14). 172–181. [16] Google. 2026. Documentation for OSS-Fuzz. https://google.github.io/oss-fuzz/#trophies Accessed: February 1, 2026. [17] Philipp Görz, Joschua Schilling, Thorsten Holz, and Marcel Böhme. 2025. An Empirical Study of Fuzz Harness Degradation. CoRR abs/2505.06177 (2025). https://doi.org/10.48550/arXiv.2505.06177 [18] Léo Grinsztajn, Edouard Oyallon, and Gaël Varoquaux. 2022. Why do tree-based models still outperform deep learning on typical tabular data?. In Proceedings of the Advances in Neural Information Processing Systems 35: Annual Conference on Neural Information Processing Systems 2022 (NeurIPS’22). [19] Emanuela Guglielmi, Andrea D’Aguanno, Rocco Oliveto, and Simone Scalabrino. 2025. Enhancing Just-In-Time Defect Prediction Models with Developer-Centric Features. In Proceedings of the 22nd IEEE/ACM International Conference on Mining Software Repositories (MSR’25). 52–62. [20] Thong Hoang, Hoa Khanh Dam, Yasutaka Kamei, David Lo, and Naoyasu Ubayashi. 2019. DeepJIT: an end-to-end deep learning framework for just-in-time defect prediction. In Proceedings of the 16th International Conference on Mining Software Repositories (MSR’19). 34–45. [21] Yasutaka Kamei, Takafumi Fukushima, Shane McIntosh, Kazuhiro Yamashita, Naoyasu Ubayashi, and Ahmed E. Hassan. 2016. Studying just-in-time defect prediction using cross-project models. Empirical Software Engineering 21, 5 (2016), 2072–2106. [22] Yasutaka Kamei, Emad Shihab, Bram Adams, Ahmed E. Hassan, Audris Mockus, Anand Sinha, and Naoyasu Ubayashi. 2013. A Large-Scale Empirical Study of Just-in-Time Quality Assurance. IEEE Transactions on Software Engineering 39, 6 (2013), 757–773. [23] Brandon N. Keller, Benjamin S. Meyers, and Andrew Meneely. 2023. What Happens When We Fuzz? Investigating OSS-Fuzz Bug History. In Proceedings of the 20th IEEE/ACM International Conference on Mining Software Repositories , Vol. 1, No. 1, Article . Publication date: October 2026.

22

Kato et al.

(MSR’23). 207–217. [24] Gwangmu Lee, Duo Xu, Solmaz Salimi, Byoungyoung Lee, and Mathias Payer. 2024. SyzRisk: A Change-Pattern-Based Continuous Kernel Regression Fuzzer. In Proceedings of the 19th ACM Asia Conference on Computer and Communications Security, ASIA CCS 2024, Singapore, July 1-5, 2024. [25] Jun Li, Bodong Zhao, and Chao Zhang. 2018. Fuzzing: a survey. Cybersecurity 1, 1 (2018), 6. [26] Stephan Lipp, Daniel Elsner, Severin Kacianka, Alexander Pretschner, Marcel Böhme, and Sebastian Banescu. 2023. Green Fuzzing: A Saturation-Based Stopping Criterion using Vulnerability Prediction. In Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA’23). 127–139. [27] LLVM Project. 2026. Clang Documentation. https://clang.llvm.org/docs/index.html. Accessed: February 1, 2026. [28] LLVM Project. 2026. LLVM Documentation. https://llvm.org/docs/index.html. Accessed: February 1, 2026. [29] Francesco Lomio, Emanuele Iannone, Andrea De Lucia, Fabio Palomba, and Valentina Lenarduzzi. 2022. Just-in-time software vulnerability detection: Are we there yet? Journal of Systems and Software 188 (2022), 111283. [30] Valentin J. M. Manès, HyungSeok Han, Choongwoo Han, Sang Kil Cha, Manuel Egele, Edward J. Schwartz, and Maverick Woo. 2021. The Art, Science, and Engineering of Fuzzing: A Survey. IEEE Transactions on Software Engineering 47, 11 (2021), 2312–2331. [31] Barton P. Miller, Lars Fredriksen, and Bryan So. 1990. An Empirical Study of the Reliability of UNIX Utilities. Commun. ACM 33, 12 (1990), 32–44. [32] Akito Monden, Takuma Hayashi, Shoji Shinoda, Kumiko Shirai, Junichi Yoshida, Mike Barker, and Ken-ichi Matsumoto. 2013. Assessing the Cost Effectiveness of Fault Prediction in Acceptance Testing. IEEE Transactions on Software Engineering 39, 10 (2013), 1345–1357. [33] Issei Morita, Yutaro Kashiwa, Masanari Kondo, Jeongju Sohn, Shane McIntosh, Yasutaka Kamei, and Naoyasu Ubayashi. 2024. TraceJIT: Evaluating the Impact of Behavioral Code Change on Just-In-Time Defect Prediction. In Proceedings of the IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER’24). 580–591. [34] National Institute of Standards and Technology. 2014. CVE-2014-0160. https://nvd.nist.gov/vuln/detail/CVE-2014-0160. National Vulnerability Database. [35] National Institute of Standards and Technology. 2024. CVE-2024-6387. https://nvd.nist.gov/vuln/detail/CVE-2024-6387. National Vulnerability Database. [36] Duong Nguyen, Thanh Le-Cong, Triet Huynh Minh Le, M. Ali Babar, and Quyet-Thang Huynh. 2025. Toward Realistic Evaluations of Just-In-Time Vulnerability Prediction. CoRR abs/2507.10729 (2025). arXiv:2507.10729 doi:10.48550/ARX IV.2507.10729 [37] Son Nguyen, Thu-Trang Nguyen, Thanh Trong Vu, Thanh-Dat Do, Kien-Tuan Ngo, and Hieu Dinh Vo. 2024. Codecentric learning-based just-in-time vulnerability detection. Journal of Systems and Software 214 (2024), 112014. [38] Olivier Nourry, Yutaro Kashiwa, Bin Lin, Gabriele Bavota, Michele Lanza, and Yasutaka Kamei. 2024. The Human Side of Fuzzing: Challenges Faced by Developers during Fuzzing Activities. ACM Transactions on Software Engineering and Methodology 33, 1 (2024), 14:1–14:26. [39] Olivier Nourry, Yutaro Kashiwa, Weiyi Shang, Honglin Shu, and Yasutaka Kamei. 2025. My Fuzzers Won’t Build: An Empirical Study of Fuzzing Build Failures. ACM Trans. Softw. Eng. Methodol. 34, 2 (2025), 29:1–29:30. doi:10.1145/3688842 [40] Henning Perl, Sergej Dechand, Matthew Smith, Daniel Arp, Fabian Yamaguchi, Konrad Rieck, Sascha Fahl, and Yasemin Acar. 2015. VCCFinder: Finding Potential Vulnerabilities in Open-Source Projects to Assist Code Audits. In Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security (CCS’15). 426–437. [41] Timothée Riom, Arthur D. Sawadogo, Kevin Allix, Tegawendé F. Bissyandé, Naouel Moha, and Jacques Klein. 2021. Revisiting the VCCFinder approach for the identification of vulnerability-contributing commits. Empirical Software Engineering 26, 3 (2021), 46. [42] Rebecca L. Russell, Louis Y. Kim, Lei H. Hamilton, Tomo Lazovich, Jacob Harer, Onur Ozdemir, Paul M. Ellingwood, and Marc W. McConley. 2018. Automated Vulnerability Detection in Source Code Using Deep Representation Learning. In Proceedings of the 17th IEEE International Conference on Machine Learning and Applications (ICMLA’18). 757–762. [43] Kostya Serebryany. 2017. OSS-Fuzz - Google’s continuous fuzzing service for open source software. USENIX Association. [44] Tatsuya Shirai, Olivier Nourry, Yutaro Kashiwa, Kenji Fujiwara, Yasutaka Kamei, and Hajimu Iida. 2026. Large-Scale Empirical Analysis of Continuous Fuzzing: Insights From 1 Million Fuzzing Sessions. IEEE Trans. Software Eng. 52, 7 (2026), 2047–2063. [45] Chakkrit Tantithamthavorn, Ahmed E. Hassan, and Kenichi Matsumoto. 2020. The Impact of Class Rebalancing Techniques on the Performance and Interpretation of Defect Prediction Models. IEEE Transactions on Software Engineering 46, 11 (2020), 1200–1219. [46] Google Open Source Security Team. 2025. OSV : Open Source Vulnerability. https://osv.dev/. Accessed: February 1, 2026.

, Vol. 1, No. 1, Article . Publication date: October 2026.

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

23

[47] Raymon van Dinter, Cagatay Catal, Görkem Giray, and Bedir Tekinerdogan. 2023. Just-in-time defect prediction for mobile applications: using shallow or deep learning? Software Quality Journal 31, 4 (2023), 1281–1302. [48] Frank Wilcoxon. 1945. Individual Comparisons by Ranking Methods. Biometrics Bulletin 1, 6 (1945), 80–83. [49] Chathrie Wimalasooriya, Sherlock A. Licorish, Daniel Alencar da Costa, and Stephen G. MacDonell. 2024. Just-in-Time crash prediction for mobile apps. Empirical Software Engineering 29, 3 (2024), 68. [50] Alperen Yildiz, Sin G. Teo, Yiling Lou, Yebo Feng, Chong Wang, and Dinil Mon Divakaran. 2025. Benchmarking LLMs and LLM-based Agents in Practical Vulnerability Detection for Code Repositories. In Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers) (ACL’25). 30848–30865. [51] Yunhua Zhao, Kostadin Damevski, and Hui Chen. 2023. A Systematic Survey of Just-in-Time Software Defect Prediction. Comput. Surveys 55, 10 (2023), 201:1–201:35. [52] Xin Zhou, DongGyun Han, and David Lo. 2025. Bridging expert knowledge with deep learning techniques for just-in-time defect prediction. Empirical Software Engineering 30, 1 (2025), 37. [53] Yaqin Zhou, Shangqing Liu, Jing Kai Siow, Xiaoning Du, and Yang Liu. 2019. Devign: Effective Vulnerability Identification by Learning Comprehensive Program Semantics via Graph Neural Networks. In Proceedings of the Advances in Neural Information Processing Systems 32: Annual Conference on Neural Information Processing Systems 2019 (NeurIPS’19). 10197–10207. [54] Xiaogang Zhu and Marcel Böhme. 2021. Regression Greybox Fuzzing. In Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security (CCS’21). 2169–2182. [55] Thomas Zimmermann, Nachiappan Nagappan, Harald C. Gall, Emanuel Giger, and Brendan Murphy. 2009. Crossproject defect prediction: a large scale experiment on data vs. domain vs. process. In Proceedings of the 7th joint meeting of the European Software Engineering Conference and the ACM SIGSOFT International Symposium on Foundations of Software Engineering (ESEC/FSE’09). 91–100. [56] Peiyuan Zong, Tao Lv, Dawei Wang, Zizhuang Deng, Ruigang Liang, and Kai Chen. 2020. FuzzGuard: Filtering out Unreachable Inputs in Directed Grey-box Fuzzing through Deep Learning. In 29th USENIX Security Symposium, USENIX Security 2020, August 12-14, 2020. USENIX Association, 2255–2269.

, Vol. 1, No. 1, Article . Publication date: October 2026.

Related documents

• Raise or Check? Predicting the Necessity of Additional Fuzzing for Continuous Fuzzing#1403623
• Stop Starving or Stuffing Me: Boosting Firmware Fuzzing Efficiency with On-demand Input Delivery#200578
• TraceLib: System-Call Bitmap Feedback Mechanism for Language-Agnostic Web Fuzzing#1129399
• TraceLib: System-Call Bitmap Feedback Mechanism for Language-Agnostic Web Fuzzing#1108829
• Soundness Checking of Taint Flow Models#1076406