Generate one SBOM per build and tie it to the artifact identifier, so it describes the release. Add a per environment snapshot only when you need to detect drift or cover things the build cannot see, such as hosts patched in place. The two answer different questions.
What each one answers
A per release SBOM answers: what is in this build? It is created at build time, stored with the artifact, and never changes. A per environment snapshot answers: what is running here now? It is taken from the live system and changes as the system changes.
| Question | Use |
|---|---|
| What did we ship in release 42? | Per release SBOM |
| Which customers got a vulnerable build? | Per release SBOM plus deploy records |
| Does production still match release 42? | Environment snapshot compared with the release SBOM |
| Which hosts have a package nobody approved? | Environment snapshot |
When per release is enough
If every environment runs rebuilt, immutable images deployed by digest, then the release SBOM already describes each environment. The live state equals the artifact. A check that the running digest equals the approved digest is enough, and cheaper than a full snapshot.
When you also need snapshots
- Servers patched in place, where the live state moves away from any build.
- Environments where people can install packages or run emergency fixes.
- Platforms that add components at start time.
- Compliance or customer requests that ask what is deployed now.
For these, take snapshots on a schedule and diff them against the release SBOM. The difference is your drift. See how to compare installed packages.
Standard formats
Two formats dominate. CycloneDX describes itself as representing inventories of software components, dependencies, and the relationships between them. SPDX describes itself as an open standard for communicating SBOM information including provenance, license, and security details, and is recognized as ISO/IEC 5962:2021. Either works. Pick one, and use it for both release and snapshot documents so they can be compared.
Storage and naming
- Name each SBOM with the artifact identifier and build time.
- For snapshots, add environment name and capture time.
- Keep both in the same store, with search by component name and version.
- Retain release SBOMs as long as you support that release.
A simple rule
Per release is the record. Per environment is the check. If you can only do one, do the release SBOM, then verify live identifiers match.
Try it yourself
Click through it at your own pace, or open it full screen.
Open the inventory and consider whether this view came from a build or a live system. Knowing which one you are reading changes how you act on it.
What Safeguard does here
Safeguard generates SBOMs from dependency scanning and keeps monitoring them against new advisories. Try a free scan at gold.safeguard.sh/scan.
Quick check
Can one SBOM cover several environments?
Yes, if they run the same artifact. Verify that with identifiers rather than assuming.
Which format should I choose?
Either CycloneDX or SPDX works. Choose what your customers and tools accept, then stay consistent.
Sources
Last reviewed: 19 October 2026.
