The Shift from CVSS to EPSS: Prioritizing GitHub Security Alerts by Exploitability

The Shift from CVSS to EPSS Prioritizing Git Hub Security Alerts by Exploitability
Back to blog
The Core Problem: Drowning in GitHub Alerts
What CVSS Measures — and Where It Falls Short
EPSS: A Score That Moves With the Threat
Two Different Questions: EPSS vs. CVSS
How GitHub Puts This to Work
Turning Prioritization into Enforcement: CISA's BOD 26-04
Conclusion: Stop Chasing Ghosts
The Shift from CVSS to EPSS: Prioritizing GitHub Security Alerts by Exploitability
Security teams have more visibility into their codebase's vulnerabilities than ever before, and that's exactly the problem. For teams relying on GitHub Dependabot and code scanning, the volume of alerts generated daily can paralyze engineering velocity long before it improves security.

For nearly two decades, the industry leaned on one metric to triage this flood: the Common Vulnerability Scoring System (CVSS). But CVSS alone is a recipe for alert fatigue, and the data backs that up. This piece walks through why the industry has been shifting toward the Exploit Prediction Scoring System (EPSS), how GitHub has actually built this into Dependabot, and how the U.S. government's own vulnerability-remediation rules changed in 2026 to reflect the same risk-based thinking.

The Core Problem: Drowning in GitHub Alerts
The numbers have only gotten worse. Roughly 48,000 CVEs were published in 2025 — a ninth consecutive annual record, and a jump from about 40,000 the year before. CVE submissions grew 263% between 2020 and 2025, and the first quarter of 2026 came in nearly a third higher than the same period in 2025.

The National Vulnerability Database (NVD), which most tooling depends on for severity scoring and metadata, has openly admitted it can't keep pace. NIST enriched almost 42,000 CVEs in 2025 — 45% more than any prior year — and still fell behind. In April 2026, NIST changed its approach: rather than trying to enrich every CVE, it now prioritizes only vulnerabilities that appear in CISA's Known Exploited Vulnerabilities (KEV) catalog, affect software used by the federal government, or qualify as "critical software" under Executive Order 14028. Everything else is now marked "lowest priority" and may sit unenriched indefinitely.

That backlog problem compounds the original triage problem. Historically, teams sorted alerts by CVSS score and worked down from "Critical." As a result, they spent weeks patching vulnerabilities with high theoretical severity and zero real-world exploitation, while lower-scored vulnerabilities were actively being weaponized elsewhere. Multiple independent estimates put the share of CVEs that are ever actually exploited in the wild at somewhere between roughly 2.5% and 5%. Treating every "Critical" as an emergency burns out engineering teams and, ironically, still leaves the truly dangerous 3-5% of vulnerabilities under-prioritized relative to the noise around them.

What CVSS Measures — and Where It Falls Short
CVSS is maintained by the Forum of Incident Response and Security Teams (FIRST). It's fundamentally a measure of technical severity: it evaluates a vulnerability's attack vector, attack complexity, required privileges, user interaction, and potential impact on confidentiality, integrity, and availability. Scores run from 0.0 to 10.0, with 9.0–10.0 categorized as Critical.

CVSS 4.0, released by FIRST in November 2023, restructured the model around four metric groups (Base, Threat, Environmental, Supplemental), dropped the widely-criticized "Scope" metric, and added new impact metrics like Automatable and Safety. But adoption has been gradual: as of early 2026, CVSS v3.1 remains the version most widely deployed in practice, and NVD still publishes v3.1 as its primary score for most CVEs alongside v4.0 data where available. NVD has not committed to retroactively rescoring its historical CVE catalog under v4.0.

The underlying limitation hasn't changed across versions: CVSS scores a vulnerability in isolation, without reference to whether anyone is actually trying to exploit it. A CVSS score assigned in 2020 will typically look identical in 2026 unless new technical details emerge. A 9.8 with no known exploit code and no attacker interest represents a very different real-world risk than a 9.8 that's being actively weaponized — and CVSS alone can't tell you which is which.

EPSS: A Score That Moves With the Threat
The Exploit Prediction Scoring System was introduced at Black Hat in 2019, with FIRST forming a dedicated Special Interest Group in 2020 and public daily scoring beginning in January 2021. It has been revised repeatedly since:

v1 (2018–2021): A simple logistic regression model with 16 variables, originally designed to run in a spreadsheet.
v2 (February 2022): Moved to a full machine-learning model with over 1,000 variables.
v3 (March 2023): Expanded further, to roughly 1,500 variables and refined data sources.
v4 (March 2025): Added broader threat-intelligence feeds and more frequent score refreshes throughout the day.
v5 (May 2026): The current version, built by Empirical Security (co-founded by EPSS co-creator Jay Jacobs). On the benchmark FIRST uses to measure the model — where a random guess scores around 0.025 and a perfect model scores 1.0 — v5 scored 0.633 versus v4's 0.514, a roughly 23% improvement in the model's ability to correctly rank exploited vulnerabilities above non-exploited ones. It now scores more than 318,000 published CVEs.
Unlike CVSS, EPSS is entirely data-driven. It pulls from the MITRE CVE list, published exploit code in places like ExploitDB, Metasploit, and GitHub repositories, security scanner telemetry, and CVSS base metrics from NVD, then estimates the probability that a given CVE will be exploited in the wild in the next 30 days. Two numbers come out of the model daily:

Probability score (0–1): e.g., a score of 0.89 means an estimated 89% chance of exploitation in the next 30 days.
Percentile: how that CVE ranks against every other scored CVE — a 95th-percentile score means it's riskier than 95% of everything else in the dataset.
Because the model runs daily against live threat data, a CVE's EPSS score can move dramatically over its lifetime, even while its CVSS score stays frozen.

Two Different Questions: EPSS vs. CVSS
The EPSS-vs-CVSS framing isn't about which system is "better" — they answer different questions. CVSS asks "how bad would this be if exploited?" EPSS asks "how likely is this to be exploited soon?" A common analogy: CVSS measures the size of a potential fire; EPSS estimates whether someone is currently holding a lit match.

The mismatch between the two shows up constantly in real CVE data. CVE-2021-45105, a Log4j-related denial-of-service flaw, carries a CVSS score of just 5.9 — Medium severity, the kind of thing many teams would push to the backlog. But it sits in the 99th percentile of EPSS scores, meaning it's more exploitation-prone than almost anything else in the dataset. It should be prioritized over plenty of "Critical" CVEs with negligible EPSS scores.

The reverse pattern is just as common. CVE-2024-0646, a Linux kernel vulnerability, carries a CVSS score of 7.0 (High) — but an EPSS score of only about 0.04%, because exploitation requires local access and narrow, specific conditions that make it an unattractive target for real-world attackers. By CVSS alone, it looks urgent. By actual attacker behavior, it barely registers.

How GitHub Puts This to Work
GitHub has built EPSS directly into its security tooling rather than leaving it as an external lookup. EPSS scores first appeared in the GitHub Advisory Database in late 2024, and became generally available inside Dependabot alerts in February 2025. Each alert now shows both the EPSS probability and its percentile — GitHub's own example: a 90.5% EPSS score at the 95th percentile means a 90.5% estimated chance of exploitation in the next 30 days, and a ranking above 95% of all other scored vulnerabilities.

The scale of the signal is what makes it useful for triage: GitHub notes that only about 0.5% of all vulnerabilities carry an EPSS score above 50%. That scarcity is the point — a high EPSS score is a genuinely rare, high-signal event, which is exactly why filtering on it works so much better than filtering on CVSS "Critical," a bucket that a much larger share of CVEs fall into.

GitHub has continued building around this. Custom auto-triage rules can now dismiss, snooze, or route alerts into pull requests based on metadata that includes severity, package, CWE, EPSS score, and patch availability — free for public repositories, and part of GitHub Advanced Security for private ones. Dismissed alerts stay available for reporting and can automatically reopen if the underlying metadata changes. More recently, eligible Dependabot alerts can be assigned directly to AI coding agents (including Copilot and supported third-party agents), which will attempt to open a draft pull request with a fix. None of this replaces judgment — a dismissal is still a policy decision — but it turns EPSS from a number on a dashboard into something that actually reduces the manual triage load.

Turning Prioritization into Enforcement: CISA's BOD 26-04
Identifying the most dangerous vulnerabilities is only half the job — the other half is actually enforcing remediation on a deadline, and there's now a real-world, public example of what that looks like at scale.

On June 10, 2026, CISA issued Binding Operational Directive 26-04: Prioritizing Security Updates Based on Risk, which governs vulnerability remediation across U.S. federal civilian agencies. It formally revokes the two directives that came before it — BOD 19-02 (2019) and BOD 22-01 (2021) — and replaces flat, severity-only patch mandates with a structured, four-factor risk model. Under BOD 26-04, agencies must assess whether a vulnerability:

affects a publicly exposed asset,
appears in CISA's Known Exploited Vulnerabilities catalog,
is realistically automatable or subject to mass exploitation, and
grants an attacker significant technical impact, such as full control of the affected system.
A vulnerability that meets all four criteria must be remediated within three days — along with a forensic triage step to check whether the system may already have been compromised before the fix was applied. Lower-risk vulnerabilities are explicitly deprioritized rather than treated as equally urgent. CISA has said the directive is partly a response to AI-accelerated vulnerability discovery compressing the window between disclosure and weaponization — the same pressure driving the CVE volume numbers above.

It's a near-exact mirror of the "emergency campaign vs. standard backlog vs. silent killer" tiering that security teams have been building informally with CVSS-plus-EPSS matrices for the past few years — just now codified as binding federal policy, with KEV status and exploitability as first-class inputs alongside severity. Organizations building their own internal SLA tooling now have a public, well-documented reference model to work from, rather than reinventing this logic from scratch.

Conclusion: Stop Chasing Ghosts
With CVE volume setting records nine years running and NVD publicly acknowledging it can no longer enrich everything, organizations can't afford to spend limited engineering time on hypothetical risk. Combining CVSS's severity view with EPSS's exploitability signal — and now, increasingly, with regulatory frameworks like BOD 26-04 that formalize risk-based deadlines — gives security teams a genuine way to cut through the noise.

True risk-based vulnerability management was never about fixing everything. It's about having the data and the automated systems in place to guarantee you fix the right things, right now.