EPSS and CISA KEV: scoring vulnerabilities by real-world risk

Every vulnerability management program eventually hits the same wall. The scanner reports hundreds of "critical" vulnerabilities. The team can fix a handful per sprint. CVSS, the scoring system everyone reaches for first, does not break the tie — it labels far too many things critical to be useful as a queue. The way out is to stop scoring vulnerabilities by theoretical severity and start scoring them by real-world risk. Two data sources make that possible: EPSS and the CISA KEV catalog.

Why CVSS is not enough

CVSS, the Common Vulnerability Scoring System, measures how bad a vulnerability could be under worst-case assumptions. That is genuinely useful — but it has two limits as a prioritization tool:

1. It is static. A CVSS base score is assigned once and rarely changes, regardless of whether the vulnerability is being exploited in the wild today or has never been touched.
2. It is inflationary. So many vulnerabilities score 7.0 and above that "critical" stops being a meaningful filter. When everything is critical, nothing is.

CVSS answers "how bad could this be?" It does not answer "how likely is this to actually hurt me, and how soon?" For prioritization, the second question is the one that matters.

EPSS: probability, not just severity

The Exploit Prediction Scoring System (EPSS), maintained by FIRST.org, estimates the probability that a given vulnerability will be exploited in the wild within the next 30 days. It is a data-driven model, updated daily, trained on real exploitation activity.

EPSS reframes the question from "how severe is this?" to "how likely is this to be exploited soon?" The two often diverge sharply. A CVSS 9.8 with an EPSS probability of half a percent is a very different proposition from a CVSS 6.5 with an EPSS probability of 40 percent. EPSS surfaces the latter, which CVSS alone would bury.

CISA KEV: what is being exploited right now

The CISA Known Exploited Vulnerabilities (KEV) catalog is a list, maintained by the United States Cybersecurity and Infrastructure Security Agency, of vulnerabilities with confirmed, observed exploitation in the wild.

KEV is binary and unambiguous: a vulnerability is either on the list or it is not. If it is on the list, it is not a theoretical risk — it is being used by attackers, now. That makes KEV the single strongest prioritization signal available. Anything in your environment that appears on the KEV catalog should jump the queue, almost regardless of its CVSS score.

Combining the signals

The strongest prioritization comes from layering these signals rather than picking one:

1. CISA KEV — is it being actively exploited? If yes, treat it as urgent.
2. EPSS — if not yet on KEV, how likely is exploitation soon?
3. CVSS — as a measure of impact if exploitation does occur.
4. Reachability — is the vulnerable code actually used in what you ship?

That last signal is the multiplier. A KEV-listed, high-EPSS vulnerability in a component you import but never execute is far less urgent than the same vulnerability on a live code path. Pairing exploitation data with reachability is how a list of hundreds becomes a list of a few.

From a wall of red to a sorted queue

This layered approach — exploitation status, exploitation probability, impact, and reachability — is the logic behind modern risk-based prioritization scores, including our own VaultScore. The details of the weighting matter less than the principle: a vulnerability's place in your queue should reflect the real-world danger it poses to your specific software, not just an abstract severity rating.

The promise is not that you will fix more vulnerabilities. It is that the handful you do fix this sprint will be the right ones. Starting from a queue sorted by real risk beats starting from a thousand undifferentiated "criticals" — every single time.