An SBOM stops describing the software when the code or its dependencies change, which happens at the next build. The component list may still be right if nothing was rebuilt, but the vulnerability picture ages by the day. Check the timestamp against the release date and rescan.
Two kinds of age
Inventory age. The NTIA minimum elements report says a new SBOM should be created whenever a new build or release changes the software, and revised when new details are learned or errors found. So an inventory is current if it matches the latest build.
Finding age. New vulnerabilities are published against unchanged code. An inventory from last quarter can still be accurate while any scan results attached to it are out of date.
A freshness test
| Check | Pass | Fail |
|---|---|---|
| Timestamp is on or after the last release | Yes | File predates a release |
| Commit or digest is named | Yes | No link to code |
| Same artifact is still deployed | Yes | Deployed build is newer |
| Vulnerability results dated within days of review | Yes | Results months old |
Steps
- Read the timestamp and the version identifier in the file.
- Find the deployed version for that product.
- If they match, accept the component list and rescan it yourself.
- If they do not, request a fresh file or generate one from the artifact.
- Record the age in the review notes.
What to do with old files
Do not discard them. They are history. Keep each with its date so you can show what shipped at a given time, which matters if a later vulnerability needs to be traced to past releases.
A worked example
A seller uploads an inventory dated early in the quarter. The service was redeployed twice since. Compare the digest in the file with the digest running today. They differ, so the file describes a build that no longer exists. Ask for a fresh file from the current image and keep the old one as a record of what shipped earlier.
Now take the opposite case. The file is two months old, but the service has not been rebuilt, and the digest matches. The component list is still right. Rescan it against current advisories and treat any older findings as history.
Setting a standard
For ongoing work, a workable rule is that every release produces an inventory and each is stored with the release. Then freshness is automatic, and the question "how old" becomes "which release".
The deal timeline problem
Data rooms stay open for weeks. A file uploaded on day one may be stale by signing. Agree up front that the seller refreshes inventories at a set point and tell the buyer which date it reflects.
Safeguard offers SBOM and dependency scanning, asset discovery and compliance and evidence automation, and you can run a free scan at gold.safeguard.sh/scan.
Quick check
Is a six month old SBOM useless?
Not useless as history, but it should not support a statement about current risk.
Sources
Last reviewed: 19 October 2026.
