CVSS, EPSS, and KEV: turning three signals into one honest queue

A vulnerability queue sorted by CVSS has a characteristic shape: hundreds of criticals, all apparently equal, none obviously first. Teams facing that wall do what humans do with un-actionable lists: they ignore them. The fix is not working harder through the wall; it is sorting by what the three available signals actually measure.

What each signal is

CVSS measures theoretical severity: how bad exploitation would be, given the vulnerability’s technical characteristics. It says nothing about whether anyone will exploit it. Its distribution is also famously top-heavy, which is how queues end up with four hundred indistinguishable “criticals.”

EPSS predicts exploitation likelihood: a daily-updated probability, derived from observed exploitation activity, that a given CVE will be exploited in the near term. Its power is separation: the difference between a large EPSS score and a tiny one is the difference between “attackers are working on this” and “no meaningful attention.” Most CVEs, including most high-CVSS CVEs, score very low, which is precisely the useful information.

KEV, the known-exploited-vulnerabilities catalog, is not a prediction at all: it is a record of confirmed exploitation in the wild. A KEV entry means the debate about likelihood is over; someone is already doing it.

They answer different questions: how bad, how likely, and is it already happening. Using only the first is why the queue looks like a wall.

The combination that works

The practical algorithm is a ladder, not a formula:

1. KEV present: top of the queue, unconditionally. Confirmed exploitation outranks every theoretical score. These also make the cleanest build-gate criterion: shipping a known-exploited vulnerability is a decision, and it should be an explicit one.
2. High EPSS next, ordered by score. This is where “likely to be attacked soon” lives, and it is usually a mercifully short list.
3. CVSS as the tiebreaker within what remains, restoring severity as the ordering principle once the exploitation signals have had their say.
4. Reachability as a demotion layer throughout. A vulnerable function that your code never calls, in a component that never loads, is real but not urgent. Where call-graph evidence shows a vulnerable component is unreachable, let it demote the finding honestly, and mark unknown-reachability as unknown rather than assumed-safe.

Context multiplies through everything: the same CVE matters more on the internet-facing payment service than in an internal batch tool. Asset criticality is your knowledge, not a feed’s, and it belongs in the scoring.

The offline wrinkle

EPSS updates daily and KEV updates continuously, which sounds like a problem for airgapped environments. It is not, if the signals travel inside your signed vulnerability-data bundle and every report records the bundle version it used. Prioritization stays current to your import cadence, and, unlike ad-hoc feed lookups, the evidence trail shows exactly what the queue knew and when, which auditors notice favorably.

What changes when you do this

Teams that switch from CVSS-sorted to ladder-sorted queues report the same before-and-after: the queue’s top ten stops being arbitrary. Fix-first conversations end because the ordering carries its own justification: “it is being exploited in the wild” and “it is 40 times more likely to be attacked than the one below it” are arguments; “it is a 9.8” is a shrug.

The wall of criticals does not shrink because the vulnerabilities went away. It shrinks because most of it was never the real work, and now the real work has names. That transformation is mechanical once the signals ride with every finding, which is exactly how the SecuNexa dashboard builds its queue: severity, EPSS, KEV, and reachability, combined into one order of work, offline.