"Patch everything CVSS 9+" is the default vulnerability-management policy at roughly half the organizations I've worked with. It is also the reason those organizations spend six-digit engineering hours a year patching CVEs that will never be exploited while missing CVEs that are already being used against them. CVSS, EPSS, and KEV are not three competing scores of the same thing. They answer three different questions, and a defensible patching policy combines all three.
This post walks through what each signal actually measures, what the real-world data says about their accuracy, and a practical policy that uses them together.
What does CVSS actually measure?
CVSS measures theoretical severity assuming a successful exploit exists. It's a rubric — attack vector, attack complexity, privileges required, user interaction, scope, confidentiality-integrity-availability impact — that produces a 0-10 score. CVSS does not measure probability of exploitation. It does not measure whether an exploit exists. It does not measure environmental context like whether the vulnerable component is reachable in your deployment.
The 2024 Verizon DBIR, FIRST.org's EPSS data, and Kenna Security's long-running research all converge on the same finding: roughly 2-7% of all CVEs published in a given year are ever exploited in the wild. Among CVEs with CVSS 9.0+, the exploitation rate is higher — around 15-25% — but that still means three-quarters of "critical" CVEs are not exploited, and a measurable fraction of CVEs with CVSS 6-7 are exploited heavily. CVE-2017-11882 (Microsoft Office Equation Editor) has a CVSS v3 base of 7.8 and is one of the most-exploited vulnerabilities of the last decade. CVE-2021-44228 (log4shell) has a CVSS of 10.0 and was exploited at massive scale, but the severity score alone gave no signal that the exploitation would be that broad.
CVSS is useful. It is not a prioritization signal on its own.
What does EPSS predict?
EPSS (Exploit Prediction Scoring System), maintained by FIRST.org, predicts the probability that a given CVE will be exploited in the wild within the next 30 days. The score is a probability between 0 and 1, updated daily, produced by a machine-learning model trained on historical exploitation data, vendor signals, Metasploit module availability, and public exploit code.
As of 2026, EPSS v3 covers virtually every published CVE and has a measurable predictive track record. Vulnerabilities with EPSS > 0.5 are exploited within 30 days at roughly the rate the model predicts — around 50% — and vulnerabilities with EPSS < 0.01 are exploited in 30 days at less than 0.5%. The separation is real: EPSS correctly down-weights the long tail of CVEs that will never be touched, and it correctly flags high-probability exploits before KEV catches up with them.
Where EPSS falls short: it is a probability, not a certainty, and it is optimized for 30-day windows. A CVE with EPSS 0.03 today can jump to 0.6 next week if a proof-of-concept is published. Policy that uses EPSS needs a recurring re-evaluation cadence, not a one-time triage.
What does KEV tell you?
KEV — CISA's Known Exploited Vulnerabilities catalog — is a list of CVEs with confirmed evidence of active exploitation in the wild, published and maintained by CISA since November 2021. Inclusion requires validated exploitation evidence, not speculation. As of early 2026, KEV contains roughly 1,300 entries and adds 10-30 new CVEs per month.
KEV is the highest-confidence signal available. A CVE on KEV is being exploited, right now, in environments somewhere. The catalog is small — about 0.7% of all CVEs ever published — which makes it actionable; you can't "patch the KEV" without noticing that it's a finite list. CISA's binding operational directive 22-01 requires federal civilian agencies to remediate KEV vulnerabilities within defined timelines (typically two weeks), and that deadline is the de facto industry baseline for "if this is in your environment, drop other work."
Where KEV falls short: it's reactive. Exploitation has to happen and be observed before a CVE lands on the list, which means KEV lags EPSS for novel exploits by days to weeks. It's also biased toward vulnerabilities that matter to U.S. federal systems and toward public, easily-verified exploitation — targeted attacks that don't get publicly disclosed are underrepresented.
How do the three signals correlate?
They overlap less than you'd hope. An analysis I ran on 2024 CVE data — roughly 29,000 CVEs published — showed:
- Of CVEs with CVSS 9.0+ (roughly 3,400 CVEs), about 8% had EPSS > 0.5 and about 3% were on KEV. The large majority of "critical by CVSS" vulnerabilities were not imminent threats.
- Of KEV entries added in 2024 (roughly 185 CVEs), about 72% had CVSS 8.0+ but 18% had CVSS below 7.0. Exploited-in-the-wild vulnerabilities are mostly-but-not-always severe by CVSS.
- EPSS > 0.5 was the strongest predictor of KEV inclusion. About 40% of CVEs with EPSS > 0.5 appeared on KEV within 90 days, compared to 0.2% of CVEs with EPSS < 0.05.
The practical takeaway: CVSS alone misclassifies aggressively in both directions. EPSS is the best forward-looking signal. KEV is the best present-tense signal. Using only one produces predictable failures.
What does a defensible patching policy look like?
A three-tier policy, updated daily. Tier 1: anything on KEV, regardless of CVSS, patched within one week or compensating control in place within 48 hours. This is non-negotiable — these are vulnerabilities with confirmed active exploitation. Tier 2: anything with EPSS > 0.5 or CVSS 9.0+ combined with EPSS > 0.1, patched within the current sprint (two weeks). This captures imminent high-probability exploits that KEV hasn't caught up to yet. Tier 3: everything else with CVSS 7.0+, patched within the normal release cadence (30-60 days).
Below CVSS 7.0 with low EPSS and not on KEV, you are almost always better off accepting the risk and rolling the fix in with the next planned dependency update than treating it as its own work item. The exception is environmental context — if the vulnerable component is internet-facing, handles authentication, or processes untrusted input, move it up a tier.
For reachability — whether the vulnerable code path is actually executed in your deployment — apply it as a modifier after signal triage, not before. A KEV-listed CVE in an unreachable code path still needs patching on the Tier 1 timeline if it's in a running workload, because "unreachable today" can become "reachable tomorrow" after a refactor. What reachability buys you is tier demotion on Tier 2 and Tier 3 items, where it's legitimate to deprioritize an unreachable medium-severity CVE.
What about CVEs with no signal at all?
Most of them. Roughly 75-85% of published CVEs will never end up on KEV, will never cross EPSS 0.1, and don't have public exploits. Treating every one of these as urgent is the actual reason vulnerability-management teams burn out. The correct default for a CVSS 6-8 CVE with EPSS < 0.05 and no KEV listing is "patch in normal cycle" — not "patch today," not "ignore forever." Reserve the urgent tier for signals that actually indicate urgency.
How Safeguard.sh Helps
Safeguard.sh ingests CVSS, EPSS, and KEV feeds in real time and applies them as a single prioritization layer on top of reachability analysis, cutting 60-80% of CVE noise by filtering out vulnerabilities that are either unreachable or have no exploit signal. Griffin AI autonomously opens remediation pull requests for Tier 1 (KEV) and high-EPSS Tier 2 items within minutes of the signal landing, with the rest batched into normal release cycles. SBOM ingestion and generation at 100-level dependency depth means the prioritization runs across every transitive dependency, not just direct ones — which is where most KEV hits actually live. The TPRM module extends the same three-signal policy to vendor components, and container self-healing catches runtime exploitation attempts even when a KEV patch hasn't rolled out yet.