Archive whatever you would need to rebuild, explain and defend a release: source and build inputs, third party libraries, an SBOM, scan results, release approvals and documentation. NIST's draft SSDF 1.2 suggests setting retention by the software's lifecycle and end of life. There is no single number in the sources I read.
What NIST says
Under task PO.1.2, the draft gives a notional example: define policies that specify "what needs to be archived for each software release (e.g., code, package files, third-party libraries, documentation, data inventory) and how long it needs to be retained based on the SDLC model, software end-of-life, and other factors." Another example says policies should cover the whole life cycle, including telling users of impending end of support and the end-of-life date.
These are examples inside a draft, not requirements. The framework does not give a retention period.
A practical archive list
| Item | Why a buyer or investigator may ask |
|---|---|
| Source at the release tag | Reproduce or review what shipped |
| Lockfiles and package files | Know exact dependency versions |
| Third party libraries or their hashes | Confirm what was inside |
| SBOM for the release | Answer "were we affected?" quickly |
| Scan results and release gate outcome | Show checks ran before release |
| Build logs and provenance data | Show how the artifact was produced |
| Release notes and known issues | Explain support and fixes |
| Approval record | Show who signed off |
Choosing a retention period
| If your retention is driven by | Then the clock usually starts |
|---|---|
| Support commitment | At end of support, not at release |
| Contract terms | As the contract specifies, so read it |
| Legal or regulatory duty | Per your counsel's advice |
| Nothing specific | Pick a defensible default and write it down |
For a general discussion of evidence retention, see audit evidence retention.
Two cautions
- Do not keep secrets in the archive. Store references, not credentials.
- Retention and deletion pull in opposite directions. Where privacy law applies to data in the archive, involve counsel before setting a long period.
Making it automatic
Generate the SBOM and scan record in the release pipeline and store them next to the artifact. Manual archiving fails the first busy week.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at the check results attached to the change. Those are the records worth keeping for each release.
Quick check
Does SSDF set a retention period?
Not in the draft text I read. It suggests defining one based on lifecycle and end of life.
Should the SBOM be archived per release?
It is a useful artifact to keep, because it lets you answer exposure questions about an older release later.
Safeguard provides SBOM and dependency scanning and policies and gates, so release records can be produced in the pipeline. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
