Version a shared SBOM by the software release it describes, add the date it was generated, and increment a revision number each time you reissue the same release. Put all three in the file name and inside the document, and keep a short changelog so customers can see what changed.
Two clocks, not one
An SBOM has two things that change independently. The software release changes when you ship. The SBOM itself changes when you correct it, add data or regenerate it against a newer vulnerability feed. If you only use one number, customers cannot tell a new release from a corrected copy of the old one.
So track both:
- Product version: the release the SBOM describes, such as 4.12.0.
- Document revision: how many times you have issued an SBOM for that release, such as rev 2.
The file name then reads something like product-4.12.0-sbom-rev2-2026-10-19.cdx.json. Ugly, but unambiguous.
What to put inside the file
SBOM formats carry their own metadata for this. The CycloneDX JSON reference defines a creation timestamp and a serial number, and says every BOM generated should have a unique serial number. Check your format's equivalent fields and fill them in. The file name is for humans; the metadata survives when someone renames the file.
Also note the main component the SBOM describes, with its version, so the file explains itself without the covering email. CISA's 2026 minimum elements guidance, published on 29 July 2026, updates and replaces the NTIA minimum elements from 2021, so check your fields against the current text when you review your template.
A simple changelog
Keep a plain text or table changelog for each product:
| Revision | Date | Reason |
|---|---|---|
| rev 1 | 2026-09-02 | First issue for release 4.12.0 |
| rev 2 | 2026-10-19 | Corrected a mislabelled library, added hashes |
Customers read this to decide whether to re-run their analysis. If the reason is "formatting only", they can skip it. If the reason is "added three missing components", they will want to.
Rules that keep it honest
- Never overwrite a shared file in place. Issue a new revision with a new name.
- Do not reuse a revision number.
- Keep every issued revision in your archive for as long as you keep the release supported.
- When a customer reports a problem, state which revision they hold in your reply.
- Mark superseded files as superseded, but leave them retrievable.
Corrections deserve special care. If an earlier SBOM was wrong, say so in the changelog instead of quietly swapping it.
Try it yourself
This demo shows a dependency inventory and how it changes with the code. Look at how a component list shifts between runs, which is why revisions matter.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard's SBOM and dependency scanning produces an inventory per build, so each release has its own record you can number and archive. A free scan lets you see one.
Quick check
Should the revision number reset for each product release?
Yes. Revision counts reissues of the SBOM for one release, so it starts again at 1 for each new product version.
Do customers need every old revision?
No. They need the current one and a changelog. You keep the older ones in your archive in case of a dispute or an audit.
Sources
- CycloneDX JSON reference, version 1.6
- 2026 Minimum Elements for a Software Bill of Materials (SBOM), CISA
Last reviewed: 19 October 2026.
