Report five things each month: scan coverage, gate outcomes (blocked, passed, bypassed), open findings by age, active exceptions, and time to fix for serious findings. Show trend against the previous month and a one line note on what changed. Keep it to one page.
The five measures
| Measure | What it shows | Watch for |
|---|---|---|
| Coverage | Repos with a fresh, complete scan | Falling coverage after new repos appear |
| Gate outcomes | Blocked, passed, bypassed counts | Bypasses rising, or zero blocks for months |
| Findings by age | Open serious findings in bands, such as under 30, 30 to 90, over 90 days | Growth in the oldest band |
| Active exceptions | Count, by risk tier, with expiry dates | Exceptions renewed again and again |
| Time to fix | Median days from detection to merged fix, for serious findings | Medians hiding a long tail |
Use medians and the oldest item, not just averages. One neglected critical finding matters more than a good average.
What leadership asks
Executives usually want to know if risk is going down, where the biggest gaps are, and what help you need. Answer in that order: a trend line, the top three gaps by team or service, and a request. Skip tool names and raw alert counts that lack context.
What to leave out
- Total alert counts without severity or age. They reward noise.
- Vanity numbers such as scans run.
- Per developer rankings. They damage trust and invite gaming.
Be careful with aggregates too. A single combined rate can hide the opposite trend in each team, a known statistical trap described in Simpson's paradox in security metrics.
How to produce it with little effort
- Pull data automatically from the scanner and the source host, as in the coverage post.
- Store monthly snapshots so trends are real, not recomputed from changing data.
- Add two sentences of commentary written by a person.
- Send the page to engineering leads, not just security.
Link measures to actions
Every number should map to a decision. If coverage drops, onboard the missing repos. If bypasses rise, review the bypass list and the top causes. If time to fix grows, look at whether fixes are blocked by breaking upgrades and consider automated fix PRs. The report is a prompt for decisions, not a scoreboard.
Try it yourself
Click through the vulnerability management demo to see the kinds of findings, ages and statuses a monthly report summarises.
Click through it at your own pace, or open it full screen.
Quick check
Should we report to developers too?
Yes. A shared page that teams can see for their own repos builds ownership better than a report only managers read.
How many measures are too many?
More than about seven on the summary page. Put detail in a linked view.
Safeguard provides vulnerability management views, compliance and evidence automation that can support this kind of reporting.
Last reviewed: 19 October 2026.
