Inspiration
Security teams do not lose because they lack another severity score. They lose because they cannot patch everything in the current change window.
CVSS describes how severe a vulnerability is. EPSS estimates the chance it will be exploited in the wild over the next 30 days. CISA's Known Exploited Vulnerabilities catalogue confirms that some flaws have already been exploited. Each signal is useful. None of them, alone, answers the operational question: given the software this organization actually runs, which fixes remove the most risk inside a fixed number of engineering hours?
That gap is what BreachWindow is built to close.
What it does
BreachWindow Intelligence turns vulnerability data into an explainable remediation plan.
- It normalizes the supplied vulnerability, product, reference, KEV, and monthly exploit-signal files around CVE identifiers.
- It matches affected products and versions to an asset inventory and shows the match evidence. The demo inventory is simulated and is labeled as simulated.
- It keeps CVSS, EPSS, KEV, asset exposure, and business criticality separate, then produces an organizational priority a person can audit.
- It selects remediation actions under an engineering-hours budget.
- It compares that plan with CVSS-only, EPSS-only, and KEV-first rankings on the same candidates and the same budget.
- An IBM Granite model on watsonx.ai explains the engine's evidence. The model does not calculate the score and does not invent vulnerability facts.
How we built it
The score is deterministic. Python handles ingestion and validation. DuckDB handles the analytical joins. Affected-product and reference rows are aggregated by CVE before they are joined, so those one-to-many tables cannot multiply the vulnerability count.
Missing EPSS stays missing. KEV is an urgency flag, not a probability of 1. The 2026 scoreboard is a benchmark: its exploit flags are not used as inputs to predict those same outcomes.
The dashboard is Streamlit and Plotly. The remediation step is a budgeted optimizer, compared against the three conventional rankings above. Granite receives only the structured evidence for a selected action and explains why that action was chosen.
Challenges
- Joining vulnerability, product, and reference files without duplicating CVEs.
- Matching product and version strings without treating a fuzzy match as a confirmed exposure.
- Separating a population-level threat signal from the risk to one organization's assets.
- Keeping future exploit labels out of any historical comparison.
- Making the language-model explanation cite the engine's evidence instead of freelancing new facts.
What we learned
The useful distinction is already in the data definitions. A high CVSS score, a high EPSS score, and a KEV listing are three different claims. A patching plan that sorts by only one of them spends the same engineering hours on a different set of fixes.
Measured comparison numbers, the public repository, and the two-minute walkthrough will be added to this page before the Sunday deadline.
What's next
Ship the baseline comparison, publish the notebook and dashboard, and record the demo around one decision: two vulnerabilities with similar global scores that deserve different priorities because they affect different assets.
