Five metrics show whether your SBOM program can support an incident: coverage of shipped releases, dependency depth, freshness, time to answer a component query, and the share of unknowns. Track them monthly, define each in writing, and watch the trend rather than a single number.
The five metrics
| Metric | How to compute | What it tells you |
|---|---|---|
| Coverage | Shipped releases with a stored SBOM, divided by all shipped releases | Whether a search can see your estate |
| Depth | Share of SBOMs that include transitive dependencies | Whether a hit would be visible |
| Freshness | Age of the SBOM relative to the release or last dependency change | Whether the SBOM matches what runs |
| Time to answer | Minutes from a component query to a three group answer | Real speed, measured in drills |
| Unknown rate | Components with no version, or products with no SBOM, over the total | How much of the answer is a guess |
Why these five
The CISA review of the Log4j event reported that none of the SBOM-using groups it spoke with had used them to identify vulnerable Log4j deployments, and pointed to variances in field descriptions and a lack of version information among the limits. Coverage, depth and unknown rate measure exactly those limits in your own data. Time to answer measures whether the data turns into action.
Avoid vanity numbers
- A count of SBOMs generated says little. A count of releases covered says more.
- A high coverage figure with shallow depth gives false comfort. Report both together.
- Time to answer measured once by an expert is not representative. Measure it in drills with whoever is on call.
- Do not set a target so strict that teams hide unknowns. An honest unknown rate is more useful than a flattering one.
How to collect the data
- Keep a release register: product, version, date, SBOM location. Without it, coverage cannot be computed.
- Add a depth flag to each SBOM at ingestion, based on whether transitive components are present.
- Record generation time and the build it describes.
- Run the 30 minute component drill and log the time.
- Count unknowns as a separate line, not buried in coverage.
Reading the trend
If coverage rises but time to answer does not fall, look at storage and search, not generation. If freshness is poor, find which products rebuild often without updating the SBOM. If unknowns are stuck, the cause is usually a missing version in a lockfile or a vendored library.
Reporting to leadership
Give four lines: what share of releases can be searched, how fast you answered the last drill, what the main gap is, and who owns closing it. Keep the monthly view to one page.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how monitoring surfaces new findings against an existing inventory.
Quick check
Is there a standard target for these metrics?
Not that these sources define. Set your own targets and compare with your own history.
Which one should we start with?
Coverage, because you cannot search what you have not stored.
Sources
Last reviewed: 19 October 2026.
