Reading scanner output without believing all of it

Why this matters

A scanner produces a list. The list is evidence, not conclusions, and the gap between those two words is where an analyst earns their place.

Objective 2.2 is about analysing that output, and the exam consistently rewards the same instinct this course has applied to alerts, indicators and model output: verify before you escalate. A vulnerability programme that forwards raw scanner output to engineering teams loses their trust in about three weeks, and once lost, genuine criticals get the same shrug as the noise.

The lesson

Anatomy of a finding: plugin, evidence, remediation

Whatever the product, a finding carries the same components, and knowing which is which tells you how much to trust it.

• The check identifier — plugin ID, QID, template name. Stable across scans, and what you use to track or suppress a specific test.
• The title and description, usually vendor-written prose about the class of problem. Generic.
• The severity or score, normally CVSS, covered properly in the next lesson.
• The affected asset, with port and protocol, and sometimes the specific software instance.
• The evidence. This is the part that matters. The banner returned, the file version found, the registry value read, the response to a probe. A finding with weak evidence is a weak finding no matter how alarming its title.
• The remediation guidance, usually generic and sometimes wrong for your platform.
• References — CVE, vendor advisory, exploit availability.
• First seen and last seen dates, which turn a list into a trend.

The discipline: read the evidence field before you read the severity. A critical finding whose evidence is "server returned Apache/2.4.29" is an inference about a banner. A critical finding whose evidence is "file version 10.0.19041.1 read from disk under credentialed scan" is an observation. Those deserve different confidence and often different urgency.

False positives and how to prove one

A false positive is a finding that is not true of the system as deployed. They are common, and the common causes are worth knowing because they repeat.

• Banner and version inference. The service reports a version, the scanner maps it to CVEs. Wrong whenever the banner is customised, suppressed, or deliberately misleading.
• Backported patches. The big one, and a favourite exam topic. Enterprise Linux distributions fix vulnerabilities while keeping the original version number, so 1.2.3-45 may contain the fix that upstream shipped in 1.2.7. Version-based checks flag it; the system is patched. The proof is the distribution's package changelog, not the version string.
• Compensating configuration. The vulnerable feature is disabled, the module is not loaded, the affected code path is unreachable.
• Wrong platform mapping, where a Windows check matches something on a Linux host or a network appliance.
• Inherited detection on load balancers or proxies, where the scanner attributes the front-end's characteristics to every backend.
• Duplicate identity, where two scanner records are the same physical host.

How to prove one properly:

1. Reproduce manually. Connect and check the version, read the file, query the package manager. Do not argue from the report.
2. Check the vendor's advisory for the fixed version in your distribution, including backports.
3. Verify the configuration the finding depends on.
4. Test the actual behaviour where it is safe to do so.
5. Write down the evidence and the date, and suppress the specific check for the specific asset — never the check globally.

That last point is the one that costs organisations dearly. Suppressing a check estate-wide to clear one false positive silently disables it everywhere, and nobody will notice when it would have been true. The same shape as the SIEM tuning error in lesson 10, with the same fix: narrow, documented, dated, reviewed.

False negatives: the ones that cost you

False positives waste time. False negatives lose data, and they are much harder to see because the output looks clean.

Why they happen:

• No credentials. The largest single cause, and covered in lesson 17.
• The host was off, asleep, or not on the network during the window.
• The port was filtered between scanner and target, so the service was invisible.
• The check does not exist. New vulnerabilities have no plugin until the vendor writes one — a real gap in the days after a major disclosure, which is exactly when it matters.
• The asset is not in scope, which is the inventory problem from lesson 18.
• The vulnerability class is not detectable by that tool at all, per lesson 19's authorisation and logic flaws.
• Scan depth limits — a crawl that stopped, a timeout, a truncated enumeration.

What to do about them, given you cannot see them directly:

• Compare the scanned count with the inventory count, every time. This one comparison catches most of it.
• Check the scan's own error and coverage data: authentication failures, hosts unreachable, checks skipped. Every scanner reports this and almost nobody reads it. A scan where credentialed authentication failed on 200 hosts is not a clean result for those hosts, and the report will not say so on the front page.
• Use more than one method — agent and network, active and passive — and investigate the disagreements.
• Hunt for specific critical vulnerabilities directly after a major disclosure rather than waiting for the plugin.

Deduplication and asset identity problems

The same vulnerability appears repeatedly and the same host appears as several assets, and both distort the numbers.

Sources of duplication:

• A host with several addresses — multiple interfaces, or DHCP giving it a new one between scans, producing two asset records with two copies of every finding.
• Agent and network scans of the same host reported separately.
• One underlying cause, many findings. An outdated framework generates a finding per CVE; a single upgrade closes forty.
• Shared infrastructure: a vulnerability in a base image appears on every container built from it.
• Load-balanced pools, where one virtual address represents many servers.

Why it matters beyond tidiness: duplication inflates the finding count, which inflates the apparent workload and distorts prioritisation. A team told they have 12,000 findings behaves differently from one told they have 800 root causes — and the second number is the true picture of the work.

Handling it:

• Deduplicate on a stable identifier — asset UUID, machine GUID, cloud instance ID — not an IP address.
• Group by root cause for reporting: by package, by image, by template.
• Track the fix, not the finding. One upgrade ticket is more useful than forty vulnerability tickets.
• Reconcile agent and network results into one asset record.

Comparing scans over time

A single scan is a photograph. The programme lives in the comparison between them, and that comparison answers questions a snapshot cannot.

What to look at:

• New findings since the last scan — from new deployments, new disclosures, or configuration drift.
• Resolved findings, and why they resolved. This is where care is needed: a finding can disappear because it was fixed, because the host was decommissioned, or because the scan failed to authenticate this time. The third case looks identical to the first in the summary and is the opposite of good news.
• Recurring findings — fixed then reappearing. This is a process failure, not a technical one: an image that was never updated, a configuration management system reverting the fix, or a rebuild from an old template. Worth its own attention in the reporting lesson, because the root cause is never the vulnerability.
• Ageing. How long findings stay open, by severity. The distribution matters more than the mean — a long tail of ancient criticals tells a story an average hides.
• Trend direction. Is the backlog growing or shrinking, and is the change explained by remediation or by scope changes?

The caution to carry into Domain 4: a metric that improves because you looked less carefully is worse than one that got worse honestly. Scope reductions, failed authentication and decommissioned assets all move the numbers in the flattering direction. Anyone reading your trend deserves to know which of those happened, and saying so is what makes the rest of the report believable.

Topics this lesson owns

• [x] Anatomy of a finding: plugin, evidence, remediation
• [x] False positives and how to prove one
• [x] False negatives: the ones that cost you
• [x] Deduplication and asset identity problems
• [x] Comparing scans over time