Yes. When a new vulnerability is announced, you need to know which shipped releases contain the affected component. NIST's Secure Software Development Framework asks producers to archive each release with supporting data such as integrity verification information and provenance data, for exactly that reason.
What the framework says
SSDF practice PS.3 is to preserve software releases to help identify, analyze and eliminate vulnerabilities discovered after release. Its first sub-practice says to securely archive the necessary files and supporting data, for example integrity verification information and provenance data, for each software release. The second says to collect, safeguard, maintain and share provenance data for all components of each release, for example in a software bill of materials.
The examples in the document are practical: allow read-only access to the archive for necessary staff and nobody else, keep integrity and provenance data in a separate location from the release files or sign it, and make provenance data available to acquirers and to your own operations and response teams.
Why it is a backup question
A backup plan for software has two jobs: restore running systems, and answer "what did we ship?" Without an archived inventory for each release, you may have to rebuild an old version just to find out what is inside it, and if the build no longer works, you cannot.
What to store per release
| Item | Why |
|---|---|
| Release artifacts or images | The thing customers have |
| SBOM | Which components and versions are inside |
| Hashes or signatures | To prove the archive is unchanged |
| Build provenance | Source revision, builder, steps |
| Dependency lockfiles | Exact resolved versions |
| Base image digests | The starting layers |
| Scan results at release time | What you knew when you shipped |
Steps
- Generate the SBOM in the release pipeline, not afterwards by hand.
- Store it next to a hash of the artifact, in a bucket with delete protection or object lock, and with write access limited to the release job.
- Sign or hash the SBOM and keep that value elsewhere.
- Index releases by version so support staff can find the right one.
- When an advisory lands, search the archived SBOMs for the component, list affected releases and notify.
- Review retention. Keep records as long as customers run that release.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at which fields the inventory records for each component. Those are the fields you will search when the next advisory arrives.
Safeguard generates SBOMs and scans dependencies continuously, and its compliance and evidence automation can keep dated records. Try the free scan.
Quick check
Is an SBOM from today enough for a release shipped last year?
No. Dependencies change. You need the inventory from the time of that release.
Who should be able to edit the archive?
Almost nobody. The framework example says read-only access for those who need it, and no access for anyone else.
Sources
Last reviewed: 19 October 2026.
