To show that production matches the release you tested, keep five linked records: the artifact identifier, its SBOM, the scan results, the approval, and a post deployment comparison of what is actually running. Together they let a reviewer trace one release from build to production without relying on memory.
What reviewers are really asking
When a reviewer or customer asks about change management, the underlying question is whether the system in production is the one you tested and approved. A commit hash answers part of that. It does not show the dependencies or the image content. That is where drift between environments weakens the story.
The five records
| Record | What it shows |
|---|---|
| Artifact identifier | Exactly which build was deployed, such as an image digest |
| SBOM | What that build contains, in a standard format |
| Scan results | Known vulnerabilities at the time of release |
| Approval | Who accepted the release, and when |
| Post deploy comparison | That running production matches the tested artifact |
The SBOM formats most teams use are CycloneDX and SPDX. CycloneDX describes itself as a way to represent inventories of components, dependencies, and their relationships. SPDX describes itself as an open standard for communicating software bill of materials information, and is published as ISO/IEC 5962:2021.
How to collect them without extra work
- Have CI write the identifier and SBOM as build outputs, stored with the artifact.
- Attach scan results to the same identifier.
- Use your deployment system's approval step, and keep its log. GitHub environment approvals as deployment evidence shows an example.
- After deploy, read the running identifier from the cluster or host and compare it with the approved one. Save the result.
- Store everything under the release label, with a retention period that matches your policy.
Handle exceptions in the open
If production differs from the tested release, for instance after an emergency fix, say so in the record, with the reason, the approver, and the date it was reconciled. A documented exception reads better than a gap.
What not to claim
Do not describe these records as proving that the software is free of vulnerabilities. They show what you shipped and what you knew at the time. Also avoid implying a certification or attestation you do not hold. Describe your practice factually, and let the evidence speak.
Try it yourself
Click through it at your own pace, or open it full screen.
See how evidence can be mapped to framework controls. Think about which of the five records supports which control.
What Safeguard does here
Safeguard supports compliance and evidence automation alongside SBOM generation and dependency scanning, which helps collect these records in one place. Try the free scan at gold.safeguard.sh/scan.
Quick check
Is an SBOM alone enough?
No. It shows contents. You also need to tie it to a specific deployed artifact and an approval.
How long should I keep these records?
Follow your own retention policy and any contract terms. Ask your compliance owner for the number.
Sources
Last reviewed: 19 October 2026.
