Track five numbers monthly: scanner coverage of in-scope repositories, open findings by severity and age, median time to fix, count and age of exceptions, and how far behind your direct dependencies are. Each maps to a control an auditor tests, and each is easy to export with a date.
Why a few metrics beat a dashboard full of charts
Auditors do not grade your dashboard. They test controls, and a metric helps when it answers a question they already ask: is scanning complete, are issues handled on time, are exceptions controlled? A small set, reviewed on a calendar, is better evidence than twenty charts nobody reads.
The five
| Metric | Question it answers | How to compute |
|---|---|---|
| Coverage | Is every in-scope repo scanned? | Scanned repos divided by in-scope repos |
| Open findings by age | Are we keeping up? | Count in buckets, such as under 30 days, 30 to 90, over 90 |
| Time to fix | Do we meet our own policy? | Median and worst case, by severity |
| Exceptions | Are we controlling misses? | Count open, oldest age, overdue reviews |
| Update lag | Are we drifting? | Direct dependencies more than one major version behind |
Coverage comes first because a perfect time to fix means little if a third of the repositories are never scanned. GitHub documents that its dependency graph is built from manifest and lock files in a repository, so repositories without them may show an incomplete picture. Reconcile the list.
Read the numbers honestly
- A shrinking backlog and a growing exception list can mean you are closing issues by excusing them. Look at both together.
- A median hides slow outliers, so also report the longest open item.
- Severity labels are a starting point. Add whether the issue is in the CISA Known Exploited Vulnerabilities catalog, since CISA recommends using it as an input to prioritization, and whether the vulnerable code is reachable.
Set thresholds that trigger action
A metric with no threshold is trivia. Pick triggers in advance:
- Coverage below 100 percent of in-scope repos opens a ticket to fix the gap.
- Any item past its policy deadline requires an exception record within a day.
- Any exception older than its review date goes on the next monthly agenda.
Record the discussion. The minutes are part of the evidence that the control operates.
Keep the history
Metrics only help if you can show past values. Save a dated export each month, because many tools display only the current state. A year later, those snapshots are how you prove what the backlog looked like during the window.
Avoid vanity numbers
"Vulnerabilities fixed this quarter" rewards churn. "Percentage of dependencies updated" can be inflated by trivial bumps. Prefer measures tied to risk and to your written policy.
Try it yourself
Open the demo and look at how findings are grouped and aged in a vulnerability management view. Think about which counts you would export each month.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard's dependency scanning, reachability analysis and compliance and evidence automation produce the underlying data for these counts. Free scan: https://gold.safeguard.sh/scan.
Quick check
Do auditors require specific metrics?
No. They test your controls. Metrics are useful when they show a control operating.
How often should I review them?
Monthly works for most small teams. Save the numbers and the meeting notes each time.
Sources
- CISA, Known Exploited Vulnerabilities Catalog
- GitHub Docs, About the dependency graph
- AICPA and CIMA, SOC suite of services
Last reviewed: 19 October 2026.
