Vulnerability scanning strategy: coverage by design

A scanner is a sensor, and a vulnerability program is only as good as its sensors. Many organizations run one type of scan — often an unauthenticated network sweep — and assume it tells them where they stand. It does not. Different techniques see different things: a network scan sees what answers on the wire, an authenticated scan sees installed packages and configuration, an agent sees a laptop that has not touched the office network in months, and a registry scan sees a vulnerable library inside an image before it is ever deployed.

A scanning strategy is a deliberate portfolio of these techniques, mapped to asset classes, with cadences that match your remediation SLAs and a way to prove coverage. This guide walks through the options and how to combine them.

Discovery versus assessment

Separate two jobs that are often conflated:

• Discovery answers "what exists?": host discovery sweeps, cloud API enumeration, DNS and certificate transparency monitoring, external attack surface discovery. It feeds the asset inventory.
• Assessment answers "what is wrong with it?": vulnerability checks, configuration checks, software composition analysis.

Run discovery more broadly and more often than assessment. A discovery sweep is cheap and low-risk; its main output is the list of things that exist but are not being assessed.

Authenticated versus unauthenticated scanning

An unauthenticated network scan sees the system as an outsider would: open ports, service banners, and whatever checks can be run remotely. It is valuable for understanding exposure, but it is a weak assessment method. Banners are often generic or deliberately hidden, backported patches in enterprise Linux distributions do not change version strings, and client-side software (browsers, office suites, runtimes) is invisible from the network.

An authenticated scan logs in — over SSH, SMB/WinRM, or an API — and inspects installed packages, registry keys, file versions and configuration. It produces far more accurate results and far fewer false positives. As a rule, authenticated coverage is the scanning metric that matters most, and a finding from an authenticated check deserves more trust than one inferred from a banner.

Credential hygiene for scanning

Scanner credentials are high-value targets, since they typically grant read access to every system. Treat them accordingly:

• Use dedicated service accounts per scope, never shared admin accounts.
• Grant the least privilege the checks need; on Linux, prefer a restricted account with targeted sudo rules over full root where your scanner supports it.
• Store credentials in a vault or the scanner's encrypted store, rotate them, and restrict which scanner hosts may use them.
• Monitor logons by scanner accounts from anywhere other than the scanner hosts — that is a useful detection for the SOC.
• Track authentication failures as a coverage defect: a scan that silently fell back to unauthenticated checks is a gap, not a success.

Agents, network scanners and API-based assessment

Most mature programs use an agent where one can be installed, authenticated network scanning for what cannot run an agent, and API-based assessment for cloud, with registry and SCA scanning in the software supply chain.

Containers and code

Containers shift where remediation happens. A vulnerable package in a running container is almost always inherited from its image, so the fix is to update the base image or dependency, rebuild, and redeploy — not to patch the container in place. Scan in three places:

1. In CI, to stop new vulnerable images being published (with policy gates tuned carefully, or developers will bypass them).
2. In the registry, continuously, because images that were clean at build time acquire new CVEs as disclosures accumulate.
3. At runtime, to learn which images are actually deployed, where, and with what exposure — the context needed for prioritization.

Open-source tools such as Trivy, Grype and OSV-Scanner cover images, filesystems and lockfiles (examples, not endorsements). Generating a software bill of materials at build time lets you answer "are we affected?" for a newly disclosed CVE without rescanning everything.

An example cadence by asset class

The table below is an example, not a standard. Derive yours from your SLAs: if a P1 must be fixed in 7 days, a monthly scan cannot even detect it in time.

When a high-profile vulnerability is disclosed, you also need an on-demand capability: a targeted check across the estate within hours, often driven from software inventory or SBOM data rather than a full rescan.

Scanning safely

Active scanning can break things: legacy services that crash on malformed input, printers that print garbage, industrial controllers that fault, and fragile medical devices. Reduce the risk by:

• Excluding known-fragile ranges from default policies and handling them with passive techniques.
• Using safe-check options and avoiding denial-of-service style checks in production.
• Scheduling intensive scans in agreed windows and notifying the SOC so scan traffic is not mistaken for an attack.
• Throttling concurrency on thin network links and small appliances.
• Keeping an exclusion list with an owner and a review date — permanent, undocumented exclusions become blind spots.

Proving coverage

A scanning strategy is only complete when you can measure it. Report at least:

• Assessment coverage: in-scope assets with a successful assessment within policy, divided by in-scope assets in the inventory.
• Authenticated coverage: the same, counting only authenticated scans or agent results.
• Authentication failure rate: scans where credentials failed, by scope.
• Unknown assets: hosts found by discovery but not in the inventory.

Coverage should be broken down by asset class and business unit. A single aggregate figure hides the one data center or cloud account that nobody scans.

Handling false positives

False positives erode trust faster than anything else. Common causes are banner-based checks on backported packages, version checks that ignore vendor-specific fixes, and duplicated findings from overlapping tools. Handle them with a process, not ad hoc deletion:

1. The remediation team disputes the finding with evidence (package version, vendor advisory, configuration).
2. A VOC analyst validates and marks it as a false positive with a reason, scoped to that asset and check.
3. Recurring false positives are fixed at the source — switching to authenticated checks, tuning the plugin, or reporting it to the vendor.

Keep false positives separate from exceptions: an exception accepts a real risk, while a false positive records that the risk does not exist.

With coverage in place, the next challenge is deciding what to fix first — see risk-based prioritization with CVSS v4, EPSS and KEV.