Keep each release's SBOM as an unchanged snapshot tied to the exact build, record every correction as a new revision instead of an edit, and store the timestamp and author of each. That gives you a trustworthy answer to what shipped on a given date.
Why history matters
Customers and assessors do not only ask about today. They ask whether a version you shipped last spring contained a component named in a new advisory. If the only copy of your SBOM is the latest one, you can answer only about the present. The NTIA document lists timestamp as a baseline field and treats frequency and accommodation of mistakes as practices to define. Both point at keeping a dated record, and at having a way to correct it without erasing it.
What a good history contains
| Element | Why |
|---|---|
| The SBOM file as received or generated | The original, untouched |
| Product and release or build identifier | Links the SBOM to what shipped |
| Creation timestamp and author | Shows when and by whom |
| Revision number | Separates the first version from corrections |
| Reason for each revision | Answers "why did this change?" |
| Hash of the file | Detects later tampering or damage |
| Link to the source commit or image digest | Lets you regenerate or verify |
Snapshots versus edits
A snapshot is frozen. An edit changes a record in place. For a record people rely on, prefer snapshots. When a mistake is found, such as a wrong version, create revision two, mark revision one as superseded and say why. The article on correcting a mistake in a shared SBOM has a policy you can adapt, and which revision to use when a supplier sends an update covers the receiving side.
How long to keep it
No single answer fits every case. Retention depends on your contracts, the life of the product, and any rules that apply to your sector. A reasonable starting point is to keep SBOMs for as long as you support the release, and for any longer period your contracts or regulators require. Check the actual requirement with your own counsel or compliance lead, because this post does not give legal advice. The wider question is covered in audit evidence retention.
Spreadsheet versus platform
A spreadsheet can hold history if you copy the file for every release, never overwrite and keep a change log. It breaks down when many people touch it. A platform can make this automatic: each import becomes a version, edits are logged, and old records are read only. Whichever you use, test restoring a record from a year ago. If restoring is hard, history is not really being kept.
Practical routine
- Generate the SBOM in the build pipeline.
- Store it with the release artifacts.
- Record the hash and the build identifier.
- Import it into your tracking system.
- On any correction, add a revision with a reason.
- Once a quarter, pick a random old release and retrieve its SBOM as a drill.
The drill catches broken storage links and expired buckets before a customer does. For naming, see how to name and store an SBOM for every release.
Where Safeguard fits
Safeguard's SBOM and dependency scanning and its compliance evidence automation help keep dated records of what a scan found. Try the free scan at gold.safeguard.sh/scan to see the kind of inventory you would be archiving.
Try it yourself
Click through it at your own pace, or open it full screen.
Look for how a change over time is recorded and what you could answer from that record later.
Quick check
Should I delete old SBOMs to save space?
Not before your support and contractual retention periods end. SBOM files are small compared with build artifacts.
Is a git repository enough for history?
It can be, if SBOMs are committed per release and tagged. It lacks access scoping and cross product search, which platforms add.
Sources
Last reviewed: 19 October 2026.
