Most vulnerability backlogs are triaged on a single number that was never designed to answer the question teams actually ask it: "will this get exploited?" The Common Vulnerability Scoring System (CVSS), maintained by FIRST.Org since 2005, scores theoretical severity on a 0-10 scale — how bad a flaw would be if exploited, assuming worst-case conditions. It says nothing about likelihood. The Exploit Prediction Scoring System (EPSS), also maintained by FIRST under its EPSS Special Interest Group, was built to fill that gap. Rather than a fixed rubric, it's a machine-learning model trained on real-world exploitation signals, and it outputs one number per CVE: the odds that attackers will actually use it in the next 30 days, on a 0-1 scale, with a percentile showing how that CVE stacks up against every other one scored that day. The whole dataset refreshes every 24 hours, and FIRST publishes both the scores and the underlying data as open CSV downloads and via API rather than locking them behind a login. The distinction matters at scale: research underpinning EPSS, published by data scientists including Jay Jacobs and Sasha Romanosky, has repeatedly found that only a small minority of published CVEs are ever observed being exploited — yet CVSS alone routinely marks thousands of CVEs "critical" or "high." This piece walks through what EPSS actually measures, why CVSS alone misprioritizes, and how to combine the two in a real remediation workflow.
What is EPSS and how does it differ from CVSS?
EPSS and CVSS answer two different questions that get conflated constantly. CVSS asks: if this vulnerability is exploited, how bad is the impact — considering attack vector, complexity, privileges required, and effect on confidentiality, integrity, and availability? It's a severity rating assigned largely through expert judgment against a fixed rubric, and it does not change based on what attackers are actually doing. EPSS asks a narrower, more actionable question: given everything currently observed about exploitation activity, scanning behavior, and each CVE's characteristics, what's the probability this specific CVE gets exploited in the next 30 days? EPSS is empirical rather than judgment-based — its model is trained and continuously updated on real-world signals, then scored against every CVE FIRST tracks, daily. A CVE can carry a CVSS score of 9.8 and an EPSS score near 0.01 (1% predicted exploitation probability) at the same time, and both numbers are correct — they're just measuring different things.
Why doesn't a high CVSS score mean high risk?
Because CVSS was never designed to estimate likelihood, and in practice the overwhelming majority of high-severity CVEs never get touched by an attacker. This is the finding that motivated EPSS's creation in the first place: exploitation researchers, including EPSS co-creators Jacobs and Romanosky, have documented that historically only a small single-digit percentage of all published CVEs are ever confirmed exploited in the wild, regardless of how severe their CVSS rating is. A ReDoS flaw and a remote code execution bug can both score 9.x on CVSS if their theoretical impact is severe enough, but the RCE might have a working public exploit circulating on forums while the ReDoS never sees a single documented attack. Teams that triage strictly by CVSS threshold — "fix everything above 7.0" — end up spending remediation cycles on vulnerabilities statistically unlikely to ever be used against them, while a CVE sitting at CVSS 6.5 with rising real-world exploitation activity waits in the same queue.
How do you combine EPSS and CVSS in a remediation workflow?
The two scores are complementary axes, not competing ones — CVSS tells you how bad, EPSS tells you how likely, and the highest-priority work sits where both are elevated. A practical model most teams converge on: treat "CVSS ≥ 7 AND EPSS above a chosen threshold (commonly somewhere in the 0.1–0.5 range depending on risk appetite)" as the SLA-bound critical queue, "CVSS ≥ 7 with low EPSS" as scheduled maintenance rather than an emergency, and "CVSS ≥ 7 with a documented active-exploitation signal such as inclusion on CISA's Known Exploited Vulnerabilities (KEV) catalog" as an immediate, non-negotiable fix regardless of EPSS trend, since KEV listing already confirms exploitation rather than predicting it. Because EPSS is recalculated daily, a CVE's score can climb sharply within days of a public proof-of-concept exploit being released — which means the highest-value workflow doesn't just filter once at disclosure time, it re-evaluates the existing backlog against updated EPSS scores on a recurring basis, catching CVEs that were correctly deprioritized last month but now warrant urgent attention.
What signals should sit alongside EPSS and CVSS?
EPSS and CVSS narrow a backlog, but neither one tells you whether your code can actually be reached by the vulnerable path, which is the signal that turns a probability estimate into a concrete engineering decision. A CVE with a high EPSS score in a transitive dependency your application never calls still carries close to zero real risk to you specifically, no matter how exploitable it is in the abstract. That's why mature prioritization models layer reachability (is the vulnerable function on a call path from an actual entry point), exposure (internet-facing versus internal-only), and business context (asset criticality, data sensitivity) on top of EPSS and CVSS, rather than treating either score as sufficient on its own. FIRST itself frames EPSS as one input among several a security program should weigh, not a standalone replacement for severity scoring or asset context — the model estimates population-level exploitation probability, not certainty for any single deployment.
What are the limits of EPSS scoring?
EPSS is a probability estimate trained on historical and observed exploitation signals, which means it inherits the limits of any predictive model: it can lag genuinely novel attack techniques, it can be skewed by uneven visibility into which CVEs get scanned or discussed publicly, and a low score today is not a guarantee against exploitation tomorrow — it's a snapshot that FIRST updates daily precisely because it's expected to shift. It also only scores CVEs that have been formally published and assigned; a vulnerability discovered and exploited before disclosure (a true zero-day) has no EPSS history to draw on until it's catalogued. None of that undermines its use as a prioritization signal — it just means EPSS answers "where should we look first," not "we're safe everywhere else." Treating it as one weighted input, refreshed continuously, alongside CVSS, KEV status, and reachability is how the model is meant to be used.
How Safeguard helps
Safeguard's Enterprise Software Supply Chain Manager surfaces CVSS Score and EPSS Score side by side on every vulnerability record, sourced from an aggregate feed spanning NVD, GitHub Security Advisories, OSV, CISA KEV, vendor bulletins, and researcher disclosures — and both scores are independently filterable, so a team can query for exactly the "high CVSS, high EPSS, no fix behind a feature flag" intersection instead of scrolling a flat severity list. Griffin AI folds EPSS and CVSS into the same prioritization pass as CISA KEV status, public exploit availability, and call-path reachability analysis, plus business context like asset criticality and internet exposure, so a vulnerability only surfaces as urgent when the probability, severity, and reachability signals actually line up. From there, Griffin AI can generate an AI Remediate pull request directly against the affected dependency, turning a scored, reachable, exploitation-likely finding into a reviewable fix without a team manually re-deriving the same EPSS-plus-CVSS math on every ticket.