How we set remediation priority by risk, not by score

A score is useful as a shared language: it says how serious a flaw is in itself, comparably across reports and across vendors. What it doesn’t say is which system the flaw sits on and who can get to that system. Ten findings with the same number can be ten different risks. What a CVSS score actually measures is worked through in a separate glossary entry. This article is about what happens with the score next.

So the remediation priority isn’t a sorted column of numbers. It is a decision that takes in a few more things the score cannot know. Those are what it comes down to, and they are why a finding scored 7 sometimes gets fixed before one scored 8.

When we compare two findings in a report, we look at four things the number itself doesn’t cover. Any one of them can turn the order around.

• Exploitability: whether a finished public exploit exists for the flaw, or whether it is already being exploited in the wild. A flaw you only need to download a tool for is urgent in a different way from a theoretical one.
• Reachability: where the system can be reached from. Some systems are exposed to the internet, some sit behind a VPN and a login, and some only in an isolated segment an ordinary attacker never gets into.
• The value of the system: what happens to the business when it is exploited. A payment gateway and an internal wiki are not the same thing, even when the same flaw sits on both.
• Chaining: whether the finding can be joined with others into a single path. It means several small things add up to a way in that none of them would be enough for on its own.

Of those four the score knows a piece at most, and even that only indirectly. It describes a flaw in a generic installation: it doesn’t know whether your particular system is reachable from the internet, or whether something runs on it the company would genuinely lose. Exploit maturity and current threats sit in separate metrics that don’t count toward the base number, so a report giving only the base score simply doesn’t carry that layer.

Chaining changes the order most, and in a purely numerical list it is invisible. Three findings, each below average on its own, can together form a path from the public website all the way to the database. Anyone fixing from the top down by number leaves those three for last, because individually they look harmless. What a manual test sees in chaining, that is, what a manual test finds and a scanner doesn’t, is worked through in the comparison with a scanner.

The standard allows for this: alongside the base metrics it has a group that adjusts the result to a specific environment. There you can record that a given system is essential to the company, or the opposite, that it is cut off from the internet, and the number adapts. We fill that group in according to what actually holds in your environment, not according to a generic installation.

In practice that means the same finding can end up with a different remediation priority at two clients. A flaw on a system that one company exposes to its customers and another runs in a lab with no connectivity gets a different urgency, even though it is bit for bit the same finding. On top of that, for some findings there is nothing to copy from: flaws in authorization or in business logic have no public number, so both the score and the reasoning rest purely on the tester, and the glossary describes when a finding has no CVE.

An example shows it best. Take two findings from one test. The first is a high-scoring flaw in an internal warehouse management tool that a handful of people in one office reach and that is invisible from the internet. The second is a mid-scoring flaw in the login form of an online store that is open to everyone and that payments flow through.

By the number, the first one would be fixed. By risk, the second goes first: it is reachable from anywhere, it sits on a system that earns money, and a flaw in the login is the first step toward customer accounts. A high score on a hidden thing can wait. A middling score on an exposed and valuable one can’t.

The second reversal comes from chaining. A finding that on its own only allows reading a seemingly harmless configuration file moves up the moment that file holds a password to another service. Low on its own, high as a link in a chain. That is exactly what a number on paper misses, because it rates every finding separately.

No formula orders the fixes on its own. Judgment goes into it, and judgment doesn’t fit into a vector. First comes triage of false alarms: before a finding enters the order, we verify that it is real and exploitable in your configuration, not just a message from a tool. A finding that can’t be exploited in practice has no business at the top of the list, whatever its number.

The second is knowledge of the business, which the tester doesn’t have and the client supplies. Sometimes a system with an ugly finding is a few weeks from being retired and there is no point investing in it. Other times a small thing sits on a process that must not fall over in the middle of the season. Those exceptions belong in the order, and we go through them at the handover rather than guess at them.

So the result isn’t just a sorted export. It is a recommendation with the reason attached, and you can rearrange it to fit your context. The formula gives the starting point. Judgment gives an order you can actually work with.

In the report this shows up as three things carried by every finding: the severity, the remediation priority, and a short reason why it sits where it sits. The reason is what matters. Without it the priority is just another number you can’t argue with. What the report contains and how we hand over findings in it are on the penetration testing page.

By four things the score itself doesn’t know: whether a finished public exploit exists for the flaw, where the system can be reached from, what value it has for the business, and whether it can be joined with other findings into a single path. The score gives the starting urgency, and those four inputs turn it into an order you can actually work with.

The base score doesn’t. It describes the properties of the flaw in a generic installation and takes neither exploit maturity nor current threats into account. Those sit in separate metrics that don’t feed into the base number. So a report that gives only the base score says nothing about the availability of an exploit, and we add that to the remediation priority separately.

Chaining joins several findings that are minor on their own into one attack path that none of them would be enough for. That raises their priority: a finding that only reveals a configuration file moves up when that file holds a password to another service. In a list sorted by number, chaining is invisible, because every finding is rated separately.