Reading a vulnerability report without panicking
Twelve critical findings sounds like a catastrophe. Often it is four real issues and eight false positives. Here is how to tell.
A vulnerability report lands in your inbox with a summary that reads: 12 critical, 34 high, 89 medium. The natural reaction is alarm.
Before acting on that, it is worth understanding what those numbers mean — because raw scanner output and a verified assessment are very different documents that can look superficially similar.
Severity is generic. Risk is yours.
CVSS scores are assigned to a vulnerability in the abstract. They do not know that the affected service is on an internal network with no route from outside, or that the vulnerable function is never called in your configuration.
A critical-rated finding on a system nobody can reach may be less urgent than a medium-rated one on your public login page. Any assessment worth paying for makes that distinction explicitly. If yours does not, that is a question worth asking the firm that produced it.
The false positive problem
Scanners infer. They see a version number in a banner, look up the vulnerabilities associated with that version, and report them — without establishing whether the vulnerable component is actually in use, or whether the distribution backported the fix while leaving the version string unchanged.
In our experience, unverified scanner output on a typical estate runs somewhere between 30 and 60 percent false positives on the higher severities. This is why manual verification is the part of an assessment that takes the time, and the part worth paying for.
Questions to ask about any finding
- Was this verified by hand? If not, treat it as a candidate rather than a finding.
- Can you show me the reproduction steps? A real finding comes with a path to reproduce it.
- What would an attacker actually achieve? Not what the CVE says in general — what happens here.
- What is the fix, specifically? "Apply security best practices" is not remediation guidance.
A sensible order of work
Once you have separated verified findings from noise, sequence by exploitability and blast radius rather than by severity label:
- Anything externally reachable that gives code execution or data access
- Anything affecting authentication or authorisation
- Anything exposing data, even at lower severity
- Everything else, batched into your normal maintenance cycle
A report that lets you do that is doing its job. One that leaves you with a number and no way to sequence the work is not.