A one-page release security sign-off lists the release ID and artifact digest, scan results, SBOM link, any open waivers, the rollback plan and the named approvers. Its job is to let a reviewer decide in minutes and to leave a record an auditor can follow.
Why one page
Sign-off documents that run to many pages get skimmed. A single page forces the team to say what matters. It also makes the pattern repeatable, which is what auditors sample against. Detail lives behind links, not on the page.
The template
| Section | Contents |
|---|---|
| Release | Product, version, release ID, artifact digest, date |
| Change | Link to the change record and pull requests, risk tier |
| Scan results | Date and tool, counts by severity, any known exploited findings |
| Gate outcome | Pass, fail or waived, with the rule that applied |
| SBOM | Link to the SBOM for this digest |
| Waivers | Each open waiver with owner and expiry |
| Compensating controls | What reduces residual risk |
| Rollback | Target version, its known findings, time limit if vulnerable |
| Deferred checks | Anything run after release, with deadline |
| Approvals | Names, roles and timestamps |
How to fill it in without extra work
Generate the page from pipeline data. Anything typed by hand is a place for errors. Leave only the judgment fields, such as the waiver reasoning and the rollback note, for people.
What reviewers should ask
- Does the digest on this page match what is queued to deploy?
- Is there a known exploited finding, and is it handled?
- Do any waivers expire soon?
- Is the rollback target safe enough for a short period?
- Is the approver independent of the author?
NIST SP 800-218 practice PS.3.1 says to retain release files and supporting data such as integrity verification and provenance data for each release. The sign-off page is a convenient index to that stored material.
Keep it with the release
Store the page beside the release evidence, named by release ID. When someone asks months later why a release shipped, this is the first document they open.
Adjust by risk tier
Low risk releases may need only an automated version of the page with no human review. High risk releases may add an architecture or privacy note. Define the tiers once and apply them consistently.
A short example of the judgment fields
Two fields deserve real sentences. In the waiver field, write why the finding cannot be fixed now and what limits the exposure. In the rollback field, write which version you would return to and whether it carries findings the current release fixed. Everything else on the page should come straight from the pipeline.
Quick check
Who signs it?
An engineering approver and, for waivers or higher risk tiers, the risk owner. Not the author alone.
Does every release need a human sign-off?
Not necessarily. Routine passing releases can use automated approval if your policy defines that tier.
Sources
Safeguard offers compliance and evidence automation and a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
