Generate a new SBOM every time you produce a new build or release, and rescan the stored SBOMs against fresh vulnerability data on a regular schedule. The two jobs are different. The first keeps the inventory true. The second keeps the risk picture true.
What the NTIA text says
The NTIA minimum elements report lists frequency as a practice. If a software component is updated with a new build or release, a new SBOM must be created to reflect the new version. That covers each release you ship, and builds that change the contents.
An SBOM is a snapshot of one version. When the version changes, the snapshot is stale.
Two clocks, not one
Think of two separate schedules.
Inventory clock. Tied to your build. Every release creates a new SBOM, ideally in the pipeline, with no manual step. If you rebuild nightly and dependencies float, the inventory changes nightly.
Risk clock. Tied to the outside world. New vulnerabilities are published every day against components you already shipped. A stored SBOM from March can be matched against advisories published in October. You do not need to regenerate it, only rescan it.
Teams that only scan on commit miss the second clock.
A practical schedule
- On every pull request: scan the proposed dependency changes.
- On every release build: generate and store the SBOM, tagged with the version and a timestamp.
- Daily or continuous: match stored SBOMs for deployed versions against new advisories.
- After a major incident: rescan everything immediately and search for the affected component.
Edge cases
If your builds are not reproducible, two builds from the same commit can differ. Store the SBOM that matches the artifact you actually shipped, not one regenerated later from source.
For long lived deployments, keep SBOMs for every version still running. An old version in production is an old risk.
For software you receive from suppliers, ask them for a new SBOM with each release and keep the last few. See how to check a supplier SBOM.
Storage and search
An SBOM nobody can search is just a file. Keep them somewhere you can ask which deployed versions contain a given package, and get an answer in minutes.
Safeguard stores SBOMs from dependency scanning and supports continuous monitoring of them. The free scan at https://gold.safeguard.sh/scan shows the starting point.
Click through it at your own pace, or open it full screen.
What to automate first
If you automate only one thing, automate storing an SBOM with each release artifact. Name it after the version and keep it next to the build. Everything else, from rescanning to answering a customer, depends on having that file when you need it. A missing SBOM for a version you shipped two years ago cannot be recreated reliably, because dependencies may have moved since. Treat the SBOM as a build output, in the same class as the binary itself, and give it the same retention rules.
Quick check
Does a new vulnerability mean I need a new SBOM?
No. The SBOM describes what is in the software, and that has not changed. Rescan the existing SBOM against the new data.
Sources
Last reviewed: 19 October 2026.
