For each release, keep five things tied to one release ID: the scan result, the digest of the artifact that was scanned, the SBOM, the gate decision with the approver's name, and any waivers with expiry dates. Store them read-only, so the record cannot drift after the fact.
Why per release, not per quarter
A quarterly scan report says little about the build you shipped on a Tuesday. An auditor testing a release wants to trace one change from approval to production and see what was checked on the way. If your evidence is organized by release, that trace takes minutes. If it is organized by date or by tool, it takes days.
NIST SP 800-218 (SSDF v1.1) points the same way. Practice PS.3.1 says to securely archive the necessary files and supporting data, such as integrity verification information and provenance data, for each software release. PS.3.2 says to collect, safeguard, maintain and share provenance data for all components of each software release, for example in an SBOM. PW.8.2 adds that testing results should be documented, with discovered issues recorded and triaged.
The release evidence pack
| Item | Why it matters | Example form |
|---|---|---|
| Release ID and version | Anchor for everything else | Ticket or tag name |
| Artifact digest | Proves which build was scanned | Image digest or file hash |
| Scan result | What was found at release time | Exported report with timestamp |
| SBOM | What the release contains | CycloneDX or SPDX file |
| Gate decision | Pass, fail or waived, and who decided | Pipeline record plus approval |
| Waivers | Accepted risk with owner and expiry | Signed entry |
| Fix tickets | What happens to non-blocking findings | Ticket links |
Practical rules
- Generate the pack in the pipeline, not by hand afterwards. Hand-built evidence is where mistakes and gaps appear.
- Name files by release ID so a search by ID finds everything.
- Make the store write-once or read-only for most people. SSDF PS.3.1 itself suggests read-only access for necessary personnel and no access for anyone else.
- Keep the timestamp of the scan, and the version of the vulnerability data if your tool records it. A result with no date is weak evidence.
- Decide retention up front and write it in the policy.
What not to keep
Raw logs from every scan step add volume without adding proof. Keep the result an auditor can read, plus the means to regenerate detail if asked. Also avoid screenshots as the primary record; they are easy to question and hard to search.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how one piece of evidence can map to more than one framework requirement.
Safeguard offers compliance and evidence automation alongside SBOM and dependency scanning, and a free scan is available at gold.safeguard.sh/scan.
Quick check
Is a screenshot of a clean scan enough?
It is weak. Keep a timestamped export tied to the artifact digest and release ID, so the result is traceable.
Do we need an SBOM for every release?
SSDF PS.3.2 describes provenance data for all components of each release, for example in an SBOM. Generating one per release is the simplest way to meet that.
Sources
Last reviewed: 19 October 2026.
