How to prioritize security findings when everything is labelled critical
A severity-ranked list is not a plan. CVSS describes how bad a vulnerability would be if it were exploited, in the abstract. It does not know whether the affected code runs on anything you own, whether anyone outside your trust boundary can reach it, or whether there is anything behind it worth taking. That is why the queue never gets shorter: the ranking answers a question nobody at your company asked.
Why the queue never gets shorter
Two findings can both score 9.8. One is a remote code execution in a library your public upload endpoint calls on every request. The other is the same library, pinned in a devDependency that is compiled away and never reaches a running process. Scored identically, they are not remotely the same piece of work — and if you address them in the order the scanner printed them, you will spend the morning on the second one.
A score is a property of a vulnerability. Priority is a property of a vulnerability in a specific estate. The gap between the two is where triage time disappears, and it is also why the same list handed to two companies should produce two different orders of work.
Three questions that actually rank
Instead of re-sorting the severity column, put every finding through three questions in order. Any finding that fails the first one drops several places without further argument.
1 · Reachability — can anything outside your boundary get to it?
Not “is this software installed” but “is the affected path exercised by something an outsider can touch”. This is the question that removes the most work from the queue, and it is usually answerable from evidence you already have.
- Does the affected host resolve publicly, and does it answer?
- Is the package in the runtime dependency tree, or is it build-time only?
- Is the vulnerable function on a path a public request can reach, or behind authentication that is actually enforced?
- Is the service in front of it already refusing the precondition — a WAF rule, a size limit, a content-type check?
Record the evidence, not the conclusion. “Not reachable” is a claim someone will challenge in six months; “absent from the production lockfile, confirmed 9 September” is a fact you can re-check.
2 · Exploitability — what does the attacker actually need?
Reachable is not the same as practical. The useful form of this question is a list of preconditions, because each precondition is a place the attack can fail — and a place you can intervene without touching the vulnerability itself.
- Are credentials required, and of what privilege?
- Does it need a user to click something, or does it work unattended?
- Does working exploit code exist publicly, or is this theoretical?
- Does it need a race, a specific version, a specific configuration, or local access?
A finding that needs no credentials, no exploit code and no user interaction outranks a higher-scored one that needs all three — most often it is a misconfiguration rather than a CVE, which is exactly the class that severity-ranked tooling under-reports because there is no score to attach.
3 · Business relevance — what is behind it?
The last question is the one only your company can answer, and the one that decides ties. What sits behind the affected surface: production customer data, the billing path, the authentication system, the outbound mail your customers trust — or a brochure page with nothing behind it at all?
This is also where the second-order damage lives. Domain-level mail authentication rarely appears on a vulnerability report because it is not a vulnerability in anything. But a domain that authorizes a million addresses to send as itself is a live path to your finance contacts and your customers, needs no exploit, and is fixed with DNS changes rather than an engineering sprint.
The reordering, worked
Five findings, as a scanner and a dependency report would hand them to you, and the order the three questions produce instead. Note where the two 9.8s end up.
Six columns — scroll the table sideways →
| # | Finding | CVSS | Reachability | Exploitability | What is behind it |
|---|---|---|---|---|---|
| 1 | ~1.1 million IP addresses authorized to send mail as your domain (long SPF include chain ending in ~all, DMARC at p=quarantine) | None | Any tenant inside those shared provider ranges | No exploit, no credentials — an SMTP client | Invoices and customer mail carry the brand |
| 2 | Remote code execution in an image-processing library, present in the production dependency tree | 9.8 | Reached by the public file-upload endpoint | Public proof-of-concept, unauthenticated | Runs in the process that holds customer data |
| 3 | SPF record consumes 8 of the 10 permitted DNS lookups | None | Not an exposure — a fragility | No attacker required | Two more senders and SPF permerrors for all legitimate mail at once |
| 4 | X-Frame-Options and X-Content-Type-Options absent on the marketing site; the product login is fully configured | None | Public, but the host serves brochure pages | Clickjacking needs a convincing pretext and a user | No session, no data, no billing behind it |
| 5 | The same remote code execution, in a build-time devDependency that is never shipped | 9.8 | Not present in any running process | Would require build-system access first | Real, but it is a supply-chain question, not this one |
Nothing in that table required a scanner you do not have. It required deciding what evidence counts, and then being willing to move a 9.8 to the bottom in writing.
Write down why, not just what
The reason prioritization is hard to defend is that the reasoning is usually in one person’s head. Management asks why the critical item is still open; an auditor asks why item four was addressed before item one. If the answer exists only as a recollection, the ordering looks arbitrary even when it was correct.
Four short paragraphs per finding are enough, and they are the same four every time: what was observed, with the evidence; what the evidence supports and what it does not; what is recommended; and who holds the authority to act on it. That last one matters more than it looks — it separates a recommendation from a decision, so nobody later assumes a report authorized a change it merely proposed.
This is the discipline Warden calls a governance note, and it sits under every recommendation in an assessment. It is also the cheapest credibility you can buy: a decision with its reasoning attached survives a change of staff.
What this does not fix
Prioritization improves the order of a list. It does nothing about the completeness of it. A perfectly ranked queue built from findings that never mentioned your mail authentication, an abandoned subdomain or a forgotten staging host is still a well-ordered partial picture — and re-sorting will never reveal that, because the missing items are not in the input.
So the two habits go together: rank what you have by reachability, exploitability and business relevance, and separately, look at your public surface as an outsider would, from the outside, without reference to what your tools already told you.
The same discipline is what a customer’s procurement team is testing when they send you a security questionnaire — the companion guide covers how to answer one without a security team.