CVSS, EPSS and KEV: how to prioritize dependency vulnerabilities

By Rushabh Shah, Senior Software Developer · 2026-06-20

Every week a dependency scanner finds dozens of vulnerabilities. Every week most developers ignore them, because there is no time to fix 200 issues and no obvious way to know which 3 actually matter. The answer lives in three numbers: CVSS, EPSS and KEV.

CVSS: severity, not risk

The Common Vulnerability Scoring System (CVSS) gives every published CVE a score from 0 to 10 based on how bad the vulnerability could be in a worst-case scenario. The problem is that CVSS scores are entirely theoretical. In practice, fewer than 5% of published CVEs are ever exploited in the wild. A CVSS 9.8 in a library feature you don't use is a lower priority than a CVSS 6.0 actively used in ransomware campaigns. Sorting by CVSS alone means sorting by worst-case theory, not real-world risk.

EPSS: exploitation probability

The Exploit Prediction Scoring System (EPSS), maintained by FIRST, is a machine-learning model trained on actual exploitation evidence — threat intelligence feeds, honeypot data and proof-of-concept exploit activity. It produces a daily probability score (0–1) for the likelihood that a given CVE will be exploited in the next 30 days. The top 1% of CVEs by EPSS account for roughly 75% of observed exploitation attempts. Filter to CVEs with EPSS above 10% and your fix list shrinks dramatically while still covering the overwhelming majority of real attacks. EPSS is updated every day.

KEV: confirmed exploitation in the wild

The CISA Known Exploited Vulnerabilities (KEV) catalog is the most reliable signal. CISA maintains a manually curated list of vulnerabilities confirmed exploited in real-world attacks. These aren't predictions — they're facts. If a CVE is in the KEV catalog, attackers have working exploits and are using them. KEV findings are always your highest priority, regardless of CVSS.

A worked example

Suppose a scan returns five findings: A (CVSS 9.8, EPSS 0.94, KEV-listed, fix available), B (CVSS 9.1, EPSS 0.02, not KEV, fix available), C (CVSS 7.5, EPSS 0.03, fix available), D (CVSS 6.5, EPSS 0.61, fix available), E (CVSS 5.3, EPSS 0.01, no fix). Sorted by CVSS alone: A, B, C, D, E — B outranks D despite D being far more likely to actually be exploited. Sorted by KEV then EPSS then CVSS: A first (KEV-listed and highest EPSS), then D (EPSS 0.61 puts it in the top slice of real exploitation activity, ahead of the higher-CVSS but low-EPSS B), then B and C (real bugs, low real-world pressure — bundle into a routine bump), then E (lowest EPSS, no fix, weakest CVSS — accept and monitor). The CVSS-only ranking would have burned a week on B before D, the finding attackers were actually using.

Common mistakes with these three signals

Treating CVSS as a risk score (it measures theoretical severity, not likelihood) — a "no CVSS >= 7" CI gate spends effort on findings nobody exploits while a lower-CVSS, high-EPSS finding sits unpatched. Ignoring EPSS because it moves — a score of 0.02 today can become 0.80 within days of a public exploit landing, so it needs re-checking, not a one-time look. Treating a KEV removal as "safe now" — it means active campaigns moved on, not that the bug is fixed. And trying to perfectly rank the whole backlog instead of just clearing the KEV-listed and high-EPSS findings first and re-triaging weekly.

A practical priority order

Fix KEV-listed findings with a fix available this week. Fix findings with EPSS above 0.20 and a fix available in the current sprint. Schedule Critical-CVSS/low-EPSS findings behind these. Accept and monitor Medium findings with no fix. Beyond these scores, direct dependencies warrant higher priority than the same CVE buried deep in the transitive tree. DepWarden fetches EPSS and KEV daily alongside the OSV mirror and uses all of these signals for its "Fix these first" list. See also: SAST vs SCA and what is a SBOM?.