skip to content

A vulnerability scan report lists 2,000 hosts assessed; how do you find the hosts it never assessed at all?

level: middleimportance: should knowfreq 22%

answer

  1. the scanner cannot list its blind spots
  2. independent inventories to diff against
  3. out of range, silent, or half-assessed
  4. assessed hosts over known hosts

basics

~20 s

Diff the scan's assessed-host list against independent inventories: cloud and virtualisation APIs, DHCP leases, DNS, directory computer accounts, switch and flow data. Anything in those sources that is missing, silent or only partly assessed in the scan is a coverage gap.

solid answer

~40 s

A scan report only counts what the scanner reached; it cannot list hosts its target ranges omitted. So coverage is measured from outside the scanner: build an expected-asset list from several independent sources and compare it with the scan results. Classify every gap: **not in any target range** (an unknown subnet, a new cloud account), **in range but never answered** (filtered probes, host off, discovery missed it), or **answered but only partly assessed** (login failed, scan timed out). Report coverage as assessed hosts over known hosts, split by gap type, and treat an unknown host as a bigger risk than a known host with findings: no one patches what no one sees.

go deeper

for a junior

Recall that a scan report only covers its own target list and what answered; hosts outside it are invisible to the report, so coverage has to be checked against other inventories.

for a middle

Explain how you build the expected-asset list from several sources and classify each gap as never targeted, targeted but silent, or reached but not fully assessed.

for a senior

Show that you give each gap class an owner and a fix, and that you read finding counts alongside coverage so a falling count with falling coverage is never mistaken for progress.

for a principal

Argue for coverage, not finding count, as the headline programme metric, and for making inventory onboarding part of how hosts are created rather than a periodic clean-up.

## Why the scan cannot report its own blind spots A vulnerability scanner works from a **target list**: address ranges, host names or asset groups someone configured. It then runs **discovery** (deciding which targets are alive) and **assessment** (running checks against the live ones). Its report is accurate about what it found inside that list. It has no way to know about a subnet nobody added, a cloud account created last month, or a host that ignored every discovery probe. A report saying *2,000 hosts assessed* is therefore a numerator without a denominator. This is why mature programmes say the **unscanned host is the risk**. A known host with forty findings is on someone's list; an unknown host is invisible to patching, monitoring and incident response at once. ## Sources for the expected inventory No single source is complete, so the denominator is built from several, each covering the others' blind spots: | Source | What it finds well | What it misses | |---|---|---| | Cloud and virtualisation APIs | Every instance the platform created, including short-lived ones | Physical kit, other accounts or clusters not connected | | DHCP leases and DNS records | Dynamic clients, named servers | Statically addressed hosts with no DNS entry | | Directory computer accounts | Domain-joined machines | Appliances and non-joined hosts; stale accounts inflate the count | | Switch and router tables, flow logs | Anything that sent traffic | Hosts that were silent during the window | | Asset register | Business owner and criticality | Whatever was never registered | | Agents and passive sensors | Hosts that report or talk | Hosts without the agent, segments without a sensor | ## Diffing and classifying the gaps 1. **Normalise identities.** Hosts appear under different keys (address, name, cloud instance ID, hardware address). Merge them before comparing, or the diff is noise. 2. **Compare against target ranges.** Hosts in an inventory but outside every configured range are *never-targeted*: the scan could not have seen them. Fix the ranges or the onboarding process that should have added them. 3. **Compare against discovery results.** Hosts inside a range that discovery marked dead are *targeted-but-silent*. Common causes are a host or network firewall dropping discovery probes, the host being off, or discovery methods that only work locally (address-resolution pings, for instance, do not cross a router). 4. **Compare against assessment depth.** Hosts that answered but whose authenticated login failed, or whose scan timed out, are *reached-but-not-assessed*. They should not count as covered. 5. **Assign an owner per gap.** Each class has a different fix: inventory onboarding, network placement or discovery settings, or credentials. ## Discovery and its limits A discovery sweep is the scanner's own attempt at an inventory, and it fails in predictable ways: - hosts configured to ignore unsolicited probes look dead; - a firewall between scanner and segment can drop every probe, so an entire range looks empty; - treating every address as alive avoids those misses but costs far more time on sparse ranges; - discovery only ever covers the ranges it was given. So discovery helps, but it is not the denominator; independent inventories are. ## Coverage as a metric Report coverage as a ratio and keep its parts visible: - **known hosts**: the merged inventory; - **assessed hosts**: answered and fully assessed, authenticated where policy requires it; - the three gap classes, each with a count, an owner and a trend. A rising finding count alongside rising coverage is often good news: the programme is seeing more. A falling finding count alongside falling coverage is the dangerous combination, and only the coverage metric reveals it. ## Making coverage self-maintaining A one-off reconciliation finds today's gaps; new ones open every week. Programmes that keep coverage high build the diff into how hosts are created and changed: - **new networks and cloud accounts** are added to scan ranges as part of provisioning, not on request; - **the reconciliation runs on a schedule**, and new never-targeted hosts open a ticket for the team that created them; - **decommissioned hosts are removed** from the inventory, so stale entries do not inflate the denominator and hide real gaps; - **segments that are deliberately not actively scanned**, such as fragile device networks, are listed as a known category with their alternative coverage, so they are a decision rather than an accident.

  • Discovery finds nothing alive in one /24 that DHCP says holds 80 active leases. What do you suspect first?
    That discovery probes are being dropped between the scanner and that segment, by a network firewall or host firewalls, so every host looked dead. Confirm with a single host the owner can vouch for, then fix the path: place a scanner inside the segment, open the probes it needs, or treat that range's addresses as alive for assessment.
  • Should hosts the scan reached but could not log into count as covered?
    No. They were reached but not assessed to the programme's standard, so a separate class is needed: reached-but-unauthenticated. Counting them as covered hides exactly the hosts whose findings are least trustworthy, and it lets a credential problem pass as good coverage.

saying these in an interview costs you the question

  • The scanner's host count is the asset inventory.
  • A host that did not answer discovery probes does not exist.
  • A known host with many findings is riskier than a host that was never scanned.
  • Coverage means every address in the target ranges was probed.
  • One inventory source, such as the asset register, is enough to diff against.