CVSS, EPSS, and KEV: Which Score Decides What You Patch First

A vulnerability scan finishes and leaves you with a list. Sixty CVE IDs, or six hundred, each with a number beside it, and a working week that will not stretch to cover all of them. The list has to become an order, and the number beside each ID looks like it was put there to supply one.

It was not. The score most scanners lead with measures how damaging a flaw would be if somebody attacked it, which is a different question from whether anyone is attacking it. Three public data sources answer three separate questions about the same CVE, and knowing which is which changes what you do on Monday morning.

Three numbers, three questions#

Start with what each one is actually asking.

• CVSS asks how bad would this be if it were exploited? A severity, produced by analysis of the flaw itself.
• EPSS asks how likely is exploitation in the next 30 days? A probability, produced by a model trained on observed attack activity.
• KEV asks is this being exploited right now? A yes or no, published by CISA on the strength of reported evidence.

None of the three is a replacement for the others, and none of them describes your network. A CVE ID by itself carries none of this: the identifier is a name, issued so that everyone discussing a flaw is discussing the same flaw. It takes the form CVE-2021-44228, with a year and a sequence number that grows longer as the years get busier. Assignment says a vulnerability was reported and catalogued. It says nothing about severity, exploitation, or whether you are running the affected build.

CVSS: how bad it would be#

The Common Vulnerability Scoring System is maintained by FIRST, and it is the number almost every tool shows first. Version 3.1 buckets scores into five bands: none at 0.0, low from 0.1 to 3.9, medium from 4.0 to 6.9, high from 7.0 to 8.9, and critical from 9.0 to 10.0.

What matters is which part of CVSS you are usually looking at. Version 3.1 defines three metric groups. Base covers the intrinsic properties of the flaw, the things that stay constant over time and across environments. Temporal covers what changes as the world learns about it, such as whether exploit code exists. Environmental covers your deployment, letting you raise or lower the score for how the affected system is actually used.

Version 4.0 reorganised that. The groups became Base, Threat, Environmental, and Supplemental. Threat replaced Temporal with a narrower scope, keeping Exploit Maturity and dropping the rest, and Supplemental holds optional context that carries no weight in the final number.

Here is the catch. Nearly every published CVSS figure, including the one your scanner prints, is the Base score alone. FIRST is explicit that consumers should enrich the base metrics with threat and environmental values for their own use of the system before treating the result as an input to risk. Almost nobody does. So the score you sort by describes a flaw in the abstract, in a deployment that is not yours, with no knowledge of whether anyone has ever attacked it.

EPSS: how likely it is in 30 days#

The Exploit Prediction Scoring System, also from FIRST, answers the question CVSS cannot. It publishes a probability between 0 and 1 that exploitation activity against a CVE will be detected and reported by the sensor networks of FIRST's data partners within the next 30 days. New scores go out every day for every scored vulnerability, shortly after 13:30 UTC.

Two properties of that number surprise people.

The first is how low the probabilities run. The distribution is heavily skewed toward zero, with the vast majority of vulnerabilities scoring below 10% and most far below that. Only a small share of all published vulnerabilities are ever exploited at all. A 4% probability looks like nothing until you notice how much company it has at 0.04%.

The second is the percentile that ships alongside it. The probability is a global measure; the percentile ranks a CVE against every other scored CVE. FIRST's own worked example puts a score of 0.10 at roughly the 88th percentile, meaning 88% of catalogued vulnerabilities score lower. Reading only the probability, 10% sounds unremarkable. Reading the percentile, it is in the top eighth of everything scored.

One thing not to do with these numbers: FIRST specifically warns against multiplying an EPSS probability by a CVSS score. The product has no interpretable meaning, and a composite figure is much harder to argue with than two figures that each say something.

KEV: who is being attacked now#

CISA's Known Exploited Vulnerabilities catalog is the only one of the three that is not a score. It is a list, and a conservative one. A vulnerability is added when it has an assigned CVE ID, when there is reliable evidence it has been actively exploited in the wild, and when there is a clear remediation action such as a vendor update. Published proof-of-concept code is not enough on its own.

The catalog opened on 3 November 2021, created by binding operational directive BOD 22-01, and it has grown past 1,600 entries since. Each entry carries the date it was added, the required action, a federal remediation due date, and a flag for whether the vulnerability is linked to known ransomware campaigns. Roughly a fifth of the current catalog carries that ransomware flag.

The federal machinery around it has changed. CISA now lists BOD 22-01 as revoked, superseded during 2026 by BOD 26-04, which directs agencies to prioritise by a wider set of risk factors rather than by catalog membership alone. Entries still carry due dates, and recent ones tend to fall a few days to a few weeks after the add date. If you are not a federal civilian agency none of those deadlines binds you, but they remain a useful read on how urgent CISA considers each item.

What KEV gives you that no probability can is certainty in one direction. Presence means exploitation has been observed. Absence means nothing has been reported and confirmed, which is not the same as nothing happening.

Why sorting by severity misfires#

Put the three together and the default behaviour of most vulnerability queues starts to look strange.

Sorting by CVSS descending puts a 9.8 that nobody has ever attacked above a 7.5 with a working exploit in active use. Both numbers are correct. The ordering is not, because the 9.8 describes a hypothetical and the 7.5 describes something happening this week. Queues sorted that way end up ranked by dread rather than by evidence, and the items at the top are frequently the ones that will still be sitting there next quarter, untouched and unexploited.

There is a practical wrinkle too. A recently published CVE often has no CVSS score yet, because scoring lags disclosure. Sorting by severity quietly drops those rows to the bottom, and a fresh vulnerability with no score is exactly the kind that gets attacked before anyone finishes analysing it.

An order that survives scrutiny#

A defensible order reads the three signals in order of how much evidence each carries.

1. Confirmed exploitation. Anything in KEV goes first. This is observed, not predicted.
2. High predicted probability. Then the CVEs with a meaningful EPSS score, worst first.
3. Severity. CVSS decides ties and tells you what you are risking, but it does not set the order.

Our bulk CVE triage tool applies exactly that. Paste up to 100 CVE IDs, or paste the raw scanner output and let it pull the IDs out, and every row lands in one of five bands: Exploited for anything in KEV, Likely for an EPSS probability at or above 10%, Elevated for 1% and up, Low signal for everything scored below that, and No data where no EPSS score exists at all. The two thresholds are judgement calls, and the page says so rather than hiding them.

Deliberately absent: a single blended risk number. Combining a binary catalog, a probability, and a severity produces a figure with no units that nobody can sensibly dispute. Each row instead states in words why it landed where it did, so you can disagree for a stated reason.

Reading a real list#

Three patterns show up on nearly every batch.

A critical with nothing behind it. CVSS 9.8, no KEV entry, EPSS in the low single digits of a percent. Real, worth fixing, and not what you cancel a Friday for. This is the row severity-first ordering puts at number one.

A medium that is on fire. CVSS 6.5, listed in KEV, remediation date already close. The severity band understates it because severity was never measuring urgency.

A row with no score at all. Recently disclosed, not yet enriched, no EPSS. There is no signal either way, so it falls to your own judgement about exposure. For a single ID like that, the CVE Explorer gives you the fuller picture: the NVD description, whichever CVSS version is available (it prefers 4.0, then 3.1, 3.0, and 2.0 in that order), and the KEV verdict with its due date and ransomware flag.

One design detail worth knowing about both tools. The KEV catalog is read from a snapshot held on our own side rather than fetched live, so the exploitation answer still arrives when the upstream APIs are slow or rate-limiting. CVSS and EPSS come from NVD and FIRST at request time, and when one of those does not answer, the page names the source that is missing instead of showing a blank cell that reads as "nothing here".

What none of them know#

All three signals describe vulnerabilities. None of them describes you.

Whether the affected service is reachable from the internet or buried behind three internal hops changes the calculus more than any score does, and that is a question about your own attack surface rather than about the CVE. Our guide to open ports and what they expose covers the reachability half of it. Whether the vulnerable component is even loaded, whether a compensating control already blocks the path, and what the system holds are all yours to supply.

That is the honest limit of a triage tool, and it is also why the ranking is worth doing. Nobody can weigh six hundred rows individually. Sorting by evidence of exploitation puts the handful that genuinely need a human at the top, and leaves the rest as scheduled maintenance. When an indicator turns up in a log rather than in a scan, the same triage logic applies to indicators of compromise, with the same caveat about context.

The number your scanner shows you first was never designed to be the one you sort by. Read it third.