A vulnerability report tells you what a scanner found. It rarely tells you what a scanner looked at. Those are different questions, and the gap between them is where coverage problems hide. An asset that was scanned last quarter but skipped this quarter does not produce a finding. It produces silence. Silence reads like good news on a dashboard that only counts open issues, yet it is the most dangerous state in vulnerability management because nobody is looking at it.
This article is about how to read coverage instead of guessing at it. We will define what scan coverage actually means, explain the wave matrix as a way to see a single asset across every scan that ever touched it, and walk through the four states a finding can occupy in that view. The goal is a working mental model. By the end you should be able to look at one asset’s history and answer three questions with confidence: was this asset assessed, which scanners produced findings for it, and did anything that was fixed quietly come back.
This is a conceptual piece. It explains how to interpret coverage and why the wave matrix is structured the way it is. If you want the operational walkthrough of which panel to open and which control to click during day-to-day triage, that lives in our companion guide on the scan coverage matrix in practice. Here we stay with the ideas.
What “Scan Coverage” Really Means
The phrase gets used loosely. People say “we have good coverage” to mean the scanner license covers enough IPs, or that a scan ran on schedule, or that the report had a lot of pages. None of those are coverage in the sense that matters for assurance.
Coverage is a property of an asset, not a property of a scan. The question is not “did the scan run” but “was this specific asset assessed, by which tools, and when.” In PMAP every finding, scan, and risk score ultimately resolves to an asset. The asset is the inventory backbone. That design choice is what makes coverage measurable at all, because once every observation is anchored to an asset, you can ask the inverse question: for this asset, what has been observed, and what has been left unobserved.
That inversion is the heart of coverage visibility. A scan-centric view answers “what did scan number 47 find.” A coverage-centric view answers “for server X, here is everything every scan has ever said about it, including the scans that said nothing.” The second view is the one that surfaces blind spots, because a blind spot is by definition the absence of an observation. You cannot find an absence by listing what is present. You have to lay out what should be present and look for the holes.
Scan coverage assurance, then, is the practice of proving that the assets you care about are actually being assessed on the cadence you expect, with the tools you expect, and that nothing important has fallen out of the rotation. Most vulnerability programs assume this is happening. Few can demonstrate it on demand. The difference between assuming and demonstrating is usually the difference between passing and failing an audit conversation about attack surface and asset inventory, where the auditor asks not “what did you find” but “how do you know you looked.”
External frameworks treat this as a first-class concern. The CIS Critical Security Controls place continuous vulnerability management in Control 7, which is explicitly about establishing and maintaining a recurring assessment process rather than a one-off scan. NIST SP 800-40 Rev. 4 frames patch and vulnerability response as an ongoing program with defined cadence. And NIST SP 800-53 control CM-8 ties the whole thing back to a complete, current inventory, because you cannot claim coverage of assets you have not enumerated. The common thread is recurrence. Coverage is not a snapshot. It is a pattern over time, and to see a pattern you need a view built around time.
The Wave Matrix Explained
The wave matrix is PMAP’s answer to the question “show me one asset across time.” It is a per-asset cross-tabulation of findings against scans. Think of it as a grid. Down one edge you have the distinct findings that have ever been recorded for this asset. Across the other edge you have the scan waves, the successive assessments that touched it. Each cell where a finding meets a scan tells you the state of that finding in that wave.
The value of a cross-tab is that it makes a pattern visible at a glance. A flat list of findings tells you the current state. A flat list of scans tells you what ran. Neither lets you trace a single issue across multiple assessments. The matrix does, because it holds both dimensions at once and fills every intersection with a status. You read a row to follow one vulnerability through its lifecycle. You read a column to see what a single wave reported. You read the whole grid to judge the asset’s coverage story end to end.
Internally PMAP models this with a small set of types. A WaveMatrix is the whole grid for one asset. It is composed of MatrixWave columns, one per scan wave, and MatrixRow entries, one per distinct finding. Where a row crosses a wave you get a MatrixCell, and the cell carries the status. This structure is exposed through a dedicated per-asset endpoint, so the matrix is always scoped to the single asset you are inspecting rather than being a global report you have to filter down.
Rows, Columns and Cells: How the Cross-Tab Is Built
Let us be concrete about each axis, because the meaning of the view depends entirely on what the rows and columns represent.
The rows are distinct findings. A finding here is a real, deduplicated issue tied to this asset, not a raw scanner line item. That distinction matters. If three scanners report the same weak TLS configuration on the same host, you do not want three rows. You want one row that you can follow across waves, with the matrix showing you which waves saw it. Correlation upstream of the matrix is what makes a row meaningful as a unit of “the same problem over time.”
The columns are scan waves. A wave is an assessment that touched this asset. In practice a wave maps to a scan execution, and scans can be grouped into larger campaigns. PMAP supports grouping scans under an assessment run, which lets a multi-scan pentest or a quarterly assessment cycle read as a coherent unit rather than a scatter of unrelated executions. When you look across the columns left to right, you are looking at the asset’s assessment timeline.
The cells are the intersection. Each cell answers one narrow question: in this wave, what was the state of this finding for this asset. There are exactly four possible answers, and learning to read them is the whole skill.
The Four Cell States and What They Tell You
Every cell in the wave matrix holds one of four statuses: open, closed, reopened, or absent. These four states are the vocabulary of coverage reading. Each one carries a precise meaning, and the interesting information often lives in the transitions between them as you move along a row.
An open cell means the finding was present and active in that wave. The scanner saw it, the issue was real, and it had not been resolved as of that assessment. A run of open cells along a row is an unremediated vulnerability persisting across multiple assessments, which is itself a useful signal. Persistence is a remediation-velocity problem, not a coverage problem, but the matrix surfaces it for free.
A closed cell means the finding was resolved in or by that wave. The issue that was once present is no longer reported as active. Reading left to right, an open cell followed by a closed cell is the happy path: the vulnerability was found, then fixed, and a later assessment confirmed the fix. This is exactly the kind of closed-loop evidence an auditor wants, because it shows not just that you remediated but that a subsequent scan verified the remediation.
An absent cell means this finding has no record in that wave at all. The wave neither reported the issue as open nor recorded it as closed. Absence is the subtle state and we give it its own section below, because depending on context it can be perfectly benign or it can be the exact blind spot you are hunting for.
A reopened cell is the alarm. It means a finding that had been resolved is active again in a later wave. We give this its own subsection too, because a reopened cell is the single most actionable signal the matrix produces.
Reopened Findings Are a Regression Signal
A reopened state is a regression. The pattern in the row is open, then closed, then reopened: the issue was found, marked resolved, and then a later scan saw it active once more. This is not the same as a finding that simply never went away. A persistent open run means remediation never happened. A reopened cell means remediation happened, was confirmed, and then was undone.
That distinction changes the response. A persistent open finding tells you to chase the remediation owner. A reopened finding tells you something in your environment is actively regressing. The likely causes are different and worth naming. A configuration drifted back to an insecure default. A patched system was rebuilt from a stale image. An infrastructure-as-code change reverted a hardening control. A host was restored from a backup taken before the fix. In every case the root cause is a process gap, not a one-time mistake, and process gaps repeat unless you catch them.
This is why reopened is the state worth alerting on. A new finding is expected; environments change and scanners improve. A reopened finding means your remediation is not sticking, and a remediation that does not stick is arguably worse than no remediation, because it consumes effort and produces a false sense of closure. Watching for reopened cells across the matrix turns the wave history into an early-warning system for regression, which is a capability a single point-in-time report can never offer.
Reading Coverage Across Scan Waves
Once you understand the four states, reading a full row becomes a narrative. You are following one issue through the asset’s assessment timeline, and the sequence of states tells its story.
Consider a row that reads open, open, closed, closed. The vulnerability was present in the first two waves, resolved by the third, and stayed resolved in the fourth. That is a clean remediation with verification. Now consider open, closed, absent, open. The issue was found, fixed, then a wave had no record of it, and then it showed as open again. The absent cell in the middle is the part to interrogate, because it changes how you read the final open. Was the asset simply not assessed in that wave, so the matrix had nothing to record? Or did the wave run and the finding genuinely was not present, only to return later? The matrix shows you the shape; the surrounding context tells you which reading applies.
Reading across waves is also how you judge cadence. If the columns are evenly spaced in time, your assessment rhythm is healthy. If there is a long gap between two waves, that gap is a coverage thinness even if no individual cell looks alarming, because a vulnerability introduced and removed inside that gap would never appear in the matrix at all. The wave matrix is honest about what it observed, and part of reading it well is staying aware of what could have happened between observations.
This is the conceptual layer. The operational mechanics of comparing waves, the specific widgets and controls, and the triage moves you make in response belong to the operational companion piece. Here the point is the interpretive skill: a row is a story, a column is a snapshot, and the spacing of columns is a cadence.
Which Scanners Produced Findings for an Asset
Coverage has a second dimension beyond time, and that is tooling. Two assessments on the same cadence are not equivalent if one used a network scanner and the other used a web application scanner. They look at different things. A clean network scan says nothing about application-layer vulnerabilities, and a clean DAST run says nothing about a missing OS patch. So part of trusting coverage is knowing which kinds of tools have actually been pointed at an asset.
PMAP exposes this directly. Alongside the wave matrix, each asset has a scan coverage view that aggregates which integrations have produced findings for that asset. Where the wave matrix is finding-by-wave, this view is a roll-up by scanner source. It answers the question “what tools have ever reported on this host.” PMAP orchestrates a broad set of vendors, including Nessus and Tenable, Qualys, Rapid7, and dedicated DAST and SAST scanners, so the coverage view can show genuine tooling diversity rather than confirming that the same single scanner ran ten times.
Reading this view is a gap-detection exercise. If a business-critical web application shows findings only from a network scanner and nothing from an application scanner, that is a coverage gap even though the asset has plenty of findings. The asset is being scanned. It is not being scanned for the right class of weakness. This is the kind of blind spot that a finding count completely hides, because the count is high and the dashboard looks busy, yet an entire category of risk has never been examined. Coverage assurance means checking the diversity of sources, not just their volume.
The two views work together. The scan coverage roll-up tells you whether the right kinds of tools have looked at the asset. The wave matrix tells you what those tools found over time and whether it was fixed. Reading both gives you the full picture: the right tools, on the right cadence, with a verified remediation history.
Spotting Blind Spots: When an Asset Goes Absent
The absent cell is where coverage reading earns its keep. An absent state means a finding has no record in a given wave, but the reason for that absence is not encoded in the cell itself. There are two very different reasons a cell can be absent, and they demand opposite responses.
The benign reason is that the finding genuinely was not relevant to that wave. Perhaps the issue was already closed before the wave ran, so there was nothing to report. Perhaps the wave targeted a different scope and never assessed the condition that produces this finding. In these cases absence is just the natural shape of a finding that does not apply, and there is nothing to chase.
The dangerous reason is missed coverage. The asset was supposed to be in this wave and was not assessed. Maybe it was unreachable when the scan ran. Maybe it dropped out of the target list. Maybe a credential expired and the authenticated checks silently degraded to nothing. In this case the absence is a blind spot. The matrix is telling you, in the only way it can, that for this wave this asset was effectively invisible.
The way you distinguish the two is by looking at the column, not just the cell. If a single finding is absent in a wave but the asset’s other findings are present in that same wave, the asset was clearly assessed and the absence is benign. But if an asset is absent across a whole column, if every finding goes quiet in the same wave, that is the signature of missed coverage. The asset was not assessed in that wave at all. That whole-column absence is the blind spot worth investigating, and it is exactly the kind of thing that never shows up in a report that only lists what was found. Absence is data. The wave matrix is one of the few views that treats it that way.
Wave Matrix vs the Findings Delta Widget
PMAP offers a second view that is easy to confuse with the wave matrix, and clarifying the difference sharpens what each is for. On a scan’s detail page there is a findings delta widget. It answers “what changed in this scan” by breaking results into new versus regression versus total, sliced by severity. It is a per-scan view, and it is excellent for understanding the impact of a single assessment the moment it completes.
The two views are complementary, not redundant. The findings delta widget is scan-centric and point-in-time. It sits on one scan and tells you how that scan moved the needle: how many issues are brand new, how many are regressions of previously closed issues, how the severity mix shifted. It is the right tool when a scan just finished and you want to know whether to be worried.
The wave matrix is asset-centric and longitudinal. It sits on one asset and tells you the full history of every finding across every wave. It is the right tool when you are auditing an asset’s coverage, hunting for blind spots, or building remediation evidence over time. You would use the delta widget to triage the results of today’s scan. You would use the wave matrix to prove that an asset has been consistently assessed over the past year and that its fixes have held.
There is one shared concept worth noting, which is regression. The delta widget surfaces regression at the scan level, counting how many findings came back in this particular run. The wave matrix surfaces regression at the finding level through the reopened state, letting you see exactly which issue regressed and when. They are two windows onto the same underlying truth, sized for two different jobs. Knowing which window to open for which question is part of reading coverage well.
Multi-Tenant Scope on Coverage Reads
Coverage data is sensitive, and a coverage view that leaks across tenant boundaries would be worse than no view at all. PMAP enforces scope on every coverage read so that what you can see is exactly what you are entitled to see, and probing for what you are not entitled to see returns nothing useful.
The single-asset coverage endpoints are scoped through an in-scope check tied to the caller’s auth context. If an asset is not in your scope, the read fails closed. A detail worth highlighting is that an out-of-scope read does not announce itself with an authorization error that confirms the asset exists. It returns a not-found response instead. This 404-not-403 behavior is deliberate. An error that said “you are not authorized to view this asset” would still confirm that the asset is real, which lets a probing user enumerate the existence of assets they cannot see. Returning not-found refuses to confirm or deny, so coverage data for one tenant cannot be inferred by another.
The same discipline runs through the list and facet queries that feed the broader inventory, where a scope filter from the auth context is applied directly in SQL rather than after the fact. The result is that coverage visibility is genuinely per-tenant. You get a trustworthy and complete view of your own assets, and the system gives you no oblique channel into anyone else’s. For a multi-tenant platform serving consultancies and enterprises with subsidiaries, that closed-by-default scoping is not a nicety. It is the precondition for letting coverage data be shared at all.
How PMAP Turns Coverage Into Confidence
Step back from the mechanics and the value proposition is simple. Coverage you cannot see is coverage you cannot trust, and coverage you cannot trust is a liability dressed up as assurance. The wave matrix exists to convert an assumption into evidence.
Everything in this article rests on one architectural fact: in PMAP every finding resolves to an asset. That single anchoring decision is what makes coverage a measurable property rather than a vague feeling. Because every observation is tied to an asset, you can invert the question and ask what every asset has been told about itself over time. The wave matrix is that inversion made visible, a per-asset, per-wave grid where the four cell states let you read remediation success, persistence, regression, and the absence that signals a blind spot.
The payoff shows up most clearly in the moments that matter. When an audit asks how you know an asset was assessed, you do not gesture at a scan schedule and hope. You open the asset’s wave history and show a consistent run of columns, a verified fix that closed and stayed closed, and a coverage roll-up that proves the right classes of scanner have looked at it. When something regresses, you see the reopened cell before it becomes an incident. When an asset goes quiet, you read the whole-column absence as the warning it is, not as good news. Coverage gaps surface in the wave matrix before they surface in a breach report. That is the entire point.
Want to see how coverage gaps surface before an audit does? Read the asset inventory and risk management datasheet to see the full picture of how PMAP anchors findings, scans, and risk to a single source of truth.
Frequently Asked Questions
What is a wave matrix in vulnerability management?
A wave matrix is a per-asset cross-tabulation that maps every finding for that asset against every scan wave that touched it. Down one axis are the distinct findings, across the other are the successive scan waves, and each cell shows the status of that finding in that wave. It lets you follow a single vulnerability through its entire lifecycle across multiple assessments rather than seeing only its current state. In PMAP it is built from WaveMatrix, MatrixWave, MatrixRow, and MatrixCell types and exposed through a dedicated per-asset view.
What do the four wave matrix cell states mean?
Each cell holds one of four statuses. Open means the finding was present and active in that wave. Closed means it was resolved in or by that wave. Reopened means a previously resolved finding became active again, which is a regression signal. Absent means the finding has no record in that wave at all, which can be benign or can indicate that the asset was not assessed in that wave. Reading the sequence of states along a row tells the story of one issue over time.
How is scan coverage different from a finding count?
A finding count tells you how many issues were reported. Scan coverage tells you whether an asset was actually assessed, by which tools, and on what cadence. An asset can have a high finding count and still have a serious coverage gap, for example if it has only ever been scanned by a network tool and never by an application scanner. Coverage is about what was looked at; the finding count is only about what was found. Trusting one without the other hides blind spots.
What does it mean when an asset goes absent across a whole wave?
When a single finding is absent in a wave but the asset’s other findings are present, the asset was clearly assessed and the absence is benign. But when an asset is absent across an entire column, meaning every finding goes quiet in the same wave, that is the signature of missed coverage. The asset was effectively not assessed in that wave, perhaps because it was unreachable, dropped from the target list, or lost its scan credentials. Whole-column absence is the blind spot worth investigating.
How is a reopened finding different from one that never closed?
A finding that never closed shows a continuous run of open cells across waves, which means remediation simply never happened. A reopened finding shows open, then closed, then open again, which means the issue was fixed and verified and then came back. The reopened case usually points to a process problem such as configuration drift, a rebuild from a stale image, or a reverted hardening control. It deserves a different response because the failure is in keeping the fix in place, not in applying it.
How does the wave matrix relate to the findings delta widget?
They are complementary. The findings delta widget is scan-centric and point-in-time, breaking a single scan’s results into new versus regression versus total by severity, which is ideal for triaging a scan the moment it finishes. The wave matrix is asset-centric and longitudinal, showing one asset’s full finding history across every wave, which is ideal for auditing coverage and building remediation evidence over time. Use the delta widget to react to today’s scan and the wave matrix to prove an asset’s coverage story across a year.
Can other tenants see my asset coverage data?
No. PMAP enforces scope on every coverage read against the caller’s auth context, and reads that fall outside your scope fail closed. An out-of-scope read returns a not-found response rather than an authorization error, so the existence of an asset cannot be inferred by probing. List and facet queries apply the scope filter directly in SQL. The result is genuinely per-tenant coverage visibility with no oblique channel into another tenant’s data.
