One number, honestly.

A security team does not get to patch everything and does not get to patch nothing; it gets a queue. Past a quarter-million CVEs (Common Vulnerabilities and Exposures) now exist, the joined dataset behind this analysis carries 341,899 of them with a CVSS vector, and any given environment lights up with hundreds at once, so the question is never "is this bad?" but "is this worse than the other forty things open this week?" That is a ranking problem, and a ranking problem wants one number.

The obvious number is the wrong one. CVSS (the Common Vulnerability Scoring System) gives every CVE a 0–10 severity score, and teams have sorted by it for twenty years because it was there, but CVSS severity describes how bad a flaw would be if exploited, not whether anyone will exploit it. Rank CVEs by raw CVSS base score and ask how well that ordering surfaces the bugs that actually get exploited in the wild — using CISA's KEV list (Known Exploited Vulnerabilities) as the test set — and the base score lands at an AUC of 0.77. AUC, the area under the ROC curve, is the probability that a score ranks a truly-exploited bug above a random un-exploited one, so 0.5 is a coin flip and 1.0 is perfect. An empirical exploitation model does much better: EPSS, FIRST's Exploit Prediction Scoring System, scores 0.94 on the same hold-out (a number to read with the endogeneity caveat below, since KEV and EPSS share inputs). Severity on its own is a weak predictor, and the data is blunt about why: the CVSS base score explains only about 3% of the variance in EPSS.

So the modern instinct is right — lead with EPSS, a model trained to estimate the probability that a CVE will be exploited in the next thirty days. But "just use EPSS" has its own hole, and EPSS's own authors name it: the model "measures threat only," and is explicitly "not a complete picture of risk." It says nothing about how much damage a flaw would do, or whether the affected system is a crown-jewel database or a disposable sandbox, so a queue sorted purely by exploitation probability floats a noisy, low-consequence bug above a quiet flaw that would hand an attacker a regulated system. EPSS was never asked about consequence.

This is the idea that makes the score more than another formula, and the one most spreadsheet versions get wrong without noticing. EPSS is not an independent opinion you can check against your other signals; it is a model whose inputs include the very signals you would reach for to validate it. FIRST's documentation lists, among EPSS features, "CVSS metrics (base vector from CVSS 3.x, via NVD)," and the v4 model additionally pulls cve.org CNA/ADP enrichment along with exploit-code presence and public mentions. So when an EPSS-based score appears to "predict" which CVEs land on KEV, part of what you see is the model agreeing with its own wiring. KEV membership and "EPSS ≥ 0.5" are not neutral referees; they share information with the score, which means every empirical claim here tests ranking sanity, not ground truth. There is no clean external "risk" label to validate against, because no one observes counterfactual breaches.

The trap gets sharper with SSVC. One of its four factors, Exploitation (none / PoC / active), is by definition derived from KEV membership and public-exploit presence — the same evidence EPSS already consumes. So the natural-looking move of multiplying EPSS by an SSVC-Exploitation term counts the same evidence twice. It looks like you are combining two signals, but you are really squaring one. I built that naive form deliberately and compared it to the single-instrument version that uses EPSS alone for exploitation: the two rankings agree at only Kendall τ = 0.84, and among the most urgent 1% of CVEs the two "top" sets share a Jaccard overlap of just 0.47 — nearly half of what the double-counted score calls most urgent is an artifact of scoring the evidence a second time, and that is the half most likely to drive an emergency change window.

The first failure is the double-count already covered. The second was the single most useful correction in the whole exercise. The literal reading of the weights says the likelihood half should be a weighted sum, L = 0.74·EPSS + 0.26·Automatable, which looks reasonable until you notice what it does to the roughly 77% of CVEs that are not flagged automatable: for each of them the Automatable term is zero, so the formula replaces 1.0·EPSS with 0.74·EPSS — it discounts them. Since most known-exploited bugs are not flagged automatable, this measurably hurt the ranking, dropping KEV coverage at 5% remediation effort from 0.88 to 0.62. The multiplicative amplifier EPSS·(0.74 + 0.26·Automatable) keeps the exact same 0.26 weight but only ever raises a wormable bug's score, never discounting EPSS within a class, and restores coverage at 5% to 0.87. The third failure is the additive composition rule itself, which breaks the "no impact means no risk" intuition, so I use the product.

The fourth case is one no smooth formula handles, and the right response is to stop pretending it does. The reverse-engineering surfaced a few tree outcomes that no weighted sum can reproduce, because they are non-compensatory — they flip on a combination of factors rather than on any one factor's contribution. So instead of torturing the weights, I add one explicit rule: if a CVE is in KEV or has EPSS ≥ 0.50 and its computed band came out below High, floor it at High. That guarantees no scoreable, actively-exploited CVE gets a long deadline; it fires for only 0.52% of the scoreable population at the standard tier, so it acts as a safety rail over the smooth score rather than a scoring system of its own.

Eight real CVEs make the behaviour concrete, scored at the standard asset tier:

BlueKeep (automatable, 58.8) outranks Struts (43.5) at identical EPSS and impact — the amplifier doing its one job. Heartbleed and the Log4j denial-of-service both sit at maximum EPSS, yet their partial impact pulls them below the total-impact remote-code-execution bugs, so impact demotes likelihood exactly where a severity-blind, EPSS-only queue would over-rank them. The sleeper, CVE-2024-0916, has a 1% EPSS and would be buried in any pure-likelihood queue, but because it is automatable with total impact it lands at Medium, not Info — the low-probability, high-consequence case triage most often misses. And the same BlueKeep moves from 41.7 (High) on a low-value asset to 100.0 (Critical) on a crown-jewel: the asset weight setting the level while likelihood sets the order.

It is decision support, not a probability of loss. Half of it — the entire impact side — is a value model you chose, so the 0–100 number must never be read as a "chance of breach." Endogeneity runs through every empirical claim: EPSS consumes CVSS base vectors and exploit evidence as features, so "the score predicts KEV" is partly the model agreeing with its own inputs, which is why SSVC Exploitation is excluded and why I never claim the score independently confirms or causes exploitation. The validation labels themselves are endogenous — KEV and "EPSS ≥ 0.5" both share information with the score — so they test ranking sanity, not truth, and there is no ground-truth "risk" to validate against.

The coverage limits are real: only 52.9% of CVEs are scoreable, because the rest lack both a CVSS vector and an SSVC Technical-Impact value; the SSVC fields exist for about 46% of CVEs, assigned by CISA's ADP and skewed toward recent, CISA-prioritised vulnerabilities, so the effect sizes should not be generalised past that population; the EPSS percentile is population-relative and re-ranks if the scored set changes; and the weights are a best additive approximation of the SSVC tree, every effect size an association rather than a cause. The right disposition is to treat the score as a consistent, explicit, tunable way to order a backlog, and to keep the measurements and the judgement calls in separate drawers — so that when someone asks "why is this one first?" the answer is always either a number you can show them or a choice you can own.