A supplier should generate a new SBOM whenever a component is updated with a new build or release, and again if it corrects errors in an earlier one. For delivery, agree something both sides can sustain: per release, plus on request after a major vulnerability. Write the arrangement into the agreement.
What the NTIA report says
The NTIA minimum elements report lists practices and processes alongside the data fields: frequency, depth, known unknowns, distribution and delivery, access control and accommodation of mistakes. On frequency it says that if a component is updated with a new build or release, a new SBOM must be created to reflect the new version, including builds that integrate an updated dependency. It adds that if the supplier learns new details about the underlying components or wants to correct an error, it should update the SBOM data as well.
The report also says that for some elements, such as access, several practices exist, so the minimum requirement is that some arrangement be specified. That is the useful point for a buyer: pick one, and put it in writing.
Options for refresh and delivery
| Approach | Good for | Watch out for |
|---|---|---|
| Every release, pushed to you | Products you embed or run | Volume if releases are daily |
| Every release, available on a portal | Many customers | You must check it |
| Quarterly summary | Low risk software | Gaps between releases |
| On request after an incident | Supplement to others | Slow if you need it urgently |
For most partnerships, release based delivery plus on demand updates after high profile vulnerabilities is workable.
Terms to settle
- Trigger. Each production release, each security patch, each change to a bundled component.
- Format. SPDX or CycloneDX, with the seven baseline fields.
- Depth. Direct and transitive components, and what happens with bundled binaries.
- Known unknowns. The supplier lists what the file does not cover.
- Delivery. Push, portal or API, with access control.
- Corrections. How you report an error and how quickly it is fixed.
- Retention. How long old SBOMs stay available, so you can answer questions about older versions.
Your side of the bargain
An SBOM is only useful if someone reads it. Decide who ingests it, how it is compared with the last one, and what triggers action. Automated diffs help: new components, removed components and changed versions are the three lists worth reviewing. This is not legal advice, so ask counsel to word the clauses.
Try it yourself
Open the demo to watch continuous monitoring flag changes in a dependency set over time. Look at what a diff between two versions highlights.
Click through it at your own pace, or open it full screen.
Safeguard generates SBOMs and monitors dependencies continuously, and you can try a free scan on a project of your own.
Quick check
Is a yearly SBOM enough?
Rarely. Software changes with every release, and a yearly file would describe code that no longer exists.
Do I need SBOMs for internal tools?
Start with what you ship or depend on for customers, then widen as capacity grows.
Sources
Last reviewed: 19 October 2026.
