Severity is not a priority

Most security reports arrive sorted by CVSS. Four criticals, eleven highs, thirty mediums, and a long tail of lows that nobody will ever read. The engineering team takes the criticals, schedules the highs, and quietly lets the rest age out of the backlog.

That process feels rigorous. It usually produces the wrong order of work.

The problem is not that CVSS is inaccurate. It is that CVSS answers a question you were not asking. It scores how bad a vulnerability is in general, across every system that has it. You need to know what to fix in your system, next week, with the three engineers you can actually spare. Those are different questions, and the second one is not a sorted version of the first.

What a score leaves out

A CVSS base score describes an isolated vulnerability under assumed conditions. It deliberately excludes almost everything that determines whether the issue matters to you:

• Whether the vulnerable code path is reachable. A critical deserialisation flaw in a library you import but never call on the affected code path is not a critical anything. It is a dependency bump you should do on a normal schedule.
• What sits behind it. Remote code execution on a stateless image-resizing worker with no credentials and no network egress is a genuinely different problem from RCE on the box holding your signing key. Same score.
• What an attacker needs to get there. “Requires an authenticated account” means one thing when accounts cost an email address and something else entirely when they require a signed contract and manual provisioning.
• What you already have in the way. A network boundary, a WAF rule, an egress policy, or a mandatory reauthentication step can move an issue from “exploitable this afternoon” to “exploitable after three other things also go wrong.”

None of that is a criticism of the scoring system. CVSS was designed to be context-free so that it could be comparable across organisations. The mistake is treating a deliberately context-free number as a work queue for a specific context.

A severity score tells you how bad the vulnerability is. Reachability and blast radius tell you what happens to your business if nobody fixes it this quarter. Only the second pair is a plan.

The two questions we actually rank on

Every finding we report gets ranked on two axes, and both of them are about your system rather than the vulnerability class.

Reachability — what does an attacker need before this is live? We write this as a path, not a probability. Unauthenticated from the internet. Any account created through self-service signup. A low-privilege internal user. A compromised CI runner. Physical access to a workstation. Each step is a real precondition someone has to satisfy, and the number of steps is the honest measure of how close the issue is to being someone’s Tuesday.

Blast radius — what is reachable once it works? One record, or the table. One tenant, or all of them. One service account, or the credential that mints service accounts. This is the axis that separates an incident from a company-ending event, and it is almost entirely a function of your architecture rather than of the bug.

Rank by those two and the ordering changes, sometimes dramatically. A “medium” IDOR on an export endpoint that any signed-up user can reach, returning every tenant’s records, outranks a “critical” RCE that requires a foothold on a segmented build network you have never seen an attacker reach. We will still report both. We will not pretend the second one is the thing to do first.

What this changes in practice

The report is shorter and the top of it is real. When ranking is contextual, the top five findings are five things you should genuinely do first, rather than five things that scored above 9.0. Teams start reading past the first page again, because the first page earned it.

Remediation stops being a queue and starts being a plan. Findings that share a root cause get grouped. Four authorisation gaps across four endpoints are not four tickets — they are one missing default-deny layer, and fixing them individually guarantees a fifth next quarter. A score-sorted report actively hides that structure by scattering related issues across severity bands.

Arguments get shorter. “This is a high” is a conversation about a number and it can run for a week. “An attacker with a free account reaches every customer’s data in three requests, here is the capture” is a conversation about a fact. Nobody negotiates with a reproduction.

Some criticals get deferred, on purpose and in writing. This is the part that makes people nervous, so we make it explicit: when we recommend deferring a high-scoring finding, we record why — the precondition that makes it remote, the control that stands in the way, and what would have to change for it to become urgent again. That note is the difference between a considered decision and an oversight, and it is what you want to be able to point at later.

Where the score still earns its place

We are not proposing you throw the number away. CVSS does three things well, and we keep it in the report for all three.

It is a common vocabulary with people outside the engagement — auditors, insurers, customers running vendor assessments, and anyone who needs a comparison across systems they cannot see inside. It is a floor: a base score above 9.0 always gets read carefully, even when we expect to conclude that reachability is poor. And it is a hedge against our own judgement — if we rank something low on reachability and the score is critical, that disagreement is worth writing down, because it is exactly the kind of call that turns out to be wrong.

So every finding carries its score. It just does not set the order.

What a finding should contain

If you take one thing from this, take the shape rather than the philosophy. A finding you can act on has four parts, and a severity label is not one of them:

• The path. The concrete sequence from attacker starting position to impact, written as steps someone can repeat.
• The blast radius. What is reachable once the path works, in the language of your business rather than of the vulnerability.
• The fix. Specific to your codebase and your stack — the change, where it goes, and what it breaks.
• The check. The test or control that stops it coming back after the next refactor.

Severity without a remediation plan is noise, and we do not ship it. If a finding in your last report does not have those four parts, the gap is not in your backlog. It is in the report.