CVSS is a broken prioritization tool: use KEV and EPSS

All four images verified. Now I'll write the post.

The number that broke triage

A mid-sized company runs a vulnerability scan on a Monday morning and gets back a report with 4,000 findings. Roughly a third of them are flagged red: "Critical" or "High." No security team on earth patches 1,300 things in a week. So someone has to choose. For most of the last decade, the tool that made that choice was a single number between 0.0 and 10.0, the Common Vulnerability Scoring System score. And for most of the last decade, that number has been quietly pointing teams at the wrong bugs. The scale of the problem has grown faster than almost anyone planned for. More than 40,000 vulnerabilities, each with its own CVE identifier, were published in 2024, and 2025 came in higher still, according to reporting on the CVE surge; submissions rose 263% between 2020 and 2025. Against that flood, the CVSS "High and Critical" band, everything scoring 7.0 or above, covers well over half of all published CVEs. Telling a team to "fix the criticals" is, at this point, telling them to fix most of the internet.

The fix is not a better severity score. It is to stop using severity as the ordering rule at all, and to add two things CVSS was never built to know: whether a vulnerability is actually being attacked right now, and how likely it is to be attacked soon. Those are the CISA Known Exploited Vulnerabilities catalog (KEV) and the Exploit Prediction Scoring System (EPSS). Here is why the swap matters, and where each piece still falls short.

The score that was never a risk score

Start with a misconception worth clearing up, because almost everything downstream depends on it. CVSS does not claim to measure risk, and it never has. It measures severity: how bad the damage would be if a given vulnerability were successfully exploited, judged from the intrinsic properties of the flaw itself. The people who maintain CVSS are explicit about this. The organization that stewards the standard, FIRST (the Forum of Incident Response and Security Teams), states in its CVSS v4.0 user guide that "the CVSS Base Score represents only the intrinsic characteristics of a vulnerability and is independent of any factor associated with threat or the computing environment where the vulnerable system resides." The Base Score, they write, "should be supplemented with an analysis of the environment" and "with attributes that may change over time." Only once you add those layers, in their words, does the result "be considered much closer to 'Risk'." That is a careful, honest disclaimer. The trouble is that in practice almost nobody adds the layers. The number that ships in a scanner report, in a National Vulnerability Database entry, in a vendor advisory, is the bare Base Score. It answers a hypothetical: if this were exploited, how bad would it be? It says nothing about whether anyone is bothering to exploit it, which is the question a triage queue actually needs answered. CVSS 4.0, released on November 1, 2023 after a public preview at the FIRST conference in Montreal that June, tried to nudge users toward the fuller picture. It introduced a new naming convention, CVSS-B for Base alone, then CVSS-BT and CVSS-BTE as you fold in Threat and Environmental metrics, precisely so that a bare Base Score would look conspicuously incomplete. It was a reasonable reform. But it does not change the arithmetic problem underneath.

The math stopped working

The arithmetic problem is that severity and attack likelihood are almost unrelated, and severity is common while attack is rare. The foundational research behind EPSS, work by Jay Jacobs, Michael Roytman and colleagues first presented at Black Hat in 2019 and later published in ACM's Digital Threats journal, put hard numbers on this. Only a small slice of all disclosed vulnerabilities are ever exploited in the wild, with credible estimates landing somewhere between roughly 2% and 6%. The overwhelming majority of CVEs, including a great many rated Critical, are never weaponized against anyone. Now overlay the CVSS distribution. A "patch everything 7.0 and above" strategy, the default in countless compliance regimes, catches about 82% of the vulnerabilities that do get exploited. That coverage sounds excellent until you count the cost: it requires remediating roughly 58% of all published CVEs, on the order of 110,000 of them in the analysis, and of that enormous effort only about 6% is spent on vulnerabilities with any real exploitation activity. In the language the EPSS researchers use, the efficiency of a CVSS 7+ strategy, the share of your remediation work that lands on something attackers actually touch, is dismal. Academic replications put the precision of a CVSS 8+ cutoff at around 8%. Put plainly: sort your queue by CVSS and you will spend nineteen units of effort chasing bugs no one exploits for every one unit spent on a bug someone does. That is not a rounding error. It is the whole game being lost.

The infrastructure feeding those scores is straining under the volume too. The NVD, run by the National Institute of Standards and Technology, is the place most tools pull CVSS scores and metadata from. It has fallen badly behind: by early 2025 it had a backlog of around 25,000 unprocessed CVEs, and NIST itself acknowledged in April 2026 that record growth had outpaced its capacity, with tens of thousands of recent CVEs still awaiting full enrichment. When the pipeline that assigns your prioritization number cannot keep up with intake, ordering by that number degrades further. You are triaging with stale, incomplete data on top of a metric that was measuring the wrong thing to begin with.

What KEV actually tells you

The first correction is the simplest and the most powerful, because it replaces a prediction with an observation. On November 3, 2021, the US Cybersecurity and Infrastructure Security Agency issued Binding Operational Directive 22-01, which created the Known Exploited Vulnerabilities catalog. The idea is disarmingly modest. Rather than score every flaw, CISA maintains a curated list of vulnerabilities for which there is reliable evidence of exploitation in the wild. To be added, an entry needs three things: an assigned CVE ID, clear guidance on how to remediate it, and that reliable evidence of active exploitation. The directive gave federal civilian agencies hard deadlines to fix listed items, two weeks for most, and although BOD 22-01 was itself superseded by BOD 26-04 in June 2026, the catalog and its criteria carried straight through.

The catalog started with about 290 entries in late 2021. By the end of 2025 it held roughly 1,484, and through 2026 it passed 1,600. Set that against the NVD, which held more than 376,000 CVE records by August 2026. KEV, in other words, represents well under half a percent of all known vulnerabilities. That is not a weakness of the catalog; it is the entire point. It is a high-signal, human-curated shortlist of the things that are provably dangerous today. If a CVE is on KEV, it stops being a judgment call. Someone, somewhere, has been attacked through it. It goes to the front of the queue regardless of its CVSS score. And that "regardless" carries weight, because the two lists do not agree as neatly as you would hope. While over 80% of KEV entries do carry High or Critical CVSS ratings, runZero's analysis of the catalog found roughly 16% rated Medium and a fraction rated Low. A CVSS-only strategy with a 7.0 cutoff would simply have skipped those, and attackers used them anyway.

EPSS: betting on what happens next

KEV has one structural limitation: it is a record of the past. A vulnerability lands on KEV only after exploitation has been observed and confirmed. For a brand-new flaw, or one being exploited quietly, the catalog is silent. That is the gap EPSS is built to fill. EPSS, also a FIRST project, is a machine-learning model that outputs, for every CVE, a probability between 0 and 1 that the vulnerability will be exploited in the next 30 days. The scores are recomputed daily, and the model is trained on a wide spread of real-world signals: observed exploitation activity from partners including VulnCheck, the Shadowserver Foundation and LevelBlue, plus features like the affected software, the type of weakness, public exploit code, mentions across hundreds of web and social sources, internet-wide scanning data from Shodan, and more. Where CVSS asks a panel to reason about a flaw's properties, EPSS learns from what has historically preceded actual attacks. The efficiency gains are the reason to care. The current model, EPSS version 4, released on March 16, 2024, collects evidence of roughly 12,000 vulnerabilities being exploited every month across its data feeds. Recall the CVSS 7+ strategy: 82% coverage at 58% effort. Using EPSS version 3, you could hit that same 82% coverage by patching vulnerabilities scored 0.088 and above, which meant remediating only about 7.3% of CVEs, under 14,000 instead of 110,000. Version 4 pushed further, cutting the effort needed to hold coverage from around 50% down to roughly 6%, an eightfold reduction, and lifting efficiency to around 47%. Nearly half your work landing on real threats, versus the single-digit hit rate of sorting by severity. There is a subtlety worth stating so you do not over-trust the number. An EPSS score of 0.10 is not "low." Because genuine exploitation is rare, a 10% probability already sits around the 88th percentile of all vulnerabilities. FIRST recommends looking at both the raw probability and the percentile, so you know both the absolute odds and where a CVE ranks against every other one.

When the three disagree

The interesting cases, and the honest ones, are where these signals point in different directions. This is not a story where CVSS is always wrong and EPSS is always right. Each instrument is blind to something. Consider a vulnerability with a modest CVSS Base Score of 5.3, squarely in "Medium" territory, that a scanner would bury on page forty of the report. If its EPSS score is 0.22, it carries better than a one-in-five chance of exploitation in the coming month, which puts it above nearly everything else you own. CVSS says ignore it; EPSS says it may be one of your most urgent problems. Real catalog history bears this out: CISA's KEV includes flaws like CVE-2016-3351, an Internet Explorer bug rated just 3.1, that ended up exploited by around a dozen ransomware operations. Sorted by severity, it never surfaces. The disagreements run the other way too. KEV can lag a fast-moving campaign, since confirmation takes time. EPSS is probabilistic and can miss a novel exploitation technique it has never seen a precedent for. And CVSS, for all its faults as a ranking tool, remains the best quick answer to a question the other two do not address at all: if this thing is exploited, how much damage can it do? A low-severity flaw that is being actively exploited still matters less, all else equal, than a critical one that is, if it lets an attacker take over a domain controller rather than crash a print spooler. The scores answer different questions. The mistake was ever asking severity to answer the question of order.

Log4Shell and the limits of any single number

It is worth dwelling on a case where CVSS got it exactly right, because it clarifies what actually went wrong.

In December 2021, CVE-2021-44228, "Log4Shell," a flaw in the ubiquitous Apache Log4j logging library, was scored a perfect CVSS 10.0. It was also, within days, one of the most heavily exploited vulnerabilities in history. Here severity and exploitation agreed completely, and prioritizing by CVSS would have sent you straight to it. So CVSS is not a broken instrument in the sense of being random. On any single genuinely critical, genuinely exploited bug, it can be dead on. The failure is systematic, not case-by-case. CVSS breaks across the whole queue, because for every Log4Shell where the 10.0 is earned, there are hundreds of other 9s and 10s that no attacker will ever touch, and a scattering of 4s and 5s that some will. A metric can be individually correct and collectively useless as a sorting key. That is the precise shape of the CVSS problem, and it is why the answer is not "score better" but "add the missing dimension."

A working order of operations

Combining the signals is less complicated than the debate around it suggests. A defensible sequence looks like this. First, patch anything on the CISA KEV catalog, immediately, without further argument. It is confirmed exploitation, it is a small list, and it is free. This is the highest-signal, lowest-effort move available. Second, for everything not on KEV, sort by EPSS to find what is most likely to be attacked next, and read the probability alongside its percentile so you are not fooled by numbers that look small but rank high. Third, use CVSS, and specifically the environmental and threat context CVSS 4.0 encourages, to break ties and to weigh consequence. Among two vulnerabilities of similar exploitation likelihood, the one that would do more damage on the systems you actually run wins. This is also where asset context matters: a flaw on an internet-facing crown-jewel server is not the same as the identical flaw on an isolated test box. Organizations that want a fully qualitative version of this can reach for SSVC, the Stakeholder-Specific Vulnerability Categorization model that CISA developed with Carnegie Mellon's Software Engineering Institute. Rather than a number, SSVC walks a decision tree using exploitation status, the prevalence of the affected product, and the potential impact, and outputs an action, Track, Attend, or Act. It bakes the same insight into its very first branch: the question that matters most is whether the thing is being exploited. None of this is exotic. KEV is a free download. EPSS is a free daily feed with a public API. The barrier has never been access. It has been the institutional habit, hardened into audits and compliance checklists and dashboard defaults, of treating a severity score as a to-do list.

What to watch

The most interesting open question is whether the compliance world catches up to the operational one. Auditors still frequently ask "have you remediated all Highs and Criticals," a demand that, given the numbers above, actively wastes the security budget it is meant to protect. The signals are shifting: KEV deadlines are now baked into US federal directives, and exploitation-based prioritization is spreading into insurance requirements and procurement language. Meanwhile the raw pressure keeps rising, with CVE volume climbing and the NVD's enrichment backlog casting doubt on the very data CVSS-based programs depend on. Watch, too, for what happens as EPSS becomes standard infrastructure rather than a specialist's tool. A prediction model that everyone acts on can change the thing it predicts, since attackers read the same signals defenders do. For now, the honest summary is narrow and firm: CVSS answers "how bad could this be," and that is a real question worth an answer. It just was never the question your Monday-morning queue was asking.

Sources

1. FIRST, CVSS v4.0 User Guide, 2023.
2. FIRST, CVSS v4.0 is now available, 2023.
3. FIRST, Exploit Prediction Scoring System (EPSS), 2024.
4. Jacobs, Roytman et al., Exploit Prediction Scoring System (EPSS), ACM Digital Threats: Research and Practice, 2021.
5. Empirical Security, Introducing EPSS Version 4, 2024.
6. CISA, BOD 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities, 2021.
7. CISA, Known Exploited Vulnerabilities Catalog, 2026.
8. CISA, Stakeholder-Specific Vulnerability Categorization (SSVC), 2020.
9. runZero, KEVology: An analysis of CISA KEV exploits, scores, and timelines, 2024.
10. Recorded Future, Understanding Exploitation of Medium and Low CVSS Score Vulnerabilities, 2023.
11. Infosecurity Magazine, NVD Revamps Operations as Vulnerability Reporting Surges, 2025.
12. NIST, NIST Updates NVD Operations to Address Record CVE Growth, 2026.