Why Vulnerability Prioritisation is Broken

1 · Executive summary

Every organisation with more findings than capacity is running a prioritisation model, whether or not it has written one down. Most are running the same one: sort by CVSS, work downwards, escalate whatever someone shouts about. That model is not merely imprecise — it is systematically wrong in a direction attackers benefit from.

The claim of this paper is narrow and testable. Severity describes a vulnerability. Risk describes a vulnerability in a place. Ranking by severity means ranking without the place, and the place is where nearly all of the variance lives: whether the code is reachable, whether the flaw is being exploited this month, whether the asset processes anything worth stealing, whether a control already stands in the way.

What this paper provides

1. An honest account of CVSS — what it measures, what its own specification says it is not for, and why the environmental metrics designed to fix this are almost never populated.
2. Five signals — EPSS, KEV, reachability, business criticality and compensating controls — each with where to obtain it, what it is worth, and the failure mode nobody mentions.
3. A composite model with the arithmetic shown, explicitly designed to be explainable rather than accurate to a decimal place.
4. Ten findings ranked twice, by CVSS and by the model, so the disagreement is visible rather than asserted.
5. The failure modes of prioritisation programmes, which are organisational more often than mathematical.

2 · What CVSS is, and what it was never for

CVSS is a good standard used badly. It exists to describe the intrinsic characteristics of a vulnerability in a way that is comparable across organisations — so that a flaw scored by a vendor in Helsinki means the same thing to a team in Bengaluru. That comparability is achieved precisely by excluding everything specific to your environment.

The standard is explicit that the base score is not a risk score, and it provides additional metric groups for the adjustment:

The third row is the whole problem. The mechanism to make CVSS environment-aware has existed for years and is not used, because populating it requires exactly the correlated context most organisations do not have: which asset, how exposed, how valuable, what compensates. So the base score is shipped raw into a work queue and treated as a priority.

Three specific distortions

Ceiling compression. A large fraction of published CVEs score between 7.0 and 10.0. Once a third of your queue is "critical", the label has stopped carrying information, and triage falls back to whoever is most persuasive in the meeting.

Uniform asset assumption. The same CVE on a developer's sandbox and on the host processing cardholder data scores identically. Every experienced practitioner corrects for this informally, which means the quality of your prioritisation depends on who is holding the spreadsheet that week.

No decay, no acceleration. A base score is the same the day a proof-of-concept lands on GitHub as it was the week before. The single most decision-relevant fact about a vulnerability — whether it is being exploited right now — is invisible to it.

3 · The five signals that change the answer

Each of these is obtainable today, by most organisations, without a platform. Each is also routinely misused, so each entry below states its failure mode as plainly as its value.

3.1 EPSS — is this likely to be exploited?

The Exploit Prediction Scoring System publishes, for most published CVEs, a probability that the vulnerability will see exploitation activity in the near term. It is a statistical model trained on observed exploitation, and it is free.

Its practical value is enormous, because the distribution is extremely skewed: the overwhelming majority of CVEs have very low probabilities, and a small minority carry most of the risk. Used as a filter rather than a ranking, EPSS removes a large share of a queue with a defensible justification.

3.2 KEV — is it being exploited already?

CISA's Known Exploited Vulnerabilities catalogue lists vulnerabilities with confirmed, observed exploitation. Where EPSS is a prediction, KEV is a retrospective fact, and facts outrank predictions. Presence in KEV should be close to decisive: a KEV-listed vulnerability on a reachable asset belongs at the top of the queue almost regardless of its base score.

3.3 Reachability — can anyone actually get there?

The single largest multiplier, and the most often missing. Reachability has layers, and the distinction matters because they cost different amounts to establish:

Most organisations can establish the first two within weeks from configuration they already hold. Those two alone reorder a queue more than any scoring refinement.

3.4 Business criticality — what breaks if this fails?

The hardest of the five, because it cannot be derived from any scanner. It is a property of the business, recorded by people, and it decays as reorganisations happen.

Resist the temptation to build an elaborate scheme. Three or four tiers, consistently applied, outperform a ten-point scale nobody maintains. What matters is that the tier is attached to a service — something a customer would notice failing — rather than to a host, because hosts are replaced weekly and services are not.

3.5 Compensating controls — what already stands in the way?

A WAF rule in blocking mode, a network segment, an authentication requirement, a feature flag disabling the affected path. Each materially reduces real risk, and none of them changes a base score.

The critical discipline: a control counts only if its live state is verified. Paper 01 described a payment API whose WAF rule everyone cited in triage and which had been switched to detection mode during a performance incident four months earlier. That is not an unusual story. It is the normal behaviour of controls that live in people's memory rather than in data.

4 · Combining them without building a black box

There is a strong temptation to reach for machine learning here. Resist it for the first two years. The purpose of a prioritisation score is not to be optimal — it is to be agreed. An engineer who can see why item 1 outranks item 8 will work the list. One who is told the model decided will not, and will keep a private list instead, which is the state you were trying to leave.

A model that fits on an index card

The coefficients above are a starting point, not a truth. What matters far more than their exact values is that they are written down, few, and stable. Three properties make a model like this survive contact with an engineering team:

• Every factor is attributable. The score displays as 8.1 × 2.0 × 2.0 × 1.6 × 1.0, not as 96. Anyone can see which factor drove it and challenge that one specifically.
• Nothing is hidden. If reachability data is missing, the model uses 1.0 and says so, rather than guessing. A queue with visible gaps is trusted; a queue with invisible assumptions is not.
• The coefficients change rarely and deliberately. A model tuned monthly cannot be compared quarter over quarter, so you lose the ability to say whether anything is improving.

5 · Ten findings, ranked twice

A composite of realistic findings from a mid-sized financial services estate. Columns: CVSS base, exposure, threat intelligence, service tier, verified control, and the resulting composite. Sorted by composite; the CVSS rank is shown for comparison.

What the disagreement tells you

The top item moved from ninth to first. A 6.5 outranks three 9.8s because it is unauthenticated, internet-facing, known to be exploited, and sits on a tier-one regulated service. Every one of those facts came from a system other than the scanner that reported it.

Three 9.8s spread across ranks 2, 4 and 9. Identical severity, wildly different risk. The one at rank 9 — unreachable, on a batch worker — would have consumed the first day of remediation effort under a CVSS-ordered queue.

Two findings dropped almost to zero because of verified controls. Note the word verified. Had those controls been assumed rather than checked, the model would have quietly buried two live issues, which is the most dangerous failure this design can produce — and the reason section 3.5 insists on a verification date.

6 · How prioritisation programmes fail

The mathematics is the easy part. These are the failure modes we see in practice, and all five are organisational.

1. False precision

   A score of 87.3 implies an accuracy the inputs cannot support. Display bands — critical, high, moderate, low — and keep the number for ordering within a band. The moment someone argues about the difference between 87.3 and 86.9, the model has become the subject instead of the tool.

2. Gaming the criticality tier

   When tier drives SLA, every service owner discovers their service is tier one. Tiering must be assigned by someone who does not own the remediation workload, against a written definition, and audited occasionally.

3. Exception debt

   Risk acceptances accumulate, expire silently and are never revisited. Every acceptance needs an owner, an expiry date and a review that actually happens — otherwise the exception register becomes the real vulnerability register, unmanaged.

4. Unmaintained inputs

   The model is only as current as its worst input. Exposure recomputed monthly on an estate that changes daily produces confident, stale answers. Every input needs a refresh interval and a visible age.

5. Ranking without capacity

   A perfectly ranked queue of 300 items delivered to a team that can close 12 a week is still a demoralising queue. Prioritisation must be paired with a commitment about how far down the list the organisation actually intends to go — and honesty that the rest is accepted risk, whether or not anyone signed for it.

7 · Implementing it in the order that works

The order below is not arbitrary. Each stage is useful alone, and each makes the next one possible.

Stages 1 and 3 can be completed in an afternoon each and require no platform. If you do nothing else from this paper, join your findings against KEV and against EPSS this week, and re-sort. The result will be closer to correct than what you have now, and it costs one query.

8 · Knowing whether it worked

Prioritisation programmes are unusually easy to declare successful, because the obvious metric — findings closed — improves when you close easy things. Four measures that resist that:

The fourth is the one to watch in the first quarter. A challenge rate near zero usually means nobody is reading the ranking, not that it is perfect. A challenge rate that starts high and falls, with the model corrected along the way, is what adoption actually looks like.