Prove it works with outcomes, not alert counts. Track coverage of repositories and images, share of findings with an owner, time from detection to fix, age of open exceptions, and how often a gate blocks something real. If those move the right way for two quarters, the platform is earning its place.
Why counts mislead
A dashboard that shows 4,000 findings tells you almost nothing. A rise might mean better coverage. A fall might mean scans broke. Measure things that cannot improve by accident.
Five measures that hold up
| Measure | How to compute | Healthy direction |
|---|---|---|
| Coverage | Connected repos and images divided by known repos and images | Up toward your target |
| Ownership | Open critical findings with a named owner divided by all open critical findings | Near 100 percent |
| Time to fix | Median days from detection to merged fix, by severity | Down |
| Exception age | Count of exceptions past expiry | Zero |
| Useful blocks | Gate blocks that the team agreed were right divided by all blocks | High and stable |
Coverage needs a denominator. You cannot divide by repositories you do not know about, so pair the platform with asset discovery or a list from your source host.
Add exploitation context
Not every finding deserves the same clock. CISA calls its Known Exploited Vulnerabilities catalog an authoritative source of vulnerabilities exploited in the wild and recommends using it as an input to prioritization. So split time to fix into two lines: findings known to be exploited, and everything else. The first line should be short and the second can be longer without alarm.
The EPSS project describes its score as a data-driven model that estimates the probability a published CVE will be exploited in the next 30 days. It is a useful second signal for the rest. Keep it as a sorting aid, not a metric on its own.
A monthly review ritual
- Print the five measures with last month beside them.
- Pick the one that got worse and ask why, in plain words.
- Sample five closed findings and check the fix really shipped.
- Sample five blocks and ask whether the team agreed.
- Write one action and an owner.
Fifteen minutes is enough.
Measures to be wary of
- Total vulnerabilities found. Rewards noise.
- Findings closed. Rewards closing easy, low severity items.
- Scans run. Measures activity, not safety.
- Mean time to remediate across all severities. Hides the critical tail in an average.
Show the result to others
Auditors and customers care less about your charts and more about repeatable evidence: dated records of what was scanned, what was found, and what you decided. Keep exports with dates so you can answer for a past quarter.
A worked example
Take a hypothetical company that reviews its five measures at the end of a quarter. These figures are invented to show how to read them, not real data.
Coverage rose from 62 to 88 percent of known repositories, because asset discovery found a group of repositories nobody had connected. Ownership of critical findings went from 70 to 96 percent after a code owners file became mandatory. Median time to fix for known exploited findings dropped from nine days to four. For all other critical findings it stayed near eighteen days, which the team judged acceptable. Four exceptions had passed expiry, and the monthly review closed them. About one gate block in ten was judged wrong by the team, and a rule was tuned.
The story reads clearly: coverage and ownership improved first, then speed on the urgent items, with one rule needing work. Compare that with the raw number of findings, which went up, because coverage went up. That number alone would have looked like failure.
How to pull the numbers
- Define the denominator for coverage. Use a list of repositories from your source host, updated weekly.
- Define a clock for time to fix. Start at first detection, stop at a merged fix confirmed by rescan.
- Split by urgency. Known exploited and internet facing items form one group, everything else another.
- Record the result monthly in a simple table. Do not rewrite history if a definition changes. Note the change.
Presenting to leadership
Leaders want to know whether risk is falling and whether effort is justified. Give them one slide with the five measures, last quarter beside this quarter, and one sentence on each trend. Add one sentence on what you will do next. Avoid a wall of charts.
| Measure | Last quarter | This quarter | Comment |
|---|---|---|---|
| Coverage | |||
| Ownership | |||
| Time to fix, urgent | |||
| Expired exceptions | |||
| Useful blocks |
Checks that catch self deception
- Sample five items marked fixed and confirm the fixed version is deployed.
- Check that scans ran on the last release of three random repositories.
- Ask two developers what they think of the checks. Their answers will not be on a dashboard.
- Verify that a known bad sample would have been blocked.
What to do when numbers get worse
A worse number is information. If coverage fell, a new set of repositories appeared. If time to fix rose, look for a blocked upgrade or a staffing gap. Resist the urge to redefine the measure. Fix the cause or explain it.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how a finding changes status over time, which is what time to fix measures.
Safeguard covers asset discovery, vulnerability scanning with reachability analysis, and compliance and evidence automation, which gives these measures a shared source. The free scan at gold.safeguard.sh/scan gives a first inventory.
Quick check
Which single measure matters most?
None alone works. Coverage and time to fix for known exploited findings are the two most telling together.
How long before the numbers mean anything?
Plan for at least two full quarters, so seasonal release patterns do not fool you.
Should we share these measures with customers?
Share only what you can back with records, and keep wording factual. Ask your legal and sales leads before publishing numbers outside the company.
Sources
Last reviewed: 19 October 2026.
