A scanner rates a vulnerability in the abstract: what the flaw allows in a default deployment, expressed as a Common Vulnerability Scoring System base score. That is what a base score is for, and it does that job well. It is not a statement about your estate, and it was never meant to be read as one. The ranking a test report needs is a different question, answered by trying it.
What a critical often turns out to be
In the prior work I have described, the majority of findings a scanner rated critical could not be exploited in that environment, as configured, from a position the scope allowed. Three reasons account for nearly all of them. The affected service was not reachable from any position in scope. The vulnerable code path was not enabled in that deployment. Or the package version string was misleading, because the vendor had backported the fix. The last is routine on Red Hat Enterprise Linux and its derivatives, where the version number does not move when the patch lands, and it produces a steady supply of critical ratings against hosts that are fully patched.
What the shortest path usually is
The chain that most often reached a domain administrator account started below medium. Link-Local Multicast Name Resolution and NetBIOS Name Service left enabled, which a scanner reports as informational if it reports it at all. Server Message Block signing not required on a file server, rated medium. A captured NTLMv2 hash relayed to a host where the same account held local administrator rights. The other recurring path was an Active Directory Certificate Services template that let the enrollee supply the subject and permitted client authentication. No scanner I used reported that one, because it is a configuration the product supports.
None of the three steps in that chain is a vulnerability with a CVE identifier. Two of them are defaults.
The ordering the report itself encourages
For most of those 6 years I printed the findings table sorted by base score, then spent the debrief arguing that the order was wrong. Clients worked down the table as printed, which is what any sensible person does with a table from their tester. The prioritisation I complained about was the prioritisation I had supplied. That is the reason this note exists, and it is the change I would make first anywhere.
The five fields we print against every finding
- Whether the finding was exploited, and from which starting position
- What it reached, named — host, account, dataset
- Whether any chain in the report depends on it
- The base score, printed but not used for ordering
- The retest result and the date the fix was confirmed
The table is ordered by what we reached and how. The report is delivered 10 working days after fieldwork ends, and a retest within 90 days confirms each fix before the report closes, so the last field is filled in by us rather than asserted by anyone.
Exploit Prediction Scoring System scores and the CISA Known Exploited Vulnerabilities catalogue both belong in the report, and both are in ours. They are population statistics. They do not know that the affected host sits on a segment nothing routes to, or that the service account behind an unremarkable medium is a domain administrator. That part is still a person trying it and writing down what happened.
Two honest limits. This ordering costs more to produce than a sorted scanner export, and it rests on the tester's judgement about what a chain depends on, which two testers can read differently. Where ours have, both readings go in the report with the evidence behind each, and your engineer decides. The second limit is that I cannot yet tell you whether printing the table this way changes what gets fixed first. That takes retests counted across enough engagements to compare against a scanner-sorted table. When they are in, the comparison gets published.