Imagine you're a casino floor manager watching 1,300 poker tables at once. You can't afford to station a security guard at every table every minute, so you need a system that flags which tables, on which shifts, are most likely to see cheating. You don't need perfect prediction — you need to be right often enough that your guard deployment is cheaper than blanketing the floor. That's what RAISE does for continuous fuzzing: it watches the daily code-change patterns across OSS projects and decides which project-days deserve the expensive additional fuzzing run. The committed claim: a Just-In-Time binary classifier, trained on a combination of VCCFinder-style static code features and dynamic fuzzing coverage metrics, can predict vulnerability-introducing project-days well enough (ROC-AUC 0.74) that a resource-allocation strategy guided by its predictions cuts the cost of finding vulnerabilities roughly in half compared to prediction-agnostic heuristics. The headline number is 91.60 additional fuzzing sessions per detected vulnerability for their Simple-Regression strategy, versus 171.89 for the Median heuristic — a 47% cost reduction. The dataset is modest but carefully assembled: 15 C/C++ projects drawn from OSS-Fuzz, covering 15,210 project-days, with 347 (2.28%) labeled as vulnerability-introducing via the OSV database. The severe class imbalance is the quiet load-bearing reality of this paper. At 2.28% positive rate, even a reasonably discriminative model will generate a lot of false positives in absolute terms, which the authors handle through threshold tuning and the allocation-simulation framing rather than pretending precision is high. Architecturally, this is a Random Forest over hand-engineered features — not deep learning, not LLMs, not transformers. The interesting contribution is the feature engineering: PatchCoverage (how much of a day's code change is exercised by the fuzzer) emerges as the most important predictor, beating purely static code-complexity features. This is a meaningful signal because it connects the ML model to something causally relevant: if the fuzzer isn't reaching the new code, vulnerabilities can hide there. The method family is supervised binary classification with tabular features — about as classical as ML gets. The validation uses cross-project leave-one-out, which is the right design for this problem: you want to know if the model generalizes to a project it hasn't seen, since that's the deployment scenario. ROC-AUC of 0.74 is honest — good enough to be useful in a cost-allocation framework, not good enough to trust as a standalone vulnerability oracle. The simulation over 968 vulnerabilities comparing five allocation strategies adds credibility, because it evaluates the prediction in the context where it would actually be used, not just on abstract classification metrics. The milestone question is where to push. The 0.74 AUC on 15 projects and 347 positives needs to scale: OSS-Fuzz covers 1,300+ projects across multiple languages, and the feature pipeline (particularly the dynamic coverage metrics) needs to work beyond C/C++. Getting to 50+ projects with AUC above 0.75 in a temporal-split (not just cross-project) evaluation would be the number that makes Google's fuzzing team seriously consider integrating this. The gap is probably 1-2 years of engineering effort, not fundamental research. The experiment they didn't run is the temporal split: training on data from months 1-N and predicting month N+1. Cross-project validation tests generalization across codebases, but real deployment is temporal — you're predicting tomorrow from today's features. The authors likely didn't run this because with only 347 positives spread across 15 projects, a temporal split would leave dangerously few positives in the test set for any single project. This is a data-scarcity problem, not a conceptual gap, and it's the obvious next paper.
