Report five numbers each month: inventory coverage, median intake decision time, overdue vulnerability fixes, use of unapproved packages, and aged exceptions. Together they show whether you can see your open source, whether the process is usable, and whether risk is shrinking.
Why only five
Dashboards with forty charts are not read. Pick a few measures that change a decision. Each number below has a clear owner and a clear action when it moves the wrong way.
The five numbers
| Number | Definition | What a bad trend means |
|---|---|---|
| Inventory coverage | Share of production services and shipped products with a current SBOM | You cannot answer exposure questions fast |
| Intake decision time | Median and 90th percentile days from request to decision | The process is too slow, expect shadow use |
| Overdue fixes | Count and share of open vulnerabilities past their policy deadline, by severity | Remediation capacity or ownership problem |
| Unapproved use | Packages found in builds or proxy logs not on the approved list | The process is being bypassed |
| Aged exceptions | Open exceptions past expiry or older than a set age | Risk is being deferred without a plan |
How to measure each
Coverage needs a denominator, so keep a list of products and services. Count those with an SBOM generated in the last release.
Decision time comes from your intake tool's timestamps. Report the 90th percentile too, since slow outliers are what developers remember.
Overdue fixes need a deadline per finding, which is why the policy must define the start of the clock. Use reachability and exposure to prioritize inside the overdue list.
Unapproved use needs a join between your approved list and logs or SBOMs. Treat the first report as a baseline, not a failure.
Aged exceptions come from the exception register. Report counts by owner team.
Reading the numbers together
- Fast decisions and low unapproved use mean the process is working.
- Slow decisions and high unapproved use mean developers are working around you.
- High coverage and high overdue fixes mean you see the risk but cannot fix it, so look at capacity.
- Low coverage means every other number is unreliable.
Presenting to leadership
Show the trend over six months, not just the current month. Add one sentence per number saying what you will do next. Do not invent targets you cannot influence. Agree on targets with the owners first.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how ongoing monitoring produces the data these numbers need.
Quick check
Should we report the total number of vulnerabilities?
Total counts rise with scanning depth and say little on their own. Overdue counts against policy are more useful.
Who owns these numbers?
The program lead owns the report, and each number has an owning team for action.
Safeguard scans dependencies and builds SBOMs, runs reachability analysis, and applies policies and gates on pull requests, so the rules in this post can be checked automatically. Autonomous fix PRs are off by default, with every category on Manual. You can run a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
