What a Scanner Finds, and What It Cannot

Vulnerability scanners are good tools that are frequently sold as something they are not. The useful framing is not "automated versus manual" as a contest, but two specific lists: what a scanner detects reliably, and what it cannot detect at all.

Both lists are concrete, and once you have them, the question of what you are buying answers itself.

What scanners genuinely do well

These are not consolation prizes. For each of them, automation outperforms a person.

• Known vulnerabilities in known versions. A scanner identifies software and matches it against published advisories, across thousands of hosts, in an afternoon. No tester can do this at that scale or that accuracy.
• Missing patches and end-of-life software across a large estate.
• Configuration against a baseline — transport security settings, cipher suites, certificate problems, security headers, default accounts, unnecessary services.
• Vulnerable dependencies. Software composition analysis reads your manifest and flags known-vulnerable libraries. Doing this manually is not realistic on a modern dependency tree.
• Breadth. A scanner checks every host for every known issue without getting bored. Coverage is where automation is unbeatable.
• Repetition. Run it weekly and it catches regressions and newly published vulnerabilities in software you already had. This is the strongest argument for continuous scanning, and it is a real one.

An organisation not scanning continuously has a gap that no annual test closes, because a test describes one day and new vulnerabilities are published on the others.

What scanners cannot find

Not "find less well" — cannot find, for structural reasons.

Authorisation flaws

A scanner does not know that invoice 1042 belongs to a different customer than invoice 1041. It has no model of who owns what, so a response containing another customer's data looks exactly like a successful request. Broken access control is consistently among the most common serious findings in web applications, and it is close to invisible to automation.

Business logic flaws

Applying a discount twice. Reaching the final step of a process without the preceding ones. A negative quantity that credits an account. Every request involved is well-formed and individually legitimate — there is no malformed input to pattern-match. A scanner has no concept of what the workflow is supposed to achieve.

Chained exploitation

Three findings, each moderate on its own, that combine into a full compromise because one yields what the next requires. Scanners report findings as a list of independent items. The chain is an act of reasoning across them.

Context-adjusted severity

A scanner assigns severity from the technique. The same flaw is not the same risk in a payment system as in an internal room booking tool. Without knowing what the data is and who can reach it, every score is generic — which is why scanner output tends to be simultaneously alarming and unhelpful.

Anything requiring a sequence

Multi-step workflows, state that depends on prior actions, race conditions between two requests, features only reachable after a specific set-up. Scanners work request by request.

The two error modes

False positives are the visible cost. Raw scanner output contains a substantial proportion of findings that are not exploitable in context — a reported flaw in a code path that cannot be reached, an issue already mitigated by a control the scanner cannot see. Triage is real work, and a "report" that is unfiltered scanner output has transferred that work to you.

False negatives are the expensive one, because they are silent. A clean scan reads as good news. What it means is that nothing on the scanner's list of known patterns matched — which says nothing at all about the authorisation model, the business logic, or anything specific to your application. Most of what a penetration test exists to find sits entirely outside what a clean scan is evidence of.

How to tell what you actually received

Four signals, in order of reliability:

• Findings with no application-specific detail. If every finding could appear verbatim in a report for a different company, it was generated rather than written.
• No authorisation findings, and no evidence any were attempted. Either the application is unusually well built, or nobody held two accounts at once.
• Reproduction steps that are tool output. A verified finding shows the request that produced the result and the response that came back. "Scanner detected SQL injection" is a hypothesis.
• Identical severities to the tool's defaults, with no adjustment for what the affected system holds.

The corresponding question at proposal stage: how much of the engagement is manual, and what will the manual portion be spent on? A credible answer names activities — authorisation testing across roles, business logic review of named workflows, chain analysis. An evasive one talks about proprietary technology.

How they fit together

The sensible arrangement is not a choice between them. Scan continuously, because that is what catches the newly published vulnerability in software you have run for two years. Test periodically with people, because that is what catches the flaw that is unique to how your application works — and it is the half that no tool will ever reach.

Where the balance sits for a given engagement, and what it does to the price, is covered in what moves the price of a penetration test. What the resulting document should look like either way is in what is actually inside a VAPT report.