Store every SBOM as a new, immutable record linked to the release it describes, and never overwrite an old one. When a customer, auditor or incident responder asks what a past release contained, only the version you generated at the time can answer. A "latest" copy cannot.
What overwriting destroys
Teams often keep one SBOM per product and replace it whenever they rebuild. That feels tidy and causes three problems.
- No history. You cannot answer what a release shipped in March if March's file was replaced in April.
- No accountability. If you gave a customer an SBOM and later find an error, you cannot show what they received.
- No audit trail. Reviewers want evidence tied to a date, and a replaced file has none.
CycloneDX points toward the right model. It says every generated BOM should have a unique serial number, even if the contents have not changed. A new document each time, with its own identity, is the intended pattern.
A simple storage model
| Element | Rule |
|---|---|
| Record | One immutable file per generation |
| Key | Product, version, build identifier and digest of the file |
| Metadata | Generation time, tool name and version, source commit |
| Link | Each record points to the release or artifact digest it describes |
| Corrections | A new record that references the one it replaces |
| Deletion | Only under a written retention policy, logged |
Naming matters less than consistency. Put the release version and a build identifier in the file name, and keep the same facts in searchable metadata.
Corrections without rewriting
Sometimes an SBOM is wrong. The fix is a new record, not an edit. Mark the old one as superseded, note why, and keep it. Anyone who received the old file can then see which one replaced it and what changed. This is also kinder to you: it shows that the process works.
Retention
Decide how long to keep records and write it down. Useful inputs include how long you support a release, what your customers' contracts say, and what regulators in your sector expect. Do not invent a number in a blog post: check the requirements that apply to you. Whatever period you choose, apply it to the whole set, so you do not keep old files for some products and not for others.
Controls worth having
- Write once storage or object versioning, so an accidental overwrite is not possible.
- Access control, since SBOMs can reveal internal component names and structure.
- A digest recorded when the file is stored, so later tampering can be detected.
- An index that lets you search by component, so old records stay useful for incident response.
Making old SBOMs useful
An archive is only valuable if you can query it. When a new advisory lands, you want to ask which past releases contained the affected component, without regenerating anything. Keep the component list indexed, and rescan stored records when the vulnerability data changes.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a new advisory is matched against components you already track.
Where Safeguard fits
Safeguard offers continuous monitoring of your dependencies and SBOM based inventory so new advisories can be matched to what you already ship. Try the free scan at gold.safeguard.sh/scan.
Quick check
Is it ever fine to delete an old SBOM?
Yes, under a written retention policy that you apply consistently and log.
How do I fix an SBOM that was wrong?
Publish a new record that references the old one, and mark the old one superseded.
Sources
Last reviewed: 19 October 2026.
