Scan coverage is the share of your assets that were scanned successfully within a set time. It only means something if the denominator comes from an inventory that is independent of the scanner. Otherwise you are measuring how much of what the scanner knows about it scanned.
The denominator problem
If your scanner supplies the list of repositories, images and services it will scan, coverage is circular. Anything it does not know about is simply absent, and you reach 100 percent while shadow assets sit outside.
Build the denominator from sources such as your source control organisation, container registry, cloud account inventory, and deployment manifests. Then compare to what the scanner has. The difference is your real gap.
Define scanned, precisely
"Scanned" should mean all of these:
- The scan completed without errors.
- It covered the relevant parts: manifests, lock files, source, image layers.
- It ran within the freshness window, for example the last 7 days.
- Results were ingested and attributed to an owner.
A scan that failed on parse errors in half the repository should not count as covered. Track a separate "scan failed" count.
Pick a freshness window by asset type
Internet facing services and production images deserve a short window. Archived repositories can be longer or excluded with a recorded reason. Write the windows into the metric card. See the definition card.
Break coverage down
An overall number hides gaps. Show coverage by:
- Asset type: repositories, images, running workloads, APIs.
- Environment: production versus the rest.
- Owner: which teams have blind spots.
- Scan type: dependency, source, container, dynamic.
A table of five rows is more useful than one gauge.
Exclusions need an expiry
Every exclusion should have an owner, a reason and a review date. Count them, and show the number on the same chart. A rising exclusion count while coverage stays at 100 percent is a warning.
Coverage is not detection quality
Full coverage with weak rules still misses things. Pair coverage with a sampled check: introduce a known test finding in a repo and confirm it is reported. Treat this like a smoke test for your pipeline.
Where to start
If you have no inventory yet, asset discovery should come first. Safeguard includes asset discovery and SBOM and dependency scanning, and you can try a free scan on a single project to see what a scan result looks like.
A worked example
Your source control organisation lists 220 active repositories. The scanner reports 180 as scanned in the last week, of which 12 failed to parse. Coverage by the strict definition is 168 of 220, or about 76 percent, not 100.
Now look at the 52 gaps. Perhaps 30 are archived repos you can exclude with a reason, 15 are new and not yet onboarded, and 7 are active services with no owner. The last group is the real work. A good coverage chart makes that split visible, so the conversation is about 7 services rather than about a percentage.
Quick check
Is 100 percent coverage realistic?
For tracked asset classes with defined exclusions, yes. Across an unknown estate, no, until discovery closes the gap.
How do I count monorepos?
Count the deployable units inside them, or record a rule once and apply it consistently.
Last reviewed: 19 October 2026.
