A 9.8 is not a priority: ranking vulnerabilities by exploitability, not CVSS

A CVSS 9.8 at the top of the backlog reads like an order: drop everything. It is the number that gets escalated in standups, written into remediation SLAs, and used to sort the queue every scanner hands you. But severity and priority are not the same thing, and treating a 9.8 as a work order — fix the highest numbers first — is how a team spends a sprint patching things nobody will ever attack while the one bug that is being exploited this week sits three pages down the list. The score is a real signal. It is just answering a different question than the one you need answered.

Severity is not risk — and CVSS says so

The clearest statement of this comes from the people who publish the scores. FIRST's CVSS v4.0 User Guide has a section headed, in so many words, “CVSS Base Score (CVSS-B) Measures Severity, not Risk.” The Base Score, it says, is “designed to measure the severity of a vulnerability and should not be used alone to assess risk,” and it “represents only the intrinsic characteristics of a vulnerability and is independent of any factor associated with threat.”

Read that carefully, because it undoes the most common way the number gets used. The Base Score is a lab measurement: given a vulnerability in isolation, how bad is the worst realistic case? It knows nothing about whether an exploit exists, whether anyone is using it, or whether the affected code is even reachable in your deployment. CVSS v4.0 is explicit that to move closer to risk you have to add the other metric groups — the Threat metrics (what v3 called Temporal) and the Environmental metrics — and that “the application of Environmental and Threat metrics is the responsibility of the CVSS consumer.” The score your scanner shows you is almost always Base-only. The part that turns severity into risk is the part you were supposed to supply, and usually didn't.

Most of the queue will never be attacked

If severity were a good proxy for what to fix, sorting by it would at least put the dangerous things on top. It doesn't, because exploitation is rare. FIRST's guidance on EPSS — the Exploit Prediction Scoring System — notes that the base rate of exploitation is around 2%: of all the vulnerabilities being scored, only about one in fifty will see exploitation activity in a given window. A backlog sorted by CVSS and filtered to “High and above” is, therefore, mostly a list of things that will never be attacked, ranked by how bad it would be if they were.

EPSS is the signal CVSS leaves out. It is a model, maintained by FIRST, that produces “the estimated likelihood that exploitation activity for a given vulnerability will be observed … in the next 30 days.” It is trained on real signals — public exploit code and tooling, how often the vulnerability is mentioned across security sources, its characteristics and age, and observed exploitation from sensor partners — using gradient-boosted trees over roughly 2,850 features. The output is a calibrated probability: FIRST's own example is that “a score of 0.05 represents a genuine 5% probability of exploitation within 30 days.”

Two traps to avoid, both documented by FIRST. First, the probability is not the percentile. EPSS ships both, and they mean different things: the probability is the chance, the percentile is only the rank — “the percent of vulnerabilities at or below this score.” A CVE in the 90th percentile is more likely to be attacked than 90% of the rest, which at these base rates can still be a low absolute probability. Second, do not build a “risk score” by multiplying EPSS by CVSS; FIRST warns specifically against multiplying a probability by an ordinal such as CVSS, because the product has no coherent meaning. Treat them as two axes instead: how bad (CVSS) and how likely (EPSS).

EPSS is free, published daily, and needs no key, so this axis costs a single request per CVE:

# EPSS score for one CVE (published daily, free, no API key):
curl -s "https://api.first.org/data/v1/epss?cve=CVE-2024-3400"

# The JSON returns one record per CVE, with four fields:
#   cve         the identifier you asked for
#   epss        probability of exploitation in the next 30 days (0.0-1.0)
#   percentile  this CVE's rank among all scored CVEs (0.0-1.0)
#   date        the day this score was computed (scores move as signals change)

Three questions a score cannot answer

Strip away the numbers and prioritisation is really three questions, in roughly this order of force:

• Is anyone exploiting it? CISA's Known Exploited Vulnerabilities (KEV) catalog is the ground truth for “yes”: it lists vulnerabilities with reliable evidence of active exploitation in the wild. A CVE in KEV is not a forecast; it is a report that the attack is already happening. EPSS is the forward-looking companion for everything not yet in it.
• Is it reachable and exploitable in your system? This is the question none of the population-level signals can answer, and EPSS's own documentation is explicit that its scores are population-level, not tied to any one organisation's environment. A critical bug in a library you ship but never call on the vulnerable path, behind a feature flag that is off, on an endpoint that isn't exposed, is not your emergency — however high it scores for everyone else.
• Does the asset matter? A proven, actively-exploited remote-code-execution bug on a throwaway staging box and the same bug on the server that signs your releases are the same CVE and two completely different business decisions.

The missing multiplier: reachability and proof

Of those three questions, the middle one is where a scanner's ranked list and your real risk diverge most, and it is the only one that can be answered by looking at your system rather than a database. Reachability analysis asks something concrete: is the vulnerable code actually invoked on a path an attacker can drive? Is the feature enabled, the endpoint routed, the parameter attacker-controlled? A dependency advisory tells you a function is vulnerable; it cannot tell you whether your application ever calls it.

Exploit verification goes one step past reachability: it attempts the exploit, in a controlled way, against the system as deployed, and reports what actually happened. It is the discipline the rest of this blog keeps returning to — a reflected Origin, a 302, a reachable admin route, a {{7*7}} that evaluates are all hints that something might be exploitable; the finding that costs an attacker anything is the one you have driven end to end. (That is the whole argument of detection is not proof.) Applied to prioritisation, verification collapses a population-wide probability into a fact about one system: either the bug fires here, or it doesn't.

This is where Xalgorix sits, and it is worth being honest about what that buys and what it does not. Re-exploiting a vulnerability to prove it is real and reachable answers the environment question that EPSS and KEV cannot — that is the whole of “proof, not guesswork.” But proof is not the entire risk picture. A verified, reachable bug on a system nobody depends on still ranks below an actively-exploited one you haven't yet confirmed; an autonomous verifier that proves exploitability tells you nothing on its own about in-the-wild pressure or business value. Reachability and verification are the multiplier the population signals are missing, not a replacement for them. The teams that get prioritisation right layer all of it.

A decision, not a number

If a single number was never going to carry the decision, the honest alternative is to make the decision explicitly. That is what CISA's Stakeholder-Specific Vulnerability Categorization (SSVC) does: instead of a score, a small decision tree whose inputs are exactly the questions above. Its decision points are Exploitation (“None,” “Public PoC,” or “Active”), Automatable (“No” or “Yes”), Technical Impact (“Partial” or “Total”), and a combined Mission & Well-being value — and they resolve to one of four actions rather than a point on a 0–10 scale.

The value is not the specific tree but its shape. Exploitation comes first, so an actively-exploited vulnerability is treated as urgent regardless of its CVSS number, while a 9.8 with no known exploit, no automatable attack, and no reachable path can land in “Track” — fix it on the normal schedule. And the decision is transparent: anyone can see why a thing was or wasn't escalated, which a bare 9.8 never explains.

What this looks like on Monday

None of this means throwing CVSS away. It means putting it in its place — one axis of several, and the one you already have.

The 9.8 that started this is not wrong. It is telling you, accurately, that if this vulnerability were exploited in the worst realistic way the damage would be near-total. What it cannot tell you — and was never designed to — is whether that will ever happen to you. That answer lives in the exploitation signals, in your own environment, and in proof. Sort by the number, and you are guessing. Sort by what is reachable and under attack, and you are not.