Yes. An SBOM lists the components in a build. Because vulnerability data changes while the build does not, you can re-match the saved SBOM against fresh advisory data every day and learn about new problems without compiling anything. That is faster and cheaper than rebuilding.
Definitions
An SBOM (software bill of materials) is a machine readable list of the components in a piece of software, such as in the SPDX or CycloneDX formats. Rescanning here means comparing that list to current advisory data, not re-analysing the code.
Why this works
The risk in a shipped build changes in two ways: the build changes, or knowledge about its parts changes. The second is far more common between releases. Comparing a list to a database takes seconds. Rebuilding takes minutes to hours and can itself introduce change.
Steps
- Generate an SBOM for every released artifact. Do it in CI at build time, from the actual resolved dependencies.
- Store it with the version. Keep the SBOM keyed by artifact name, version and digest.
- Schedule the match. Run a nightly job that loads each current SBOM and queries advisory data. A batch query endpoint, such as the one OSV documents for package versions (OSV API docs), makes this efficient.
- Record findings per artifact. Alert on new ones only, so people are not paged for known items.
- Retire old SBOMs. When a version leaves production, mark its SBOM inactive.
What an SBOM rescan can and cannot tell you
| It can | It cannot |
|---|---|
| Show which deployed versions contain an affected package | Prove a flaw is reachable |
| Cover every release in minutes | Find components the SBOM never listed |
| Support audit evidence of ongoing monitoring | Detect a problem in code you wrote |
The weak point is SBOM quality. If the generator missed vendored code, native libraries or a shaded dependency, no later rescan will find them. Check an SBOM against a real build before you rely on it, as in how to validate and scan an SBOM in CI.
Try it yourself
Open the inventory demo and look at how components, versions and findings are tied together. Notice that the component list is the stable part, and findings are layered on top.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning and reachability analysis, and you can test a manifest or SBOM with the free scan at gold.safeguard.sh/scan.
Quick check
How long should I keep old SBOMs?
As long as the version is deployed, plus the period your audits and customer contracts require you to answer questions about it.
Is the SBOM enough to decide what to fix first?
No. Add severity, exploit evidence and reachability to rank the matches.
Sources
Last reviewed: 19 October 2026.
