A vulnerability scan tells you what a scanner found. It does not, on its own, tell you what the scanner reached. Those are two different questions, and the gap between them is where most blind spots live. A clean scan report can mean your environment is healthy. It can also mean the scanner never touched half of your assets and reported nothing because it saw nothing.
Scan coverage is the discipline of answering the second question. It measures how much of your real attack surface your scanners actually examined, which assets they touched, which scanners produced findings for each asset, and how that picture changes every time you run another scan. This article defines scan coverage as a concept, explains what a scan wave is, and walks through the wave matrix, a per-asset view that tracks how each finding behaves across successive scans.
This is a definitional guide. If you want the operational walkthrough of building and interpreting a coverage view, that lives in the deeper concept piece on reading the wave matrix. Here the goal is simpler. By the end you should be able to say what scan coverage is, read the four states a finding can hold across scan waves, and explain why a coverage gap is a risk even when no vulnerability has been reported.
What Is Scan Coverage?
Scan coverage is the proportion of your asset inventory that your scanners have actually examined, expressed against the assets you know you own. It is a measure of reach, not of results. Two organizations can run the same number of scans and produce the same number of findings while having completely different coverage, because coverage depends on how many of your real assets ended up inside a scanner’s target scope.
The simplest way to frame it is as a ratio. On one side sits your known inventory, the full set of servers, workstations, network devices, cloud instances, applications, databases, and other manageable entities you track. On the other side sits the subset of those assets that at least one scanner has reached and reported on. Coverage is high when those two sets are close. Coverage is low, and risk is hidden, when a large slice of your inventory has never appeared in any scan.
Coverage is meaningful only against a trustworthy inventory. If your asset inventory is incomplete, your coverage number will look better than reality, because you cannot measure reach against assets you have not recorded. That is why coverage and inventory are tightly coupled, and why a strong asset inventory is the foundation that makes coverage measurable at all. For the inventory side of that relationship, see the pillar on attack surface and asset inventory.
In a vulnerability management platform, coverage is tracked at the level of the individual asset rather than as a single global percentage. For any given asset, the platform can show which integrations or scanners have produced findings for it. That per-asset view is what turns coverage from an abstract metric into something you can act on, because it points at the exact assets a scanner has never touched.
Why Coverage Gaps Are a Hidden Risk
A coverage gap is an asset, or a class of assets, that your scanning program has not examined. The danger of a gap is that it produces silence, and silence reads like safety. A dashboard showing zero open critical findings for an asset feels reassuring. If that asset was never scanned, the zero is meaningless. It is the absence of data, not the presence of health.
This is what makes coverage gaps different from ordinary findings. An open vulnerability is a known problem you can prioritize and fix. A coverage gap is an unknown. You cannot triage a vulnerability you have never detected, and you cannot detect a vulnerability on an asset no scanner ever reached. The risk is real whether or not anyone is looking, so the unexamined asset carries the same exposure as a scanned one while contributing nothing to your visibility.
Gaps appear for ordinary operational reasons. An asset gets added to the environment after the last scan target list was defined. A credential expires and the scanner can no longer authenticate to a host, so it returns a thin or empty result. A network segment is unreachable from the scanner appliance. A new cloud subscription spins up outside the configured scan scope. None of these involve a misconfigured vulnerability. All of them produce the same outcome, which is an asset that sits in your inventory but never in a scan.
Coverage measurement exists to surface exactly this category of problem. It does not look for vulnerabilities. It looks for the assets your vulnerability detection has skipped, so the unexamined parts of your estate become visible alongside the examined ones. A mature program treats a low-coverage asset as an action item in its own right, because the fix is not patching a flaw, it is getting the scanner to reach the asset in the first place.
What Is a Scan Wave?
A scan wave is a single round of scanning at a particular point in time. Every time you run a scan, whether you launch it manually, a schedule triggers it, or the platform adopts a completed scan from a remote scanner, that execution produces a wave of results. The next scan produces the next wave. A wave is the unit you compare against, the snapshot that lets you ask what changed since last time.
Waves matter because vulnerability state is not static. New findings appear as software ages and new checks are published. Old findings disappear as teams remediate them. Some findings come back after a patch is rolled back or a host is rebuilt from an old image. None of this is visible from a single scan. It only becomes visible when you line up one wave next to another and watch how each finding moves between them.
In a scan, the underlying execution context carries the metadata that makes a wave meaningful. Each scan record holds its own status, progress, per-severity counts, and timing, and the platform tracks the lifecycle of that execution from queued through running to completed. When a scan completes, its results become a wave you can compare against earlier and later runs. That ordered series of waves is the timeline the wave matrix is built on.
The point of thinking in waves is that coverage and findings are both moving targets. A single wave answers what one scan saw. A series of waves answers whether your coverage is improving, whether remediation is holding, and whether problems you thought were fixed are quietly coming back.
Reading the Wave Matrix
The wave matrix is a per-asset cross-tabulation of findings against scan waves. Picture a grid. Down the rows sit the findings associated with one asset. Across the columns sit the scan waves in time order. Each cell answers a single question, which is what state this finding was in during that scan. The matrix turns a pile of scan results into a readable history of how each issue on an asset behaved over time.
What makes the matrix powerful is that it is scoped to one asset and reads left to right as a timeline. Instead of asking how many open criticals exist right now, you ask how a specific finding has moved across your last several scans. Did it appear, get fixed, and stay fixed? Did it vanish and then return? Did it simply stop showing up without ever being marked resolved? Each of those stories is a different pattern of cells in a single row.
Each cell in the matrix carries one of four states. Those four states are the vocabulary of the entire view, and learning to read them is the whole skill of reading the matrix.
- Open. The finding was present and active in this scan wave. The scanner saw it and it is unresolved.
- Closed. The finding was resolved by this wave. It was present earlier and the scanner now confirms it is gone, which is the pattern you want to see after remediation.
- Reopened. The finding had been closed and has come back in this wave. Something that was fixed is detectable again, which is a regression signal worth investigating.
- Absent. The finding was not part of this scan wave at all. The scanner did not report on it, which can mean the scan did not cover the asset that time rather than that the finding was resolved.
Four states across many waves give you a behavioral fingerprint for every finding on an asset. A row that goes open, open, closed, closed is a clean remediation. A row that goes open, closed, reopened is a regression. A row peppered with absent cells is a coverage story, not a remediation story, because the scanner kept missing that finding or that asset.
What “Reopened” and “Absent” Tell You
The open and closed states are intuitive. A finding is either an active problem or a confirmed fix. The other two states, reopened and absent, are the ones that carry the subtler signals, and they often matter more than the obvious ones.
Reopened is a regression flag. It means a finding that had been closed is detectable again. The fix did not hold, or the environment changed in a way that reintroduced the issue. A host might have been rebuilt from an outdated image, a patch might have been rolled back during an incident, or a configuration might have drifted. Whatever the cause, a reopened cell is telling you that closure is not the same as permanence, and that your remediation needs verification rather than a single confirming scan.
Absent is the coverage signal hiding in the matrix. An absent cell does not mean the finding was fixed. It means the scan that produced that wave did not report on the finding at all, often because it did not reach the asset. A row full of absent cells next to a couple of open ones is not a remediation history, it is evidence that your scanning has been intermittent for that asset. Reading absent as if it were closed is one of the most common ways teams convince themselves an environment is cleaner than it is. Absent is precisely where coverage gaps show up at the level of an individual finding.
Scan Coverage Per Asset
Coverage becomes concrete when you attach it to a single asset. For any asset in the inventory, a per-asset coverage view answers which integrations or scanners have actually produced findings for it. That is a direct, factual statement about reach. It is not an estimate. It is the list of scanners that have demonstrably touched this asset and returned results.
This per-asset framing changes how you reason about gaps. A global coverage percentage can tell you that, say, most of your estate has been scanned, but it cannot tell you which assets fall in the unscanned remainder. The per-asset view does exactly that. You can look at a high-criticality database and see that only one scanner has ever reported on it, or that none have, and treat that as a gap to close regardless of what the aggregate number says.
It also exposes single-scanner dependence. An asset that only one scanner has ever covered is more fragile than one that several have examined, because if that one scanner loses credentials or drops the asset from its target list, coverage for that asset silently goes to zero. Seeing coverage as a per-asset, per-scanner fact lets you notice that fragility before it turns into a blind spot, and it lets you decide whether a critical asset deserves more than one scanner’s eyes.
Because every finding in the platform ultimately resolves to an asset, per-asset coverage and the wave matrix describe the same reality from two angles. Coverage tells you which scanners have reached an asset. The wave matrix tells you how the findings on that asset have behaved across the waves those scanners produced. Together they answer both halves of the question this article opened with, namely what was reached and what was found.
Coverage vs Findings Delta
It is easy to confuse coverage with a related but separate idea, the findings delta. They answer different questions, and keeping them distinct sharpens both. Coverage is about reach, meaning which assets and scanners were involved. The findings delta is about change, meaning how the set of findings shifted from one scan to the next.
A findings delta breaks a scan’s results into what is new versus what is a regression versus the total, and it can slice that by severity. It powers the “what changed” view on a scan, answering whether this run surfaced fresh problems, brought back old ones, or held steady. It is a per-scan comparison focused on the movement of findings, which is the natural counterpart to the wave matrix’s per-asset, multi-wave view.
The distinction matters because the two can move independently. Coverage can improve while the findings delta stays flat, if a new scan reaches more assets but those assets happen to be clean. The findings delta can spike while coverage is unchanged, if the same assets are scanned again and a wave of new checks lights up problems that were always there. Reading one as a proxy for the other leads to wrong conclusions. The delta is a deeper topic in its own right, and its mechanics belong to the scanning concept material rather than to this definition. Here it serves only as a contrast that clarifies what coverage is by showing what it is not.
How Coverage Improves Over Scan Waves
Coverage is not a one-time measurement. It is something you grow, wave by wave. The reason waves are the unit of comparison is that each new scan is a chance to close a gap the last one left open. An asset that was absent from three waves and then appears in the fourth is a gap that just got filled, and the matrix records that improvement directly.
Closing gaps over waves is mostly operational work rather than vulnerability work. A scanner that could not authenticate gets fresh credentials and starts returning real findings for a host that used to come back empty. A target list gets widened to include a network segment that was previously out of scope. A newly onboarded integration begins covering a class of assets no existing scanner reached. Each of these shows up as previously absent cells turning into open or closed ones, which is the visible signature of coverage expanding.
This is also why orphan adoption and scheduled scanning matter for coverage. When a platform automatically picks up completed scans from a remote scanner and turns them into PMAP records, the scan history stays a faithful mirror of what actually ran, without depending on someone remembering to import each run. Scheduled scans keep the waves coming on a regular cadence, so coverage is refreshed continuously rather than drifting until the next manual effort. The combination keeps the wave timeline dense enough that the matrix tells an honest story.
The goal is a coverage picture that trends toward completeness and stays there. Early waves often show ragged coverage, with many absent cells and assets that only one scanner has ever touched. As gaps are closed wave by wave, the matrix fills in, the coverage view per asset shows more scanners reaching more assets, and the absent state becomes the exception rather than a recurring pattern. At that point your findings actually mean something, because you can trust that a quiet asset is quiet because it was examined, not because it was missed.
Frequently Asked Questions
What is scan coverage in simple terms?
Scan coverage is how much of your known asset inventory your scanners have actually examined. It measures reach rather than results. High coverage means most of the assets you own have appeared in a scan and been reported on. Low coverage means a meaningful slice of your inventory has never been scanned, so any apparent absence of vulnerabilities on those assets is unverified.
What is the difference between scan coverage and a vulnerability scan?
A vulnerability scan is a single execution that looks for security issues and reports findings. Scan coverage is the broader measure of how much of your environment your scans collectively reach. One scan answers what was found in one place at one time. Coverage answers whether your scanning program is touching the whole inventory, including the assets that no individual scan happened to include.
What does the wave matrix show?
The wave matrix is a per-asset grid that places findings on the rows and scan waves on the columns. Each cell shows the state of one finding during one scan wave, using four states, namely open, closed, reopened, and absent. Read left to right, a row becomes a timeline of how that finding behaved across successive scans, which makes remediation, regressions, and coverage gaps visible at a glance.
What does “absent” mean in the wave matrix?
Absent means the finding was not part of that scan wave at all, usually because the scan did not reach the asset that time. It is not the same as closed. A closed cell confirms a fix, while an absent cell confirms only that the scanner did not report on the finding. Rows with many absent cells are a coverage signal, indicating intermittent scanning rather than successful remediation.
How is reopened different from open?
An open cell means the finding was present and active in that wave. A reopened cell means the finding had previously been closed and has come back. Open is an unresolved problem. Reopened is a regression, a problem that was fixed and is now detectable again, which usually points at a rolled-back patch, a rebuilt host, or configuration drift that deserves investigation.
Why do coverage gaps matter if no vulnerabilities were reported?
Because no vulnerabilities reported can mean no vulnerabilities exist, or it can mean nothing looked. An unscanned asset produces silence, and silence reads like safety even when the asset is exposed. A coverage gap hides risk by removing the asset from your visibility entirely, so a mature program treats a low-coverage asset as an action item, closing the gap by getting a scanner to reach it.
How do you improve scan coverage over time?
Coverage improves wave by wave as you close the gaps each scan leaves open. The work is mostly operational, such as restoring scanner credentials, widening target lists to include missing segments, and onboarding integrations that reach asset classes no existing scanner covered. Scheduled scans and automatic adoption of completed remote scans keep the wave timeline dense, so coverage refreshes continuously and the matrix tells an honest story.
