Issue a new SBOM whenever you ship a new build or release, and issue an updated one when you learn something new about the components in an existing release. Put a timestamp on each, because a customer can only judge freshness if they know when the data was assembled.
What the NTIA report says
The NTIA minimum elements report lists a timestamp among the baseline data fields. It explains that the timestamp records when the data is assembled, the point of SBOM creation, and helps identify updated versions. On frequency, it says that if a software component is updated with a new build or release, a new SBOM should be issued, and that suppliers should issue an updated one when they learn new details about past ones.
That gives you two triggers: a change in the software, and a change in your knowledge about it.
Triggers in practice
| Trigger | Action |
|---|---|
| New release or build | Generate and publish a new SBOM |
| A component in a shipped release is found to be mislabelled | Re-issue for that release |
| Dependency updated in a patch release | New SBOM with the patch |
| New vulnerability in a shipped component | SBOM unchanged, but the vulnerability status changes |
The last row is important. A new vulnerability does not change what the SBOM lists, but customers will want to know whether it affects them. Pair the SBOM with a vulnerability exploitability statement, which says whether a known vulnerability actually affects the product.
Steps
- Generate the SBOM in the build pipeline, so it matches the artifact.
- Name and version it by release.
- Record the timestamp and the author of the data.
- Store every issued SBOM, not only the latest.
- Tell customers where to fetch updates, or notify them on re-issue.
What customers can reasonably expect
Most customers do not want a weekly file for software that has not changed. They want an SBOM for the version they run, a way to find newer ones, and a prompt answer when an advisory lands. Agree this in the contract or a trust page.
Mistakes
- Sending an SBOM generated from source months before the build.
- Overwriting old files, which breaks audits.
- Leaving the timestamp out.
Try it yourself
Open the demo and look at the component inventory it builds. Note the fields a customer would see.
Click through it at your own pace, or open it full screen.
Safeguard generates and exports SBOMs through SBOM and dependency scanning, and you can run a free scan at gold.safeguard.sh/scan.
Quick check
Do we reissue the SBOM when a new CVE is published?
The component list is unchanged, so usually no. Communicate whether the CVE affects the product through a separate statement.
Why keep old SBOMs?
Customers run older versions, and audits ask which components shipped in which release.
Sources
Last reviewed: 19 October 2026.
