Report coverage, image age, time to fix, exception debt and gate bypasses. These five show whether the programme is working and where it is stuck. A raw count of vulnerabilities does not, because it rises with every new advisory and says nothing about what you did. Pair each number with a trend and an owner.
Why not total findings
Total findings go up when scanners improve, when new advisories land, and when you scan more. A leader reading a rising line may conclude things are getting worse when the programme is getting better. Choose numbers that measure behaviour you control.
The five
| Metric | Definition | Direction |
|---|---|---|
| Coverage | Share of deployed image digests with a current scan and SBOM | Up |
| Image age | Median and 90th percentile build age of running images | Down |
| Time to fix | Median days from fix available to patched image running | Down |
| Exception debt | Open exceptions, and how many are past expiry | Down |
| Gate bypasses | Deploys that skipped a policy, by cause | Down |
How to compute each
Coverage. Divide the number of running digests that have a scan newer than your rescan interval by the total running digests. The denominator must come from the clusters, not from the registry, otherwise unscanned images that run are invisible. See which image tags in a registry should you scan.
Image age. Use build date and base age, as described in how old is too old for a container image. Report the tail, since a median can hide a handful of images that are two years old.
Time to fix. Start the clock at fix availability and stop it when the patched digest is running in production. See container vulnerability SLA by severity and fix availability.
Exception debt. Count every accepted risk with its expiry, and show the number past expiry separately. A growing pile of expired exceptions is a control failure, not a detail.
Gate bypasses. Count break-glass uses and any deploy that evaded the gate, with a reason. A few is healthy proof that the route works. A rising count says the policy is out of step with how teams work.
Presenting them
Use one page. For each metric show current value, three month trend, target, and the person responsible. Add one sentence on what you are doing about the worst one. Avoid red and green for its own sake, and avoid decimals that suggest false precision.
A good leadership review asks "what do you need". Prepare the answer: headcount for platform base images, a decision on a legacy service, or agreement on a freeze policy.
What to avoid
- Vanity counts such as images scanned, without a denominator.
- Severity-only breakdowns that ignore fix availability.
- Reporting findings closed when the pull request merged instead of when the fix was deployed.
- Comparing teams on raw counts without adjusting for workload size.
Link to customer and audit questions
These numbers also answer buyer questionnaires and audit requests. Coverage and time to fix map neatly onto common security questions about vulnerability management. See how to answer container image security questions.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at which views in the demo give you coverage and fix status rather than only counts.
Where Safeguard fits
Safeguard provides dependency and image scanning, SBOM data and policy records, the raw inputs for these five numbers. Start with a free scan.
Quick check
Should we report the total number of vulnerabilities?
Only as context. It rises for reasons unrelated to your performance, so pair it with the five behaviour metrics.
How often should leadership see these?
Monthly is enough for most organisations, with an immediate note when a widely exploited flaw affects deployed images.
Last reviewed: 19 October 2026.
