Vulnerability scanning: strategy before tooling

Why this matters

Vulnerability management is a programme, not a scanner, and the difference is where organisations lose. Buying a scanner is a procurement decision anybody can make; deciding what it scans, how it authenticates, who owns what it finds and how success is measured is the architecture, and that is what CAS-005 examines.

The single most important idea arrives from lesson five and is worth restating because it dominates everything here: a vulnerability programme cannot exceed the completeness of its asset inventory. Every improvement to scanning technique operates on the known set, and the unknown set is disproportionately where the risk lives.

The second idea is that scanning is a measurement with known biases. An unauthenticated scan systematically under-reports. A network scan cannot see a host it cannot route to. An agent reports about the host it is on and nothing else. Knowing each method's blind spot is what lets you combine them so the blind spots do not coincide — which is the same reasoning lesson twenty applied to enforcement points.

The lesson

Authenticated and unauthenticated scanning, and the very different pictures they give

Unauthenticated scanning probes from the network with no credentials. It sees what an unauthenticated attacker sees: reachable ports, service banners, responses to probes, and web application surface. Its findings are inferential — a version string suggests a vulnerability rather than proving one.

• Strength: it measures exposure honestly, which is what an external attacker faces, and it needs no access to the target.
• Weakness: it under-reports heavily. Missing patches, insecure local configuration, weak permissions and installed-but-unused software are all invisible. Banner-based inference also produces false positives where a vendor has back-ported a fix without changing the version string.

Authenticated scanning logs in and inspects directly: installed packages and patch levels, configuration, local accounts and permissions, registry or filesystem state.

• Strength: far more complete and far more accurate, with fewer false positives and dramatically fewer false negatives.
• Weakness: it requires credentials on every target, and those credentials are themselves a serious asset — a scanning account with administrative rights across the estate is precisely the identity an attacker wants.

The examinable point is that these are not alternatives; they answer different questions. Authenticated scanning tells you what is wrong. Unauthenticated scanning tells you what is reachable. A programme running only authenticated scans has an accurate list of defects and no view of exposure; one running only unauthenticated scans systematically misses most of what is wrong and reports the rest with poor confidence.

Protecting the scanning credential is a design problem with standard answers: a dedicated account used for nothing else, permissions restricted to what scanning needs rather than full administration, source restriction so it can only be used from the scanner, vault-managed rotation, and monitoring for its use from anywhere unexpected. A scenario describing a compromise that moved laterally using a scanning account is describing the absence of all five.

Agent-based, network-based and cloud-native scanning across one estate

Three delivery models, and the practical answer is layered.

Network-based. A scanner reaches targets over the network. No installation required, so it covers appliances, embedded devices and anything that cannot host software. Blind to anything it cannot route to — which, in the segmented estate lesson twenty built, is a lot — and heavy on network and target load.

Agent-based. Software on each host reports continuously. It sees the host completely, works wherever the host is including off-network and remote, needs no inbound connectivity through segmentation, and produces near-continuous data rather than a periodic snapshot. It requires an agent on everything, so it cannot cover what will not take one, and the agent is privileged software to deploy, maintain and patch.

Cloud-native. The provider's own assessment of resources and, increasingly, of workloads through snapshot-based analysis that needs no agent. It has complete visibility of the account's resources, sees configuration as well as software, and adds no load to running workloads. It covers only that provider, and only accounts you have connected — which returns, again, to completeness.

The layering that works, and the reasoning is blind-spot disjointness:

• Agents on everything that takes one — servers, endpoints, cloud instances. This is the backbone.
• Cloud-native assessment on every account and region, from the organisation structure rather than a maintained list.
• Network scanning for what has no agent, and — separately and importantly — from outside, to measure external exposure.
• Pipeline scanning of images and dependencies before deployment, covered below.

The examinable judgement is matching method to asset type. A scenario naming an asset class — an unpatchable medical device, a laptop that is rarely on the corporate network, a serverless function — is usually asking which method still applies.

Scan scope driven by the asset inventory, so an unknown asset is a known gap

The architectural requirement of the whole objective: scope is derived, not maintained.

The failure it prevents is specific. A scanner configured with a list of network ranges entered when it was installed will scan those ranges forever. New cloud accounts, new segments, new sites and acquired estates are simply absent, and nothing in the scanner's output indicates an absence — the report covers what was scanned and says nothing about what was not.

Deriving scope means:

• Cloud accounts enumerated from the organisation, so a new account is in scope the day it is created rather than the day someone remembers it.
• Hosts enumerated from the inventory of lesson five, with the reconciliation from that lesson feeding scope directly.
• External surface enumerated from DNS, certificate transparency and the provider's own public-address inventory, not from a list of what you believe you publish.
• Coverage reported as a first-class metric: assets in inventory, assets scanned, assets scanned successfully, and the difference between them with reasons.

That last point is the one that turns an unknown asset into a known gap. A programme reporting "4,120 of 4,400 assets scanned; 280 failed authentication; 112 in inventory not reachable by any method" is describing its own limits honestly. A programme reporting only findings is asserting completeness it has not measured, which is the shape lesson six warned about with GRC platforms and lesson twenty-seven with pagination.

Three coverage failures worth naming because they are common and quiet: credentials failing on a subset so those hosts scan unauthenticated and report almost nothing; agents installed but not checking in; and whole accounts or segments unreachable. Each looks like good news in a findings count.

Scheduling, load and the production system that must not be scanned at noon

The operational constraints, because a programme that causes outages gets restricted until it is useless.

Load. Authenticated scans consume real CPU, memory and disk on targets, and aggressive network scans can affect fragile devices — operational technology and embedded systems especially, where a port scan has genuinely caused failures. The mitigations: throttle, stagger, exclude fragile device classes from active scanning and cover them by passive means, and agree windows for high-load scans on sensitive systems.

Frequency, which should follow exposure and change rate rather than being uniform:

• Internet-facing systems: continuously or daily, because exposure is immediate.
• Production internal: weekly, with continuous agent data underneath.
• Endpoints: continuous via agent.
• Cloud configuration: continuous, event-driven, as lesson twenty-seven described.
• Images and dependencies: on every build, plus a periodic rescan of published images so a newly disclosed vulnerability in a stored image surfaces.

That last item matters and is often missed: an image scanned clean at build time and sitting in a registry for six months has accumulated vulnerabilities without changing a byte.

Out-of-cycle scanning is triggered by events rather than the calendar: a significant disclosure, a change to an internet-facing system, an acquisition, or an incident. A programme that can only answer "are we affected by this disclosure" at the next scheduled scan is too slow for the question.

Scanning cannot be the only detection. Between scans the estate changes, so continuous agent data and event-driven configuration assessment carry the gap. The scan is a periodic deep measurement; the continuous sources are the ones that notice something happened today.

Container and image scanning in the pipeline rather than in production

The last section, and it is where scanning stops being detective and becomes preventative — which, as lesson eighteen argued, is a better trade when it is available.

Scanning a running container tells you about a problem already deployed. Scanning in the pipeline tells you before it exists, and the fix is cheaper by an order of magnitude because it is a rebuild rather than a change to a running service.

What belongs in the pipeline:

• Dependency scanning of the application's declared dependencies, with results compared against a policy about severity and exploitability.
• Image scanning of the built image, covering the base layers as well as the application — the base image hygiene from lesson fifteen, enforced.
• Configuration checks on the image and its deployment manifests: running as root, privileged mode, secrets present in layers.
• Secret detection in source and in image layers, which catches the credential lesson twenty-six prohibits before it is published.
• A generated software bill of materials, stored with the artefact, which is what makes the next disclosure answerable by query rather than by rescan.

Two policy decisions decide whether this works in practice, and both are scenario material. What fails the build, which should start narrow — critical severity with a known exploit, or any exposed secret — and tighten as the estate cleans up, because a gate failing every build on day one is disabled on day one. And the exception path, time-limited and recorded in the register from lesson one, because a vulnerability with no available fix is a real situation and a gate with no exception mechanism gets bypassed rather than respected.

Production scanning still matters, for two reasons that the pipeline cannot cover: images deployed before the gate existed, and vulnerabilities disclosed after the build. Runtime scanning also sees what is actually running, which can differ from what was built — and that difference, when it appears, is a finding of a much more serious kind than a missing patch.