EPSS vs CVSS: Why "Critical" Doesn't Mean "Fix First"

CVSS answers how bad would exploitation be — a severity score from 0 to 10 built from the vulnerability's characteristics. EPSS answers a different question entirely: how likely is this vulnerability to be exploited in the wild in the next 30 days — a probability from 0 to 1, re-estimated daily by FIRST from real exploitation telemetry. Teams that treat CVSS as a priority queue are sorting by the wrong axis: most critical-severity CVEs are never exploited at all, while some medium-severity ones are exploited within days.

The two scores are not competitors; they are orthogonal axes. Every vulnerability in your backlog sits somewhere on the plane they span, and the quadrant it lands in is the priority decision:

• It is population-level, not your-environment-level. EPSS models the internet's exploitation activity; it does not know your firewall rules, your compensating controls, or whether the vulnerable path is even reachable in your deployment.
• It lags novel targeting. A probability model built on observed activity is quiet right up until activity is observed. Pair it with CISA's KEV catalog — KEV is confirmed exploitation, and membership overrides any score.
• A low score is not permission to ignore. It is permission to schedule rather than to interrupt — which is precisely the distinction a priority system exists to make.

The practical version is a risk score that folds both axes together. When a Webcuris scan finds a vulnerable dependency — including a package name an AI invented, the finding's risk is computed from severity and the advisory's EPSS probability, alongside confidence and asset exposure — so the list you read is already in fix-first order, and a medium with a 0.9 exploitation probability outranks a critical with a 0.0004. The raw scores stay visible on every finding, because a prioritisation you cannot audit is a prioritisation you cannot trust.