EPSS vs CVSS vs KEV: which number actually tells you to patch
Three numbers, three completely different questions. Mixing them up is the fastest way to patch the wrong thing. Here's how I keep them straight — and turn them into one rule.
If you take one thing from a decade of vulnerability triage, take this: CVSS, KEV, and EPSS are not three versions of the same number. They answer three different questions, and the single most common triage mistake is treating a high CVSS as 'the risk.' It isn't. It's one input, and often not the deciding one.
Three numbers, three questions
| CVSS | CISA KEV | EPSS | |
|---|---|---|---|
| Question it answers | How bad if exploited? | Is it exploited, for real? | How likely to be exploited soon? |
| Type | Severity score (0–10) | A binary fact (on the list or not) | Probability (0–100%), recomputed daily |
| Good for | Ranking impact | Forcing action — it's confirmed | Prioritizing before exploitation is confirmed |
| Trap | Treating it as 'the risk' | Assuming absence = safe | Equating the percentage with severity |
The case that makes it click
CVE-2023-44487 — HTTP/2 'Rapid Reset' — is a CVSS 7.5. By severity alone it's a mid-tier bug you might slot behind a dozen 9.8s. But it's on CISA KEV and was exploited at scale. Meanwhile plenty of 9.8s sit in databases having never been touched. If you sorted your queue by CVSS, you'd patch the untouched 9.8s first and leave the exploited 7.5 waiting. Sort by exploitation, and the 7.5 jumps the line — correctly.
Sorting your patch queue
- Untouched 9.8s float to the top
- Exploited mid-CVSS bugs sink
- Feels rigorous, patches the wrong things first
- Confirmed-exploited bugs act now
- CVSS ranks only within that set
- EPSS prioritizes what's not-yet-confirmed
Turning three numbers into one rule
Keeping the axes separate is the discipline; combining them deliberately is the payoff. In My Stack I collapse all three into a single cut-line policy — act on KEV, or a public exploit, or EPSS ≥ 50% — and let CVSS rank whatever clears it. That's the SSVC idea made concrete: exploitation decides whether you act, severity decides in what order. Everything on my stack is scored against that one rule, so I'm never re-litigating 'is a 7.5-on-KEV more urgent than a 9.8-that-isn't' — the policy already answered it.
A caveat on each
- CVSS: a v3 vs v4 score, or NVD vs vendor, can disagree. Use it to rank, not to decide.
- KEV: absence is not innocence — plenty of exploited bugs aren't on KEV yet. KEV forces action; it doesn't grant safety.
- EPSS: it's a model, it moves daily, and it's near-useless once something is already on KEV. Best used to prioritize before exploitation is confirmed.