What a vulnerability scan sees, and what it misses

Objective 3.1 in this course covers vulnerability scans — CompTIA describes it as conducting authenticated, unauthenticated, static application security testing (SAST) and dynamic application security testing (DAST). This lesson sets up what a scanner can and cannot do; lessons 16 and 17 take the specific kinds.

Why this matters

Vulnerability Discovery and Analysis is 17% of PT0-003, and the domain's centre of gravity is not running scans — it is judging them. Lesson 1 drew the line between a scan and a penetration test; this is where that line becomes practical work.

A scanner produces a list. A tester produces an assessment. The distance between the two is the value of the engagement, and a report that is a re-formatted scan export is the most common way to waste a client's money.

The lesson

Signature and version matching, and its failure modes

Most of what a scanner reports comes from matching observed detail — a banner, a file version, a response pattern — against a database of known issues.

That mechanism has predictable failure modes, and you should be able to name them:

• False positives from version strings. The scanner sees an old version and reports its known issues. Backported patches (lesson 10) break this: the version stayed, the fix landed.
• False negatives from unfamiliar things. Custom applications, unusual configurations and anything not in the database produce silence — not "secure", just unrecognised.
• Configuration-dependent issues, where whether the flaw is reachable depends on settings the scanner cannot see without credentials.
• Feed staleness. A scanner is only as current as its plugin feed, and a clean scan from an out-of-date feed is worth very little.

Why a scanner cannot find a logic flaw

This is the most important structural limit, and the clearest exam distinction.

A scanner recognises known patterns. A logic flaw is an application behaving exactly as built, where what it was built to do is wrong: a checkout that trusts a client-supplied price, a workflow that lets you approve your own request, an identifier you can change to read another customer's order.

No signature exists for these, because they are unique to the application. They need someone who understands what the application is for — which is why penetration testing exists alongside scanning, and why an application in scope deserves a human even when its scan is clean.

The related class: chained findings. Two mediums that together give full compromise will be reported as two mediums, because a scanner assesses findings individually. Recognising the chain is Domain 5's attack narrative, and it is usually the headline of the report.

Coverage: the hosts the scan never reached

A scan's most dangerous output is silence about things it never looked at.

Ask, every time, before reading any results:

• Which addresses were in the target set, and how does that compare with the inventory from Domain 2? A scan of the asset list inherits the asset list's omissions.
• What was unreachable — filtered by a firewall, on a network segment the scanner could not route to, or switched off.
• What was excluded deliberately, such as the fragile systems from lesson 8.
• Did it complete? A scan that timed out or was cancelled produces partial results that look exactly like complete ones.

Coverage belongs in the report explicitly. "We scanned 412 of the 500 addresses in scope; 88 were unreachable from our position" is a finding. Reporting results without it implies completeness you did not achieve.

Scan windows, and the asset that was switched off

A scan is a snapshot of whatever happened to be running at that moment.

That interacts badly with how estates actually behave: laptops are off overnight, development environments are shut down at weekends, autoscaling instances exist for an hour, and maintenance windows take things offline exactly when you are most likely to be scanning.

So a host absent from results may be absent from the network or merely absent at that time — and those mean very different things. Where it matters, scan at more than one time of day, and record when each scan ran. This is also why the authenticated agent approach in lesson 16 is attractive for laptops.

A clean scan is not evidence of a secure system

Everything above assembles into the claim that most needs making to clients, and it is worth being able to make it crisply.

A clean scan means: the checks this tool knows about, with this feed, from this position on the network, against the hosts it could reach, at this time, found nothing recognisable. It says nothing about logic flaws, nothing about what it could not reach, nothing about custom code, and nothing about tomorrow.

The professional obligation is to say so in the report rather than let a clean result be read as assurance. Lesson 1's four limits — not proof of absence, point in time, bounded by scope, reflects the testers — all apply here in their sharpest form, and a client acting on a misread clean scan has been failed by the report rather than by the scanner.

What to take into the exam

• Scanners match known patterns; that is why they cannot find logic flaws or recognise chains.
• Backported patches create false positives from version strings; unfamiliar software creates false negatives.
• Coverage is part of the result: what was targeted, unreachable, excluded, and whether the scan completed.
• A host missing from results may have been off, not absent.
• A clean scan is a bounded statement, and the report must bound it explicitly.