Inspiration
Security teams face far more new CVEs than they can patch. CVSS measures possible severity, but it does not answer the operational question: what should we fix first when the patch budget is limited? We built ExploitPath for the IBM Before the Breach challenge to rank newly published vulnerabilities using only evidence that was available at the decision cutoff.
What it does
ExploitPath ranks the 72,670 CVEs in the 2026 benchmark and produces a top-500 remediation queue. On locked 2025 development validation, its first 50 patches caught 10 CVEs later added to CISA KEV, compared with 4 for the strongest simple baseline (public exploit flag, then EPSS). At 100 patches it caught 12 versus 8. At 500 the methods were roughly level, 19 versus 18, so we lead with the small-budget result where the model actually helps.
The analyst application provides:
- An overview of cumulative later-KEV hits versus patch budget, baseline comparisons, assigner-history lift, and deliberately excluded leakage-prone features.
- A historical KEV landscape built from 1,484 IBM-provided records through 2025: monthly additions and public exploit signals, the most represented vendors, and publication-to-KEV delay distributions.
- A searchable top-500 queue served from Tiger Data.
- Per-CVE logistic-regression feature contributions and the strongest TF-IDF terms.
- Three date-valid historical KEV neighbours retrieved with IBM Granite embeddings.
- Monthly vendor EPSS and exploit-signal history queried from a Tiger Data Timescale hypertable.
- A Gemini analyst brief grounded only in computed contributions, time-cut evidence, and Granite neighbours.
- Remediation status and analyst notes stored in Tiger Data.
How we built it
The ranking model is balanced logistic regression over month-end EPSS, public exploit signals, time-cut assigner/vendor KEV history, description patterns, and TF-IDF description features. Scores order the queue; they are not calibrated probabilities.
We selected the model on an inner 2024 split before scoring 2025. The pipeline is deterministic and writes the validation curves, ranking, explanations, and audit artifacts directly from code.
IBM Granite (granite-embedding-30m-english) performs retrieval, not ranking: it finds the three most similar CVEs already in KEV by the candidate's publication-month end. Granite variants were evaluated for ranking on the inner split but did not win, so we kept the more defensible retrieval role.
IBM challenge data also powers the descriptive historical KEV landscape. Signal coverage is shown explicitly: 419 of 431 additions in 2024-2025 have valid month-end observations, while 12 missing snapshot records remain unknown rather than being treated as zero. The charts exclude all 2026 outcomes, distinguish CISA ransomware status Unknown from No, and disclose 62 inconsistent negative publication-to-KEV delays.
Tiger Data stores rankings, current CVE context, analyst notes, cached Gemini briefs, and a Timescale hypertable of monthly historical exploit signals.
Gemini on Vertex AI produces a three-sentence brief plus one action. Its prompt is restricted to whitelisted evidence. Output is validated, retried once if necessary, and replaced by a deterministic template if it fails the guardrails.
Challenges
The hardest problem was temporal leakage. Today's NVD records can contain details added after exploitation. We excluded current review status, product and reference counts, current CVSS, CWE, today's links, and post-event phrases such as "exploited in the wild." Historical name lists, month-end signal observations, and Granite neighbours are cut at the correct date.
An earlier draft reported a stronger result, but an audit found future vendor lists, unstripped text, random tie jitter, and a hand-adjusted curve. We removed those issues and report the reproducible result: 10 versus 4 at 50 patches and 19 versus 18 at 500. We also state that 2025 is development validation, not an untouched holdout or a 2026 result.
What we learned
Public exploit signals carry substantial information, while CVSS alone performs poorly for prioritization. The model's real advantage is ordering the very top of the queue. We also learned that explainability must be computed before generative summarization: Gemini can phrase the evidence, but it must not invent the drivers.
The historical landscape reinforced a second lesson: absence of a signal in a missing snapshot is unknown, not negative. Making coverage, excluded records, and temporal limits visible is part of the product not a footnote.
What's next
We would validate on larger rolling-origin windows, improve vendor/entity resolution, study calibration before displaying likelihoods, and add exploitation labels beyond KEV. Granite would enter the ranking only if it wins prospectively on a larger selection window.
Limitations
KEV is incomplete, month-end snapshots cannot prove a signal preceded an intra-month KEV decision, current descriptions may contain later edits, and CVEs below rank 500 are not safe they simply fall outside the selected patch budget.
Built With
- docker
- gemini
- google-cloud
- hugging-face
- ibm-granite
- pandas
- plotly
- postgresql
- python
- scikit-learn
- streamlit
- tiger-data
- timescaledb
- vertex-ai
