Kenna Security and the Cyentia Institute found that of the roughly 18,000 CVEs published in 2019, only 473 — 2.6% — were ever observed being actively exploited in a way likely to affect enterprises, and just 6% of those 473 reached exploitation at more than 1% of organizations. That gap between "high CVSS score" and "actually attacked" is the central problem in vulnerability management: a security team with 400 open CVE tickets, all triaged by CVSS Base Score alone, is very likely burning sprints on vulnerabilities no attacker will ever touch while genuinely dangerous ones sit at a middling 6.5. CVSS was never designed to answer "will this be exploited" — it scores theoretical severity, not observed attacker behavior. Closing that gap requires layering in purpose-built signals: EPSS's probability-of-exploitation forecast, CISA's Known Exploited Vulnerabilities catalog as a confirmed-exploitation ledger, and reachability plus exploit-maturity data to strip out the noise CVSS and CVE volume alone can't resolve. This post lays out a practical framework for combining all four.
Why isn't CVSS score enough on its own?
CVSS Base Score measures the theoretical impact and basic exploitability of a flaw in isolation — confidentiality/integrity/availability impact, attack vector, privileges required — but it has no concept of whether that flaw is being exploited anywhere, or ever will be. A CVSS 9.8 critical and a CVSS 9.8 critical look identical in a ticket queue even if one has a Metasploit module and a live campaign behind it and the other has never had public exploit code written for it. Cyentia's research across the Prioritization to Prediction series has repeatedly found that CVSS score alone is a weak predictor of actual exploitation: a large share of "critical" CVSS-scored vulnerabilities are never exploited, while some medium-scored ones are. CVSS 4.0, published by FIRST in 2023, added optional Threat and Supplemental metric groups specifically to address this gap, but most scanners still report only the Base score, which is the number teams end up triaging by default.
What does EPSS actually predict, and how does it work?
EPSS (Exploit Prediction Scoring System) is a machine-learning model maintained by FIRST.org — the same nonprofit that stewards CVSS — that outputs a 0-to-1 probability that a given CVE will be observed being exploited in the wild in the next 30 days, updated daily. EPSS v2, released in February 2022, moved to a gradient-boosted decision tree model (XGBoost) trained on CVE metadata (age, CWE category, CVSS vector components), exploit-code signals (Metasploit modules, Exploit-DB entries, public GitHub proof-of-concept repos), and reference/discussion activity; v3 (March 2023) expanded that feature set further, and v4 (March 2025) added contextual threat-intel signals like malware and endpoint-detection telemetry. Because raw probabilities cluster very low — FIRST's own published statistics show an EPSS score of just 0.10 already sits around the 88th percentile of all scored CVEs — FIRST also publishes a percentile rank, so a CVE at 0.02 probability but the 70th percentile is still more urgent than the median CVE. Data is free via CSV download or API at first.org/epss.
What does the CISA KEV catalog add that EPSS doesn't?
CISA's Known Exploited Vulnerabilities (KEV) catalog is a curated list of CVEs with confirmed, observed real-world exploitation. Federal civilian executive branch agencies were long required to remediate KEV entries on a mandated deadline under Binding Operational Directive 22-01; CISA revoked BOD 22-01 in 2026 and replaced it with BOD 26-04, which keeps KEV status as one input but sets remediation deadlines using a broader risk model — asset exposure, KEV status, exploit automation potential, and technical impact. Where EPSS is a forward-looking probability, KEV is a backward-looking confirmation: CISA only adds a CVE once it has evidence of exploitation, and the catalog is updated frequently — CISA has logged dozens of separate addition alerts through 2026 alone, typically adding a handful of CVEs at a time. The two signals are complementary rather than redundant: a CVE can carry a high EPSS score for weeks before any confirmed incident lands it in KEV, and a CVE can appear in KEV even with a modest CVSS score if it happens to be the entry point a specific campaign favors. Any CVE on the KEV list should be treated as a "stop and patch" item regardless of what its CVSS or EPSS number says, since exploitation is no longer hypothetical.
What is reachability analysis and why does it change the priority order?
Reachability analysis determines whether the vulnerable function inside a flagged dependency or code path can actually be invoked from your application's entry points, rather than just confirming the vulnerable package version is present in your manifest. A standard SCA scan matches your lockfile against a CVE database and reports every match, whether or not your code ever calls the affected function; a reachability engine builds a call graph from your app's entry points down through direct and transitive imports and checks if execution can reach the vulnerable line at all. This matters because a large share of dependency-scan findings in typical applications sit in code paths that are never invoked at runtime — an unreachable CVE, even a critical one, cannot be exploited through your application no matter how attractive it looks in a report. Reachability doesn't replace EPSS or KEV; it answers a different question ("can an attacker even get here through my app") that neither score addresses.
What is exploit maturity, and how does it sit alongside CVSS Temporal metrics?
Exploit maturity describes how far a vulnerability has progressed from theoretical to weaponized — no known exploit code, a public proof-of-concept, a working exploit integrated into a framework like Metasploit, or confirmed use in an active campaign — and it's the same concept CVSS's Temporal (in CVSS v3.1) and Threat (in CVSS v4.0) metric groups try to capture with an Exploit Code Maturity value. In practice, most vulnerability databases don't populate Temporal/Threat metrics consistently, which is exactly why EPSS exists as a standardized, always-updated substitute: it encodes exploit-code availability (Exploit-DB, Metasploit, GitHub PoCs) as one of its core model inputs rather than leaving it as an optional manual field. Combining exploit maturity with reachability answers two separate questions that both have to be "yes" for a finding to be genuinely urgent: is there a way to attack this (maturity), and can an attacker reach it in my specific deployment (reachability).
How do you combine these signals into one triage workflow?
A workable triage order layers the signals from broadest to narrowest: first pull any CVE on the CISA KEV catalog to the top regardless of score, since exploitation is already confirmed; second, rank the remainder by EPSS percentile rather than raw CVSS to separate the CVEs attackers are statistically likely to weaponize from the long tail that never will be; third, filter both groups through reachability analysis to drop anything your application can't actually execute; and finally use exploit maturity as a tiebreaker within what's left — a reachable, high-EPSS CVE with a public Metasploit module outranks a reachable, high-EPSS CVE with no exploit code yet. This ordering directly targets the finding from Kenna/Cyentia's research that prioritizing by exploit-code availability was measured as roughly 11 times more effective at reducing organizational exploitability than prioritizing by CVSS alone, because it spends remediation capacity on the narrow set of vulnerabilities where probability, confirmation, and reachability all line up.
How Safeguard helps
Safeguard's reachability engine traces every SCA finding through your application's real call graph so a CVE only carries urgency when your code can actually execute the vulnerable path, which is the piece that CVSS, EPSS, and KEV data alone can't tell you. Because reachability and exploit-likelihood scoring answer different questions, Safeguard treats them as complementary layers rather than collapsing them into a single opaque number: AutoTriage deduplicates and correlates findings across scanners to cut ticket noise before prioritization even starts, and Griffin AI can explain why a specific finding is or isn't reachable in plain language so engineers don't have to manually trace a call graph to trust the verdict. That combination — noise reduction, reachability, and clear explanations — is what turns a 400-item CVE backlog into the dozen or so findings that genuinely warrant a sprint.
