CVSS vs EPSS vs KEV comes down to three different questions. CVSS asks how bad a vulnerability would be if exploited. EPSS asks how likely it is to be exploited in the next 30 days. CISA KEV asks whether it has already been exploited in the wild. None of them knows whether the vulnerable code runs in your environment, so none of them should rank your backlog alone.
The rule that works: treat a KEV listing as a floor, use EPSS to pull likely-exploited findings forward, use CVSS to judge impact, and confirm reachability before anyone writes a fix. This guide compares the three side by side and shows how to combine them.
What CVSS, EPSS and KEV each measure
CVSS: severity if exploited
The Common Vulnerability Scoring System, maintained by FIRST, produces a 0–10 score that describes the severity of a vulnerability relative to other vulnerabilities. The qualitative bands are Low (0.1–3.9), Medium (4.0–6.9), High (7.0–8.9) and Critical (9.0–10.0).
CVSS v4.0 has Base, Threat, Environmental and Supplemental metric groups, and FIRST asks that scores be labeled by the groups used. A score built from Base metrics alone is "CVSS-B." Almost every score a scanner hands you is CVSS-B: a property of the bug class, assessed without your deployment in mind. More detail is in the CVSS glossary entry.
EPSS: probability of exploitation
The Exploit Prediction Scoring System, also run by FIRST, estimates the probability that a published CVE will be exploited in the wild in the next 30 days. It publishes a score between 0 and 1, plus a percentile, every day for every CVE.
EPSS is a forecast, not a severity. A CVSS 9.8 can carry a tiny EPSS score, and a Medium can carry a high one. See the EPSS glossary entry for how the model is built.
CISA KEV: confirmed exploitation
The Known Exploited Vulnerabilities catalog is CISA's authoritative list of vulnerabilities exploited in the wild. It held 1,767 entries when we checked on November 4, 2026. Each entry has a required action and a due date for federal agencies.
KEV is binary and backward-looking. A CVE is either on the list or it isn't, and it gets added after exploitation is seen, not before. The CISA KEV glossary entry covers how entries are added.
CVSS vs EPSS vs KEV at a glance
| CVSS | EPSS | CISA KEV |
|---|
| Question it answers | How bad if exploited? | How likely to be exploited soon? | Has it been exploited? |
| Output | 0–10 score and a severity band | 0–1 probability and a percentile | On the list or not |
| Maintained by | FIRST | FIRST | CISA |
| Updates | When a CVE is scored or rescored | Daily | When CISA adds an entry |
| Coverage | Most published CVEs | Published CVEs | Only confirmed-exploited CVEs |
| Knows your environment | Only if you add Environmental metrics | No | No |
| Covers first-party code bugs | No CVE, no score | No | No |
| Best used for | Judging impact | Ordering what to look at first | Setting a floor nothing drops below |
| Typical failure | Ranks unreachable Criticals first | Misses bugs before signals appear | Silent until after exploitation |
The last two rows matter more than the first five.
Where each score fails when it ranks alone
CVSS alone floods the queue
If every CVSS 9.0+ finding is a Critical, the Critical queue fills with findings in test fixtures, build-only dependencies and internal services. The score is correct about the bug class and silent about your code.
A finding is a guess about impact. The deployment decides whether that guess applies.
EPSS alone misses what hasn't happened yet
EPSS is trained on observed exploitation activity. A newly disclosed CVE with no public exploit yet can score low on day one and jump within a week. A team that ignores everything below an EPSS cutoff is betting that the model sees the attack before the attacker launches it.
EPSS also has nothing to say about your own code. A broken authorization check in your billing API has no CVE, so it has no EPSS score either.
KEV alone is too small and too late
KEV is the strongest single threat signal because it's confirmed. It's also a short list compared with the number of CVEs published each year, and every entry arrived after someone was attacked. Using KEV as your only filter means you fix what was exploited last month and wait on everything else.
None of them knows whether the code runs
This is the shared gap. All three scores describe a CVE in the abstract. Whether the vulnerable function is imported, called from a reachable path, and deployed to production is a question about your repository, not about the vulnerability database.
How to combine CVSS, EPSS and KEV
Use each score for the one thing it's good at, and add the signal none of them has.
1. Make KEV a floor
A KEV listing should never drop out of view because of a CVSS band or an EPSS cutoff. If the affected component is deployed, it goes to the top tier. If static analysis says the vulnerable code isn't reachable, record that verdict and the evidence, and keep the finding visible rather than closing it.
2. Use EPSS to order what to look at next
Below the KEV floor, EPSS is the best public signal for "look at this first." Sort by EPSS percentile, not by the raw probability, because percentiles are easier to set policy on and more stable from day to day.
3. Use CVSS for impact, not urgency
CVSS answers "how bad if it lands." Use it to separate a remote code execution from an information leak once a finding has made it into the queue. Where you can, add Environmental metrics so the score reflects your deployment instead of the worst case.
4. Confirm reachability before anyone writes a fix
Check that the vulnerable code is present in the deployed artifact and reachable from untrusted input. A reachable Medium with a high EPSS score is more urgent than an unreachable Critical with none.
5. Score first-party findings on the same scale
SAST, secrets and API findings don't have CVEs. Rank them by the same factors the three scores stand in for: impact, likelihood and exposure. Otherwise your dependency findings get a rigorous process and your own code gets a guess.
A decision matrix you can use today
Use this as a starting point and adjust the tiers to your own risk appetite. It assumes the finding has been confirmed present in a deployed component.
| Tier | Rule | Why |
|---|
| 1 | On KEV, or exploit evidence in your environment, and reachable | Confirmed exploitation, confirmed path |
| 2 | Top EPSS percentiles and reachable, any CVSS band | Likely to be exploited soon, and it can be |
| 3 | CVSS High or Critical, reachable, low EPSS | Bad if it lands, no current signal |
| 4 | CVSS Medium or Low, reachable, low EPSS | Fix in normal sprint work or as a campaign |
| 5 | Not reachable or not deployed | Record the evidence, re-check when code or dependencies change |
Two notes on the matrix:
- Tier 5 is not "false." An unreachable finding is real, just not reached. Keep the verdict and re-triage when the code changes.
- Public exposure moves findings up a tier. CISA's BOD 26-04 sets federal remediation urgency from public exposure, KEV status, exploit automation and technical impact. That's a useful pattern for anyone.
Common mistakes when ranking with these scores
- Treating CVSS-B as your risk score. The base score was never meant to know your environment.
- Setting a hard EPSS cutoff and closing everything below it. Use EPSS to order work, not to dismiss it.
- Waiting for KEV. By the time a CVE is listed, it has already been used against someone.
- Ranking dependencies and first-party code on different systems. The backlog is one queue to the engineer who has to fix it.
- Throwing away the evidence. Record why each finding landed in its tier, so the next reviewer can audit the decision instead of redoing it.
How Nullify ranks vulnerabilities beyond CVSS, EPSS and KEV
Nullify's triage scores every finding continuously on reachability, exploitability, business context and confidence, and keeps severity (abstract risk) separate from priority (urgency in your environment). Unreachable code, test fixtures and benign configuration are filtered before a person reviews them. When code, dependencies or threat intel change, findings are re-triaged automatically, and human overrides persist through re-triage.
Actively exploited vulnerabilities that affect technologies you use move up the backlog. For REST and GraphQL APIs, the pentest agent goes further and proves the exploit with request and response evidence. Confirmed findings get a minimal, root-cause fix that's validated against your build before the pull request opens, and your engineers approve every merge. See how it works on the triage and remediation page.
Frequently asked questions
What is the difference between CVSS and EPSS?
CVSS measures how severe a vulnerability would be if it were exploited, on a 0–10 scale. EPSS estimates the probability that a published CVE will be exploited in the wild in the next 30 days, on a 0–1 scale. CVSS describes impact and EPSS describes likelihood, so they answer different questions and work best together.
Is EPSS better than CVSS?
Neither is better on its own. EPSS is a stronger signal for deciding what to look at first, because it reflects real exploitation activity. CVSS is better for judging how much damage a successful exploit would cause. Use EPSS to order the queue and CVSS to weigh impact once a finding is in it.
Should every CISA KEV vulnerability be fixed first?
Every KEV vulnerability in a deployed, reachable component should go to the top tier. If the affected code genuinely isn't deployed or reachable, record that evidence and keep the finding visible instead of closing it. KEV is a floor, not an automatic override of everything you know about your environment.
Do CVSS, EPSS and KEV cover first-party code?
No. All three describe published CVEs. Vulnerabilities in your own code, such as an injection flaw or a broken authorization check found by SAST, have no CVE, so they have no CVSS, EPSS or KEV entry. Rank them on the same factors of impact, likelihood and exposure.
