Once a quarter, check five things: coverage of products, freshness of each SBOM, accuracy against real builds, depth of the dependency graph, and whether anyone used the data. If a check fails, fix the pipeline, not the file. Record the results so you can see the trend.
Why a health check
SBOM programs decay quietly. A pipeline step breaks, a new service launches without one, a format option changes, and the data slowly stops matching reality. Nobody notices until an incident. A short, regular check catches the decay while it is cheap to fix.
The five checks
| Check | Question | How to test |
|---|---|---|
| Coverage | Does every product and service have an SBOM? | Compare your service list with your SBOM store |
| Freshness | Is each SBOM from the latest release? | Compare SBOM dates with release dates |
| Accuracy | Does the SBOM match the build? | Pick three services, regenerate and diff |
| Depth | Are transitive components and relationships present? | Open one SBOM and trace a transitive path |
| Use | Did anyone use the data this quarter? | Count searches, requests and tickets referencing it |
Check 1: coverage
Start from a source of truth for what you run, such as a service catalogue or asset discovery results, and look for items with no SBOM. Missing items are your biggest risk, since they are invisible by definition.
Check 2: freshness
For each service, compare the SBOM date to the last deploy. Old data after a recent deploy suggests the generation step is not running. Our guide on how often to regenerate an SBOM helps you set the rule.
Check 3: accuracy
Regenerate for a sample and diff against the stored version. Differences you cannot explain point to unstable generation or to changes outside the pipeline. See is your SBOM identical every time you generate it.
Check 4: depth
Open a sample file and trace one transitive dependency back to a root. If you cannot, the graph is missing, and incident scoping will be slower than it should be.
Check 5: use
An unused SBOM store is a warning sign. If nobody searched it, either nothing happened or people do not know it exists. Run a small drill, such as finding a component in 30 minutes, to see whether the data works under pressure.
Scoring and follow up
Give each check green, amber or red, and assign an owner to every amber and red. Keep the scorecard in a shared document. Compare quarter on quarter. If a check is green for several quarters, you can sample less often, but keep the coverage check running.
What to avoid
Do not chase a total component count or a perfect score. The point is that the data answers real questions quickly, which is easiest to show with a drill.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how ongoing checks catch change without a manual review.
Safeguard's SBOM and dependency scanning, asset discovery, and compliance and evidence automation support this kind of recurring check. You can try a free scan.
Quick check
How long does the check take?
For a modest portfolio, a couple of hours once the sampling method is set.
What if coverage is low?
Fix coverage first. Everything else depends on having an SBOM to check.
Last reviewed: 19 October 2026.
