Vulnerability prioritisation: rank by exploitability, not by severity score
Vulnerability prioritisation by CVSS alone puts the wrong work first. Rank the remediation backlog by known exploitation, ransomware use, reachability and business impact.
Vulnerability prioritisation has one job: to decide what your team touches on Monday morning. The usual answer — sort by CVSS, work down from critical — is the wrong queue order, because the score describes the flaw and not your estate. Rank instead by four questions, asked in this order. Is this being exploited in the wild right now? Is it associated with ransomware operations? Can the affected machine actually be reached? And what is on it? Severity is the tie-break, not the sort key.
That reordering is not a scoring trick. It is the difference between a remediation backlog your infrastructure team works through and one they quietly stop opening.
Why vulnerability prioritisation by severity score alone gets the order wrong
CVSS is a good severity rating and a poor priority. FIRST, the body that publishes the standard, says as much in the specification itself: the base score describes intrinsic characteristics that are constant over time and across environments, and it is meant to be adjusted by the temporal and environmental metrics before anyone acts on it. Almost nobody performs that adjustment. What ends up in the queue is the raw base score, applied identically to a machine facing the internet and a machine that has never left a lab.
Two consequences follow, and both are familiar.
The first is that the critical band stops discriminating. When a large part of your register carries a score in the same narrow range, "work the criticals first" is not an order at all — it is a pile, and the sequence inside it comes down to whoever sorted the spreadsheet.
The second is that the register loses credibility with the people who have to act on it. A system owner who is asked three times to take an urgent outage window for something that turns out to be unreachable will treat the fourth request as noise. You do not get that trust back by raising the threshold.
The four questions that actually order the queue
Each of these is answerable from data you already hold or can get free, and each one moves items past a raw score.
| Question | Where the answer comes from | Why it outranks the score |
|---|---|---|
| Is it being exploited now? | CISA's Known Exploited Vulnerabilities catalogue, which lists flaws with reliable evidence of active exploitation | Someone has already done the hard part. Proof of use beats a prediction of difficulty. |
| Is it used in ransomware? | The same catalogue carries a field marking flaws known to be used in ransomware campaigns | It changes the worst case from data loss to an estate-wide outage, which changes who signs the change request. |
| Can it be reached? | Your own asset inventory: exposure, network position, whether the vulnerable service is actually listening | An unreachable flaw needs a foothold first. That is a second event, not this one. |
| What is on the machine? | Ownership of the asset, and the business impact of losing it | A domain controller and a print server are not the same finding with the same score. |
The first two say whether the world has made this urgent. The last two say whether your estate has. A finding needs both halves to reach the top, and that is the whole of the model.
A high score on a machine nobody can reach is not the most urgent thing you own
Take one flaw, one score, two hosts. On the reverse proxy terminating your public traffic, the vulnerable service is listening, the catalogue says it is being exploited, and the exploit is being used by ransomware operators. On the lab virtual machine behind two firewalls with no route in, the same flaw sits at the same score and is reachable only by someone who already has a foothold.
A queue ordered by score puts these two next to each other. A queue ordered by exploitability puts the first one at the top today and the second one on the schedule. The severity did not change. The urgency was never in the severity.
This is also where the ranking earns its keep in the other direction. A moderate-scoring flaw on an internet-facing box, marked as exploited in the wild, outranks half your critical band. Nothing in a CVSS-sorted list will ever surface it.
Ranking is worthless until the finding is qualified and the coverage is stated
Two things have to be true before an order means anything.
The finding has to be real. Two scanners reporting one weakness on one host is corroboration, not a duplicate to be deleted. Agreement between an agent-based scanner and an agentless one is the strongest cheap signal you can get that a finding is not a false positive produced by the way one tool looks. Seculogik corroborates first and ranks second, because arguing about the position of a finding that may not exist is the most expensive kind of meeting.
The coverage has to be on the screen. "No criticals" across ten hosts out of four hundred is not good news, and should not be allowed to look like it. Every view in the register states how much of the estate was examined before it states any figure. It is the same rule the rest of the platform holds itself to — a zero must be explainable, because a clean dashboard that is actually blind is worse than no dashboard.
Two clocks: a remediation is measured in days, an incident in minutes
The most common mistake after the ranking one is running vulnerabilities through the incident queue. They do not fit the shape.
An incident is measured in minutes to acknowledge. It belongs to the SOC, a tier 1 analyst works it inside one shift, and it ends in a verdict.
A remediation is measured in days to patch. It is owned for weeks by somebody outside the SOC, it needs a change window, and it ends in a fix, a formal acceptance, or silence.
Reuse the incident deadlines for vulnerabilities and every finding is in breach the second it is created, which trains everyone to ignore the breach count. So the two run on separate clocks in Seculogik, and are linked read-only in both directions: an analyst working a case can see what was known to be weak on that host, and a system owner can see the case. Neither can edit the other, and a weakness present during an incident is not treated as proof it was the way in.
Accepted risk that never expires is not a decision
Sooner or later the answer is "we are not fixing this". That is a legitimate outcome, and it is the one most registers handle worst, because the acceptance is terminal. The compensating control gets decommissioned, a working exploit gets published, the business context changes — and the acceptance keeps holding, because nothing ever asks again.
Every risk acceptance in the register carries an expiry. When it lapses, the item comes back for review with its original reason attached. Nothing rewrites the human decision on a timer: the record that the risk was formally accepted, by whom and why, is the point of keeping it.
Where this sits in the product
The Vulnerability Operations Centre comes with the Client edition. It is not one of the six modules and is not sold on top — the distinction matters, because a buyer should never meet a capability for the first time on a quote. Only the committee-ready posture report belongs to the SOC Reporting module, and the Threat Intelligence module deepens the exploitation context. The register works without either.
It reads the scanners you already run — agent-based, agentless, or findings already sitting in the index you operate, whether that is Elastic, OpenSearch, Splunk or Wazuh — and if yours is not covered, we build the connector. Everything runs on one self-hosted box, with no per-gigabyte meter and nothing sent anywhere.
Our own commitments are on the security and trust page, including what we do not hold: no third-party pentest report, no certification, no SLA. We are pre-GA, with no customers to name.
Ranked by exposure, corroborated across sources, owned by a named person with a date, and expiring when the risk is accepted. That is a register people keep opening.
If your vulnerability queue is currently sorted by score, see what the Vulnerability Operations Centre does with it, check which edition includes it and what each of the six modules adds — then bring an export of your current findings to a demo and we will show you the order they come out in.