IBM Research has published a paper describing Bugstone-E2E, a framework that converts public vulnerability history into executable detection rules and then validates what those rules find. The work, submitted to arXiv on 4 September 2026, is research-stage: the authors present a pipeline and evaluation results, not a shipping product.
The premise is that CVE records, CWE labels, and fixing commits already explain why code was unsafe — but they are written for human readers, not scanners. Bugstone-E2E tries to close that gap by mining verified fixing commits and turning them into reusable rules that can search other codebases for the same unsafe conditions.
How the pipeline works
The system runs in two broad parts. First, a CVE-to-skill pipeline mines the cvelistV5 dataset, verifies fixing commits, and synthesizes rules that capture scan anchors, buggy and fixed code patterns, a verification contract, and the source CVEs. Rules are grouped by CWE family and programming language into modular detection "skills."
Second, detection follows a funnel shape. Cheap analysis runs on the full candidate pool; expensive models run only on what survives. Concretely, the pipeline works in stages:
- Tree-sitter indexes the target codebase and enumerates call sites matching rule anchors, with no LLM calls involved.
- Lightweight deterministic heuristics remove clearly benign candidates.
- LLM-based agents inspect the remaining candidates, guided by the rule.
- The system re-triages survivors and builds runtime verifications.
- Finally, it generates scope-checked patches validated through two-sided differential tests.
That last stage matters because a static match is not proof. The authors argue a complete workflow needs runtime evidence that a behavior is actually reachable, plus a patch verified to remove the demonstrated behavior.
The numbers
Starting from 19,325 high-severity CVEs published between 2022 and 2026, Bugstone-E2E identified 2,710 fixing commits and constructed 1,033 detection rules spanning 56 CWE families, packaged into 172 skills. Applied across 14 programs, the system produced runtime evidence for 644 findings.
The paper also evaluates scanner efficiency, cross-harness comparison on wolfSSL, run-to-run reproducibility, and a remediation prototype, according to its section structure.
Why it matters
The timing is pointed. Vulnerability volume has been climbing through 2026, with defenders facing record Patch Tuesday loads even as AI-assisted discovery expands the public CVE flood. If discovery is becoming automated and abundant, the bottleneck shifts to detection and remediation on the defender's side. A pipeline that converts already-public patch history into reusable detectors is a direct answer to that asymmetry: the knowledge exists, it is just not executable.
Limitations
The authors acknowledge open challenges. CVE records and patches vary widely in quality — relevant fixes can be buried in unrelated edits or tied to project-specific logic, which complicates rule extraction. Rule specificity is a balancing act: matching on a raw call like memcpy is too broad, while an overly narrow signature misses the same flaw behind a different wrapper. The paper includes a dedicated limitations and future-work discussion, and the framework remains a research prototype rather than a generally available tool.
Our take
The interesting design choice is economic, not just technical: reserving LLM calls for the shrinking tail of the funnel is an admission that model-based code analysis does not yet scale on cost alone. If that funnel holds up beyond the 14 evaluated programs, the leverage shifts to whoever curates the best rule library — and 1,033 rules across 56 CWE families is a start, not coverage. What remains unproven is how well mined rules generalize to languages and projects far from their source CVEs.
