KEV and EPSS: prioritizing vulnerabilities by exploitation, not severity

Why severity alone makes a bad work queue

CVSS (the Common Vulnerability Scoring System, maintained by FIRST) rates intrinsic technical severity: how much damage the vulnerability would do to confidentiality, integrity and availability if someone exploited it, and how hard it is to reach. That is a useful question and it is not the question a team with limited hours is asking. They are asking which of these is being used against organizations like ours right now.

The gap shows up in the distribution. A large estate routinely carries hundreds of high and critical findings, which is more than any team triages in a quarter, so severity alone produces a list nobody finishes — and the order within a severity band is effectively arbitrary. Anything that imposes a real order on that band is worth more than a more precise severity score.

• CVSS answers 'how bad if exploited', not 'is it being exploited'.
• A list of 300 highs is not a priority order; it is the absence of one.
• Exploitation evidence and probability impose an order severity cannot.

CISA KEV: confirmed exploitation, and what it misses

The Known Exploited Vulnerabilities catalog, published by the US Cybersecurity and Infrastructure Security Agency, lists CVEs with reliable evidence of active exploitation in the wild, each with a remediation due date that is binding on US federal civilian agencies under Binding Operational Directive 22-01. For everyone else it is not binding, and it is still the strongest single fix-first signal available for nothing.

Its blind spot is that it is a LAGGING indicator by construction: a CVE appears once exploitation has been observed and verified, so a vulnerability under active exploitation this week may not be listed yet. A KEV hit is strong evidence to act; a KEV miss is weak evidence not to. Treating absence from the catalog as safety is the most common way this signal is misread.

• KEV entries carry a remediation due date — binding on US federal civilian agencies via BOD 22-01.
• Presence is strong evidence. Absence is not evidence of absence: the catalog lags observation.
• Coverage skews to widely-deployed software; a niche component may never appear.

FIRST EPSS: a probability, deliberately not a verdict

The Exploit Prediction Scoring System, maintained by FIRST, publishes a daily probability between 0 and 1 that a given CVE will be exploited in the next 30 days, modelled from observed exploitation activity and vulnerability characteristics. It fills exactly the gap KEV leaves: it produces an ordering across the vulnerabilities nobody has confirmed exploitation for yet.

It is a probability and must be read as one. A score of 0.6 does not mean the vulnerability is 60 percent dangerous; it means roughly six in ten similar vulnerabilities were exploited within the window. Scores move daily as the model sees new activity, so a snapshot taken at triage time is a snapshot, and an EPSS-derived queue is worth recomputing rather than freezing.

A defensible order, and the argument for it

Combining the signals gives a queue that survives a post-incident review. Confirmed exploitation first, because it is the only signal backed by observation. Then how far past its own remediation deadline an item is — a date the organization set and missed is a stronger claim on attention than a label a scanner assigned, and it is the one dimension comparable across every kind of finding. Then severity, then exploitation probability as the tiebreak inside a band.

Whatever order you choose, the queue should be able to explain itself. A ranked list whose reasons are invisible asks to be trusted; one that shows why each item sits where it does can be argued with, and that argument is how a priority call survives contact with the engineer who has to do the work.

• 1. Confirmed exploitation (KEV) — the only observation-backed signal.
• 2. Days past your own remediation deadline — comparable across finding types.
• 3. Severity (CVSS) — impact if exploited.
• 4. Exploitation probability (EPSS) — the tiebreak within a severity band.

Where this still leaves you guessing

None of these signals knows your deployment. A critical vulnerability in a component you ship but never invoke is less urgent than a medium one on your public entry point, and no public catalog can tell you which is which. Reachability analysis and asset context are what close that gap, and they come from your own estate rather than a feed.

The honest position is that KEV and EPSS make the order much better than severity alone and do not make it correct. Treat the result as a strong default that a person with deployment knowledge is allowed to override — and record the override, so the next reviewer sees a decision rather than an anomaly.

Frequently asked questions