Cybersecurity Engineering Handbook / Chapter 64
Release Security Review Template
Run a release security review that turns design, test, vulnerability, logging, recovery, and risk evidence into an explicit ship decision.
Preparing audio…
Audio edition
Release Security Review Template
A release review begins with a claim: this particular change is safe enough to expose to production. The review exists to make that claim answerable. It connects the behavior being changed to the requirements that govern it, the threats that could defeat it, the evidence available now, and the people authorized to stop or accept the release.
Consider the Customer Export Service from the preceding appendices. The release moves export work from an API to queue workers by means of signed job envelopes. Tenant authorization, envelope verification, replay rejection, archive access, and audit events have all been designed. Automated signing-key rotation will not be ready, however, so the team has an approved exception for a bounded period of manual rotation.
The exception is an input, not a ship decision. The release reviewer must still confirm that its temporary controls exist, that evidence belongs to the code and configuration being released, and that production checks can reveal a bad assumption before the change is allowed to continue. A release review is where those separate facts become one accountable decision.
Give the gate a boundary
Use this record for a new system or for a change that alters a security boundary: identity or authorization, sensitive-data handling, public exposure, privileged operation, deployment authority, supply-chain trust, security telemetry, recovery behavior, or an accepted exception. Routine changes may use a lighter process, but the team should state who decides which path applies. Otherwise the most consequential change can disappear inside an ordinary release.
Fix the scope before collecting evidence. Name the release artifact or immutable version, target environment, affected interfaces and data, assurance level, deployment window, and rollback or containment boundary. A test report for yesterday’s commit or a threat model for a different data flow does not support today’s decision merely because it is nearby.
The record should let a reviewer answer these questions without reconstructing the release from tickets:
- What security behavior changes, and what remains deliberately unchanged?
- Which requirements and credible failure paths govern that behavior?
- What evidence was produced from the release candidate or an honestly equivalent environment?
- Which facts block release, which residual risks have authority behind them, and what must production prove?
The working record
The form follows the decision rather than sorting evidence by department. Add detail in linked artifacts, but keep their exact identity, result, and consequence visible here.
# Release Security Review: <release and security boundary>
## Identity, scope, and authority
- Review ID and status:
- System, release artifact or version, and target environment:
- Assurance level and reason:
- Accountable release owner:
- Security and operations reviewers:
- Ship, block, rollback, and exception authorities:
- Deployment window and decision deadline:
- Related architecture, requirement, threat, exception, and incident records:
## Changed security behavior
- Capability and security-sensitive path being introduced or changed:
- Trust boundaries, identities, privileges, data, and tenants affected:
- Explicitly unchanged or out of scope:
- Worst credible release failure:
- First safe containment or rollback action:
## Requirements and release evidence
### <requirement or control ID>: <required behavior>
- Applicability and release consequence:
- Evidence artifact, immutable version, environment, and time:
- Result and reviewer:
- Limitation or untested boundary:
- State: satisfied | blocker | approved exception <ID>
## Vulnerabilities, dependencies, and unresolved findings
### <finding or risk>
- Affected component and exploit or failure path:
- Exposure, impact, and current controls:
- Evidence and disposition: fixed | blocker | accepted by <authority> under <record>
- Owner, due date, and invalidation trigger:
## Exceptions carried into the release
### <exception ID>
- Requirement gap and expiration:
- Approved scope and risk authority:
- Temporary controls that must be active before release:
- Evidence that each control is active:
- Revocation and containment trigger:
## Blockers and conditions
### <item>
- Why it affects the ship decision:
- Owner and deadline:
- Evidence required for closure:
- State and closure reviewer:
## Decision
- Decision: approved | approved with conditions | blocked | exception required
- Release scope covered by the decision:
- Evidence and residual risk relied upon:
- Conditions, if any, and consequence of missing them:
- Decision maker, authority, and time:
- Next review or expiry:
## Deployment and post-release proof
### <check or stop condition>
- Signal, query, test, or observation:
- Expected result and observation window:
- Owner and evidence destination:
- Stop, rollback, or containment threshold:
- Actual result and time:
## Closeout
- Final production state and any containment or rollback:
- Evidence archive:
- Open operational risks and owners:
- Review closed by and time:
Make the labels carry consequences
Approved means every release blocker is closed, required exceptions are already approved, and the named authority accepts the stated residual risk for the stated scope. Deployment still has stop conditions; approval is not a promise that production cannot surprise the team.
Approved with conditions permits deployment while named, non-blocking work remains. Each condition needs an owner, deadline, closure evidence, and a consequence if it slips. Evidence filing may be a condition. Untested tenant authorization, an inactive temporary control, unknown sensitive-data exposure, or no safe containment path is a blocker wearing the wrong label.
Blocked means the release must not proceed within the reviewed scope. State the missing fact or failed requirement and the evidence that would reopen the decision. Exception required means a known requirement cannot be met and may be eligible for separate risk acceptance. It grants no release permission. If the risk lies outside the acceptor’s authority, cannot be bounded, or lacks effective temporary controls and detection, the result is blocked rather than exception required.
Record changed decisions instead of overwriting them. A gate that moved from blocked to approved should show who closed the blocker, which new evidence justified the change, and when the authority changed.
Follow the export release through the gate
The dates and identifiers below are illustrative. The example continues the signed-envelope design and rotation exception from the preceding appendices.
# Release Security Review: EXPORT-2026-07 signed job envelopes
## Identity, scope, and authority
- Review ID and status: RSR-EXPORT-021; approved
- System and release: Customer Export Service; container digest
`sha256:<release-digest>` and worker configuration revision 184; production
- Assurance level: Level 2 because the internet-facing service processes
tenant customer data
- Accountable release owner: Customer Data Platform service owner
- Reviewers: Product Security and Export SRE
- Ship/block authority: Customer Data Platform director; rollback authority:
Export incident commander; exception authority: Customer Data Platform director
- Deployment window: 2026-07-18 09:00–10:00 UTC
- Related records: SADR-AUTHZ-EXPORT-003; TS-AUTHZ-EXPORT-002;
KEY-ROT-006; EXC-KEY-EXPORT-004
## Changed security behavior
- Export API now creates a short-lived, versioned, signed job envelope. Queue
workers verify its signature, issuer, tenant, export record, expiry, and job
ID before reading source data or writing an archive.
- The new boundary is the queue: possession of a message is insufficient
authority to export. Workers gain permission to verify envelopes but no
permission to sign them.
- Archive download authorization and retention policy are unchanged and were
regression-tested. The release does not add a new data class or public route.
- Worst credible release failure: a worker accepts forged, stale, replayed, or
cross-tenant work and creates an unauthorized archive.
- First containment: pause export creation and worker consumption, disable the
suspect signing version, and quarantine archives created during the affected
window. The prior worker version remains deployable only after queued envelope
compatibility is checked; queue pause is the safe fallback.
## Requirements and release evidence
### AUTHZ-TEN-002: tenant authority is checked at creation and execution
- Applies to every export. Failure can cross the book's central tenant boundary.
- Evidence: candidate digest tested in staging run `export-authz-882`; policy
review `PR-1842`; 2026-07-17.
- Result: same-tenant export passed; changed-tenant API request, changed-tenant
envelope, absent export record, and worker/data-store tenant mismatch all
failed before data read. Product Security reviewed the negative cases.
- Limitation: staging uses synthetic tenants and cannot prove production policy
propagation. State: satisfied, with a production canary below.
### JOB-ENV-005: workers accept only valid, live, unreplayed envelopes
- Evidence: candidate test report `envelope-verification-61`; malformed-property
suite; queue redelivery exercise; configuration revision 184.
- Result: unknown key version, altered claims, expired envelope, duplicate job
ID, unapproved issuer, and excessive lifetime were rejected and audited.
- Limitation: the production signing path still needs a no-data canary after
deployment. State: satisfied, with a stop condition below.
### LOG-AUD-004: release decisions and export actions are attributable
- Evidence: schema test `audit-contract-307`, staging trace `trace-771`, and
preserved alert payloads tie subject, tenant, export record, job ID, envelope
issuer, key version, worker, decision, and reason to one request path.
- Result: allowed and denied paths were queryable by job ID and tenant. State:
satisfied.
## Vulnerabilities, dependencies, and unresolved findings
### Candidate image and signing dependency review
- Candidate digest has no unresolved finding above the Level 2 release threshold.
Scanner report `image-991` and software inventory `sbom-991` identify the
exact digest and signature-verification library version.
- One medium-severity parser denial-of-service finding requires a validly signed
envelope and is bounded by envelope-size limits, queue admission policy, and
worker concurrency limits. Product Security accepted the disposition in
`RISK-218`; Runtime owner will update the library by 2026-08-01. New exploit
evidence or a bypass of the signing precondition invalidates the disposition.
## Exceptions carried into the release
### EXC-KEY-EXPORT-004
- KEY-ROT-006 automated rotation is absent; approval expires 2026-08-07 17:00
UTC and applies only to the export-envelope signing key.
- Required temporary controls are seven-day two-person manual rotation, narrow
signing authority, dual-key verification, access review, a telemetry canary,
and tested containment.
- Evidence: change `KEY-MANUAL-11`, policy export `IAM-EXPORT-44`, denied-use
test `IAM-NEG-19`, overlap and rollback run `KEY-EXERCISE-7`, and alert canary
`DET-CANARY-88`.
- Missed rotation, unexpected signing identity, failed canary, scope expansion,
or unexplained signature result revokes the exception and pauses exports.
## Blockers and conditions
### Signing-principal alert did not page the export on-call route
- Initial test `DET-CANARY-86` reached Product Security but not Export SRE. This
left the temporary custody control without its required operational response.
- Observability owner corrected the route and repeated the end-to-end test.
`DET-CANARY-88` shows both acknowledgements and is attached to the exception.
- Product Security closed the blocker at 2026-07-18 08:31 UTC.
### Archive the production canary trace
- Release owner must attach the query result and job trace to this review within
one hour of deployment. Missing evidence does not erase a successful stop-
condition check, but it blocks the next export release until closed.
## Decision history
- 2026-07-18 08:10 UTC — blocked by Product Security because the signing-
principal alert had no proven Export SRE route.
- 2026-07-18 08:38 UTC — approved with the canary-evidence archival condition
after Product Security verified `DET-CANARY-88`, every other requirement state,
and the active approval for EXC-KEY-EXPORT-004.
- Decision maker: Customer Data Platform director. The decision covers only the
named image digest, configuration revision, production environment, and
deployment window. A changed artifact or revoked exception requires review.
## Deployment and post-release proof
### No-data signed-envelope canary
- Create a canary export containing no customer records through the production
API. Confirm one signing event, one queue message, one successful verification,
and one attributable worker decision for the same job and tenant.
- Owner: release owner; observe before enabling ordinary export creation.
- Stop threshold: missing or inconsistent identity, tenant, export record, job
ID, issuer, key version, or decision; any unexpected signing principal; any
duplicate execution. On threshold, pause API and workers and preserve events.
### Negative envelope and alert canaries
- Submit the approved synthetic expired-version and duplicate-job probes. Both
must fail before data read and page Product Security and Export SRE through the
production route.
- Owner: Product Security; observe before ordinary traffic and again after one
hour. Any accepted probe or missing telemetry invokes the same pause.
### Early production watch
- For the first hour, Export SRE watches signature rejection by reason, signing
principal and version, envelope age, duplicate job IDs, tenant mismatch,
archive creation without a linked approved job, queue retry rate, and telemetry
freshness. A threshold breach pauses exports; it is not deferred to the next
business-day review.
## Closeout
- 2026-07-18 09:19 UTC — all canaries produced their expected allow or deny
decisions; both alert routes acknowledged; ordinary export creation enabled.
- Evidence archived under `RSR-EXPORT-021/production`; trace attachment condition
closed by Product Security at 09:42 UTC.
- EXC-KEY-EXPORT-004 remains an operating risk with weekly review. The release
review closes; the exception does not.
The first alert test did not become harmless because the release had other good evidence. It blocked the gate because detection and response were part of the temporary control that made manual rotation acceptable. Once the end-to-end route worked, the decision changed on the strength of new evidence, not a softer description of the same failure.
Production gets a vote
Pre-release evidence supports deployment into a bounded observation period. It cannot prove every property of production identity, policy propagation, routing, telemetry, or dependency behavior. That is why post-release checks need expected results and stop thresholds rather than the instruction to “monitor closely.”
Run the narrowest production probes that can distinguish a safe release from a dangerous one without placing real customer data at risk. Preserve the results with the same release identity. If a stop condition fires, contain first; do not let the existence of an approval turn a failed production assumption into an authorized state.
Close the review when the deployment outcome and evidence are recorded, conditions are resolved or transferred with explicit authority, and remaining operating risks have owners. An exception may outlive the review, as it does here. A release record should never make that temporary authority look permanent.