Vulnerability Prioritization: CVSS, EPSS and What Actually Matters
- CVSS answers "how bad if exploited". EPSS answers "how likely to be exploited". They are different questions and CVSS alone is a weak sort key.
- CISA KEV is the strongest single signal available: it records what is being exploited in the wild right now.
- None of the three knows whether the vulnerable code is reachable in YOUR application. That context beats all of them.
- A validated exploit outranks every score, because it has removed the uncertainty the scores exist to estimate.
CVSS measures how severe a vulnerability would be if exploited. EPSS estimates how likely it is to be exploited. CISA KEV records what is actually being exploited right now. Most teams sort by the first one alone, which is why remediation queues are simultaneously enormous and misaligned with real risk.
The three are complements, not competitors, and there is a fourth input that beats all of them.
CVSS: severity, not urgency
The Common Vulnerability Scoring System, maintained by FIRST, produces a 0 to 10 score from characteristics of the vulnerability: how it is accessed, how complex exploitation is, what privileges are needed, and what the impact would be on confidentiality, integrity and availability. Version 4.0 restructured this into base, threat, environmental and supplemental metric groups; version 3.1 is still widely used in tooling and reporting.
What it is good for is a consistent, vendor-neutral description of how bad something would be. What it is not is a work queue. A 9.8 in a component your application never invokes is less urgent than a 6.5 on your login endpoint, and CVSS has no way of knowing that.
One more trap: the score you usually see is the BASE score, which deliberately excludes your environment. The environmental metrics exist precisely so you can adjust it, and almost nobody does.
EPSS: likelihood, not severity
The Exploit Prediction Scoring System, also from FIRST, outputs a probability that a given vulnerability will be exploited in the wild within the next thirty days. It is built from observed exploitation activity and vulnerability characteristics, and it is updated continuously.
It answers the question CVSS cannot: of the many severe things on my list, which are attackers actually going for. The overwhelming majority of published vulnerabilities are never exploited at scale, and EPSS is how you tell the difference between theoretical and active.
Its limitation is the mirror of CVSS: a high probability tells you nothing about the consequence for you.
KEV: observed reality
The CISA Known Exploited Vulnerabilities catalogue is not a score. It is a list of vulnerabilities confirmed to be exploited in the wild. If something you have is on it, the debate about likelihood is over.
As a single signal it is the strongest of the three, and the narrowest - it only contains what has been observed and confirmed, so absence from KEV is not evidence of safety.
| Question answered | Form | Blind to | |
|---|---|---|---|
| CVSS | How bad if exploited | 0 to 10 score | Likelihood, and your environment |
| EPSS | How likely to be exploited | Probability, next 30 days | Impact on you |
| KEV | Is it being exploited now | Yes or no list | Anything not yet observed |
| Reachability | Can it be reached in MY app | Context, not a score | Nothing - this is the missing input |
The input that beats all three
None of the three scoring systems knows anything about your application. They describe a vulnerability in the abstract. Whether the affected code path is reachable from untrusted input in your deployment is a property of your system, and it routinely changes the answer completely.
This is why a dependency scan can report forty critical findings and a competent engineer can dismiss thirty of them in an afternoon. The severity was accurate; the relevance was not established.
The ranking that actually works, in order: something we proved is exploitable in our application, then something on KEV that we can confirm we expose, then high EPSS combined with high impact, then everything else. CVSS alone is where that list ends, not where it starts.
Why validation reorders everything
A validated exploit removes the uncertainty that these scoring systems exist to estimate. CVSS and EPSS are both, at bottom, ways of guessing about exploitability at a distance. If a test has already demonstrated the exploit against your own application, the guess is unnecessary. See exploit-validated penetration testing for what that demonstration looks like as a delivered service.
That is the argument for spending effort on validation rather than on ever more elaborate scoring: a proven finding needs no prioritisation model, it needs a fix. Everything else is triage, and triage is exactly where scoring belongs.
Frequently asked questions
What is the difference between CVSS and EPSS?
CVSS scores how severe a vulnerability would be if exploited. EPSS estimates the probability that it will be exploited in the wild in the next thirty days. Severity and likelihood are different questions, so using CVSS alone as a work queue misaligns effort.
Should I prioritise vulnerabilities by CVSS score?
Not on its own. A CVSS 9.8 in a component your application never calls is less urgent than a moderate issue on your authentication endpoint. CVSS deliberately excludes your environment, which is the input that most often changes the answer.
What is the CISA KEV catalogue?
A published list of vulnerabilities confirmed to be exploited in the wild. It is the strongest single prioritisation signal available, because it replaces estimated likelihood with observed activity. Absence from the list is not evidence of safety, only of nothing having been confirmed yet.
What should I prioritise above a high CVSS score?
Anything proven exploitable in your own application, then anything on CISA KEV that you can confirm you expose. A validated finding removes the uncertainty that scoring systems exist to estimate, so it needs a fix rather than a score.