EPSS vs CVSS: which number sorts the queue

A backlog sorted by CVSS is sorted by how bad a vulnerability would be if somebody used it. EPSS sorts by whether anybody is likely to. Both numbers are useful and they are not substitutes, but teams keep reaching for one when the decision in front of them needs the other.

What each number actually measures

CVSS is a severity model. It scores the intrinsic properties of a weakness — attack vector, complexity, privileges required, the impact on confidentiality, integrity and availability — and produces a 0–10 base score. Nothing in that calculation knows whether exploit code exists, whether it is being used, or whether you are running the affected component in a way that is reachable.

EPSS is a probability model. It is maintained by FIRST and estimates the likelihood that a published CVE will be exploited in the wild in the next 30 days, published daily as a score from 0 to 1 plus a percentile rank against every other scored CVE. The current model, v5, began publishing on 15 June 2026.

	CVSS	EPSS
Question answered	How bad if exploited?	How likely to be exploited?
Range	0–10 severity	0–1 probability, plus percentile
Changes over time	Only if rescored	Daily
Knows about your environment	No	No

That last row is the one people skip. Neither score knows what you run, what is internet-facing, or what sits behind three layers of authentication. Exposure is yours to supply.

Where CVSS-only sorting goes wrong

Most published CVEs are never exploited by anyone. Sorting purely by severity means the top of the queue is dominated by the largest group — high-scoring issues nobody has weaponised — while a medium-scoring bug with working public exploit code and active scanning against it sits below the fold. The queue is correctly ordered by a property that is not the one driving your risk this week.

The mirror failure is real too: EPSS-only sorting deprioritises a genuinely catastrophic issue simply because it is new and quiet. A high-impact vulnerability with a low probability today can become the one everyone is patching at 3am on Friday, and the probability moves after the exploitation starts, not before.

A workable order of operations

Use them as filters in sequence rather than as competing sort keys.

1. Is it reachable from outside? A finding on an asset with no public path is not an emergency regardless of either number.
2. Is it on CISA's KEV catalogue? Confirmed in-the-wild exploitation ends the discussion. Patch it.
3. Then EPSS, to rank what is left by likelihood of near-term exploitation.
4. Then CVSS, to break ties and to decide how much damage control a successful exploit would need.

Exposure comes first because it is the only input that is specific to you. Both scoring systems describe a vulnerability in the abstract; only your scan data says whether the affected service answers on a public IP. That is the same argument as why a CVSS score alone is not a priority, extended by one number.

What this means for the backlog

Adding EPSS to a triage process does not shorten the backlog. It changes which end of it you work from, and it makes the ordering something you can defend in a review: this was patched first because exploitation was probable and the service was reachable, not because a number was red.

CyberSpec attaches CVE identifiers, CVSS scores and vectors, and CWE references to every finding, and tracks which findings sit on externally reachable assets so exposure is a filter rather than a guess. See vulnerability management.