Name each SBOM after the release it describes, include the artifact digest, give it a unique serial number, and store it read-only next to the release record. Never overwrite an older SBOM. If you must correct one, publish a new revision and keep the old.
Why naming matters
An SBOM you cannot match to a specific build is nearly useless in an audit or an incident. Months later someone will ask what a given release contained when a new advisory lands. If the answer depends on guessing which file belongs to which build, you have lost the benefit.
NIST SP 800-218 practice PS.3.2 asks organizations to collect, safeguard, maintain and share provenance data for all components of each software release, for example in an SBOM. The practice is per release, so your storage should be too.
Fields that help you match and track
The CycloneDX specification gives you built-in fields for this.
| Field | What the spec says | How to use it |
|---|---|---|
| serialNumber | Every BOM should have a unique serial number, a lowercase RFC 4122 UUID in URN form | One per generated SBOM, even if contents are unchanged |
| version | Integer starting at 1, increment when the BOM is modified | Revisions of the same SBOM |
| metadata.timestamp | When the BOM was created | Evidence of when it was generated |
When a system receives several BOMs with the same serial number, the spec says it should use the highest version. So keep the serial number stable for a revision and change it for a new generation.
A naming pattern
Use something readable and sortable, for example:
product-name_1.8.2_sha256-ab12cd34_sbom.cdx.json
The release version tells people what it is. The shortened digest ties it to the exact artifact. Put the full digest inside the document metadata too.
Where to store it
- In the artifact registry or release bucket beside the build, so they travel together.
- In the release evidence pack, linked by release ID.
- With write protection, so edits require a deliberate new revision.
- With a retention rule that matches your audit and customer commitments.
Generate it from the build, not from the repo
An SBOM generated from source can differ from what was actually built. Where possible, generate it from the final artifact or during the build, then compare it with the dependency lockfile as a sanity check.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how each component is listed with its version, and imagine that list frozen against a release ID.
Safeguard provides SBOM and dependency scanning, and a free scan is available at gold.safeguard.sh/scan.
Quick check
Do we need a new serial number for every release?
Yes. Each generated SBOM should have its own unique serial number. Use the version field only for revisions of the same one.
Can we regenerate an old release's SBOM later?
You can, but a regenerated one may differ from the original. Keep the original from release time as the record.
Sources
Last reviewed: 19 October 2026.
