SECURITY
What a vulnerability scan with 4,000 findings is telling you
5 min read
A vulnerability scanner reports severity, which is a property of the vulnerability in the abstract, so findings have to be re-ranked by exposure and exploitability in your environment before the list means anything actionable.
The first scan of an environment that has never been scanned produces a number large enough to be useless. Four thousand findings, several hundred of them critical, across a few hundred hosts.
The instinctive response is to start at the top of the list. That is almost always the wrong order, and it is why first remediation efforts often spend weeks without measurably reducing risk.
Severity is not risk
A scanner assigns severity from a standardised score describing how bad the vulnerability is if exploited, under assumptions about the target. It knows nothing about whether your affected host is internet-facing, whether the vulnerable service is running, or whether anything valuable is reachable from it.
A critical finding on an isolated internal appliance with no route to anything matters less than a medium finding on an internet-facing server holding customer data. The scanner cannot make that distinction; you can.
Re-rank by exposure, then exploitability
Exposure first: is the affected system reachable from the internet, from the general corporate network, or only from a restricted segment? This single question reorders the list more than any other.
Then exploitability: is there a known exploit in active use? Public exploit code and inclusion in known-exploited catalogues matter far more than the theoretical score, because they describe what attackers are actually doing rather than what is possible.
- Internet-facing and known-exploited — fix now, out of cycle if necessary
- Internet-facing, no known exploit — next patch window, tracked
- Internal, known-exploited — next patch window, with compensating controls meanwhile
- Internal, theoretical — routine patching, do not treat as a project
Most of the list is one patch
Large finding counts are usually concentrated. A few hundred findings resolve to one superseded cumulative update across many hosts, or one end-of-life runtime installed everywhere.
Grouping findings by the fix rather than by the finding often converts four thousand items into a few dozen actions. That is the list a team can actually work from, and it makes the progress reporting honest.
What cannot be patched
Every environment has findings with no available fix: unsupported systems a vendor no longer updates, applications that break on the patched runtime, appliances the supplier controls.
These need compensating controls and a written acceptance with an owner and a review date, not an indefinite place on the open list. A backlog that contains the same two hundred unfixable items every month trains everyone to stop reading it.
The number worth reporting
Total findings is a poor metric because it moves with scan scope. More useful: time to remediate internet-facing critical findings, the count of known-exploited vulnerabilities currently open, and the age of the oldest unresolved high-exposure item.
Those three describe whether the process is working. The total count mostly describes how much you scanned.
Questions we get asked
How often should we run vulnerability scans?
Continuously or at least weekly for internet-facing systems, where exposure changes fastest. Monthly is usually adequate internally, provided the results feed a tracked remediation process rather than an archive of reports.
What is the difference between a vulnerability scan and a penetration test?
A scan enumerates known vulnerabilities automatically across many systems. A penetration test is a scoped human exercise that chains weaknesses together to demonstrate real impact. They answer different questions and a scan is not a substitute for a test, or the reverse.
Where should we start if we have never scanned before?
Scan the internet-facing estate first and remediate that fully before widening scope. It is the smallest list, the highest exposure, and it produces a visible result quickly, which matters for sustaining the effort through the much larger internal pass.