CVSS, EPSS, and KEV: three vulnerability signals, explained

CVSS, EPSS, and KEV are three of the most useful vulnerability signals, and they are constantly confused for one another. They are not competing scores; they answer genuinely different questions, and the reason vulnerability queues feel unmanageable is almost always that a team is using one of them - usually CVSS - to do the job of all three.

What each one measures

CVSS - the Common Vulnerability Scoring System - measures theoretical severity: given the technical characteristics of a vulnerability, how bad would exploitation be? It produces the familiar 0-to-10 score. Its critical limitation is that it says nothing about whether anyone will actually exploit the vulnerability, and its distribution is top-heavy, which is how queues fill with hundreds of indistinguishable “criticals.”

EPSS - the Exploit Prediction Scoring System - predicts likelihood: a probability, updated regularly from observed exploitation activity, that a given vulnerability will be exploited in the near term. Its power is separation - the gap between a high EPSS score and a negligible one is the gap between “attackers are working on this” and “no meaningful attention” - and most vulnerabilities, including most high-CVSS ones, score very low, which is exactly the useful information.

KEV - the Known Exploited Vulnerabilities catalog - is not a prediction at all. It records confirmed exploitation in the wild. A KEV entry means the question of whether a vulnerability will be attacked is settled: it already is.

The three answer, respectively: how bad, how likely, and is it already happening.

Combining them into an order

The reliable approach is a ladder, not a formula:

1. Confirmed exploitation (KEV) first, unconditionally - real-world attack outranks any theoretical score, and shipping a known-exploited vulnerability should be an explicit, gated decision.
2. High likelihood (EPSS) next, ordered by score - “likely to be attacked soon,” usually a mercifully short list.
3. Severity (CVSS) as the tiebreaker within what remains - restoring impact as the ordering principle once the exploitation signals have spoken.

Context multiplies through all of it: the same vulnerability matters more on an internet-facing service than in an internal batch job, and reachability can demote a vulnerable component your code never calls. Asset criticality is your knowledge, not a feed’s, and it belongs in the ranking.

What changes when you do this

The wall of criticals does not shrink because vulnerabilities disappeared - it shrinks because most of it was never the urgent work, and now the urgent work has names. Fix-first arguments end, because the ordering carries its own justification: “it is being exploited in the wild” and “it is far more likely to be attacked than the one below it” are arguments; “it is a 9.8” is a shrug. The full prioritization argument walks through the transformation on a real queue.

The SecuNexa dashboard builds its queue this way - severity, EPSS, KEV, and reachability combined into one order of work - with the signals riding inside the offline vulnerability bundle, so prioritization stays honest without the platform ever reaching the internet.