Validating Scanner Findings: Separating Real Issues From Noise

A scanner produces findings, not facts. Every mature vulnerability management programme spends more effort validating and prioritising output than generating it, and a programme that treats scanner output as a work queue drowns within a quarter.

Where false positives come from

Version matching without context. The scanner sees a version string and reports every vulnerability associated with it. That ignores backported patches — distribution maintainers fix flaws without changing the upstream version — which is the single largest source of false positives on Linux estates, and the matching problem described under CPE.

Unreachable code. A vulnerable function present in a library the application never calls is real in the sense that the code is there, and lower risk than the severity score implies.

Configuration dependence. Many vulnerabilities apply only when a feature is enabled. The scanner identifies the product, not how it is configured.

Compensating controls. A finding on a host that is unreachable from anywhere it could be exploited from is a different risk from the same finding on an internet-facing system, and the scanner does not know the network.

Inference from behaviour. Web scanners frequently conclude a flaw exists from an error message or a timing difference that has another explanation.

False negatives matter more

Less discussed and more dangerous, because nothing tells you they happened.

Unauthenticated scans see far less than authenticated ones — frequently half as much — and many organizations run unauthenticated scans because credentials are awkward to manage. Components with no identifiable version, vendored or bundled code, and anything outside the asset inventory are all invisible. Business logic flaws are not in any scanner's model at all.

The practical implication: a clean scan means the scanner found nothing, which is a weaker statement than it appears.

Validating a finding

A repeatable sequence, ordered by effort.

Confirm the component and version from the system itself rather than from the scanner's inference, and check whether the distribution's advisory says it is patched.

Check applicability — is the affected feature enabled, is the vulnerable path reachable, does the configuration match the advisory's conditions.

Check exposure — who can reach this system, from where, with what authentication.

Attempt confirmation where a safe check exists. A non-destructive proof is worth far more than a version match when you need someone to schedule an outage to fix it.

Document the outcome either way. A finding validated as a false positive should be suppressed with a reason and a review date, not silently — because the reason may stop being true when the configuration changes.

Prioritising what survives

Severity alone is a poor ordering. Weight by exploitability, since a medium-scoring vulnerability under active exploitation outranks a high-scoring one nobody has ever used — the argument for EPSS and known-exploited catalogs.

Then by exposure and asset criticality, which requires knowing what the system is and who depends on it — the context that a maintained CMDB supplies and whose absence is why so many programmes prioritise badly.

Then by effort, pragmatically. A hundred findings closed by one patch cycle beats three closed by a migration.

Running it sustainably

Route findings to the team that owns the system with a due date, rather than into a central security queue that no one else can action. Set remediation targets by severity and exposure, and measure against them — the mean time to remediate family, with the age of open findings mattering more than the count.

Where a finding cannot be fixed, it becomes a documented exception with a compensating control, an owner and an expiry — the handling under security control types — rather than an item that stays open indefinitely.

And distinguish scanning from testing. Scanners cover known vulnerabilities in identifiable components; authorization flaws, business logic and chained findings need the manual work described under web application testing methodology. A clean scan report and a competent tester reach very different conclusions about the same application.

Exam angles

Know that scanners produce both false positives — from version matching, backported patches, unreachable code and configuration dependence — and false negatives from unauthenticated scanning, unidentifiable components and unknown assets. Know authenticated scanning as finding substantially more. Recognize validation as confirming component, applicability, exposure and where possible exploitability, and prioritisation by exploitability and asset criticality rather than severity score alone.