A secure release checklist needs an exception decision, not another green tick

A known security issue appears in the release notes. The pipeline is green, the deployment slot is booked and someone says it can be fixed later. Before approving the release, the engineering release lead needs to know who accepted that exposure and who will make “later” happen.

A secure release checklist is useful when it connects requirements to evidence and authority. It is much less useful when every unresolved item becomes a tick because a meeting took place. Design the record so that a passed technical check, a missing test and an accepted exception remain visibly different.

Identify exactly what is being released

Start with the release identifier, source revision, build run and immutable artefact digest, together with the intended environment. Associate security results and approval with that identity. A test report for yesterday’s build does not establish the status of a binary rebuilt today, even if both carry the same friendly version label.

Also identify configuration and migration changes that travel with the deployment. The application image may be unchanged while a permission, dependency or database migration materially changes the release risk. Decide what evidence those changes require instead of allowing the artefact identifier to narrow the review accidentally.

NIST’s SSDF version 1.1, published in February 2022, calls for software-security criteria and information to support them. Its implementation examples include recording approvals, rejections and exception requests in the workflow. That is a useful foundation for a release gate: capture a decision against criteria, rather than treating tool execution as the decision itself.

Ask five questions at the gate

1. Do the required checks cover this change? Identify the applicable testing and review requirements, the evidence produced and any exclusions. A scan that did not run, failed to analyse relevant code or excluded the changed component is not a demonstrated pass.
2. What unresolved findings affect the deployed service? Relate each material issue to the affected component, reachable behaviour, exposure and proposed treatment. Keep the reasoning behind prioritisation available; a severity label alone cannot describe the deployment context.
3. Is this the approved artefact from the expected build? Verify provenance and integrity against the organisation’s policy, including the expected repository and workflow where applicable. Retain the verification result with the release.
4. Can operations support the change? Confirm deployment permissions, configuration, monitoring, escalation ownership and any capacity or dependency assumptions. Assign responsibility for watching the service after rollout.
5. What can be reversed, and what cannot? Identify the tested rollback or recovery route, the person authorised to invoke it and its limits. An old application binary may not work against a newly changed data model; external actions already taken may need reconciliation.

Use these questions to select evidence appropriate to the change. They do not require identical ceremonies for a routine patch and a major migration. Routine decisions can be automated against agreed policy, while exceptions need the authority specified by that policy.

Understand what the attestation proves

GitHub artifact attestations record signed provenance information, including the build workflow, repository and commit. GitHub’s documentation says the attestations must be verified to provide their security benefit and explicitly warns that they do not guarantee an artefact is secure.

That distinction should change the checklist wording. “Attestation created” confirms an output exists. “Attestation verified against the approved origin and build policy” supports a provenance decision. Neither establishes that the application has no exploitable vulnerability or that its deployment configuration is correct.

Keep those claims separate when briefing the approver. If origin verification passes but a required security test is unresolved, report both. Do not use the strength of one kind of evidence to conceal the absence of another.

Give the exception a life after deployment

In a hypothetical release, the team wants to ship with a known issue in an administrative export function. The proposed restriction is to keep that function disabled until a fix is verified. A useful exception identifies the affected release and environment, the exposure being accepted, evidence that the restriction is effective, the authorised risk decision-maker and the engineer responsible for remediation.

It also states the expiry or review trigger and what happens if the fix is late. If the function must be enabled, the assumptions behind the acceptance have changed and the decision must be revisited. “Accepted by the project” without a named authority and follow-up owner is not enough to govern that change.

After release, check that the mitigating configuration is actually in place and that the service behaves within its agreed operating limits. Keep the remediation open until the corrected artefact is deployed and the relevant evidence is verified. Closing the development ticket alone does not establish that production exposure ended.

For purchased components and software delivered by third parties, carry the same evidence discipline into software-supplier security requirements. The immediate release decision should say what was demonstrated, what remains exposed and who owns the next action.