Release Security Review and Production Readiness

A release candidate for the invoice-correction service is due on Thursday. Manual testing found that the legacy bulk route could alter a settled invoice. The team moved the state check to the authoritative write, carried the initiating actor through the worker, and replayed the exploit successfully: the correction is now denied. One defect remains. Denial events from the bulk route reach the security stream, but a dashboard parser drops the entry-point field, so responders cannot distinguish bulk attempts from ordinary API denials.

Can this release ship?

A scanner cannot answer. Neither can a vote among people in the launch meeting. The answer depends on whether the remaining uncertainty is tolerable, whether the system can contain failure, and whether someone with the right authority is willing to own the residual risk. Release review is where those facts become a recorded production decision.

Review the release that will actually run

The review record starts with an identity, not a collection of reassuring links. For this release it names the invoice service, production environment, source commit, immutable image digest, database migration, policy bundle version, feature flags, and intended tenant cohort. Every test result and approval must resolve to that identity. A passing scan against yesterday’s image proves nothing about today’s candidate.

Then the reviewers reconstruct what changed. The architecture review shows that all invoice transitions now converge on one write boundary. The threat model still treats tenant crossing, settled-state mutation, replay, and lost actor context as the consequential paths. The open-risk register contains the dashboard parser defect and no expired exceptions. Automated results cover the candidate digest; the manual report identifies the original exploit, root cause, repair, and retest evidence.

Production readiness supplies facts that security tests cannot. The service and security-event stream have named on-call owners. Dashboards and alerts point at the new version. The rollout can stop at one tenant cohort, and the bulk route can be disabled without reverting the whole service. The database change is backward compatible, the last restore exercise met its recovery objective, and the rollback procedure preserves invoices created after deployment. Incident readiness names the person who can halt rollout, the investigation query, the evidence-preservation location, and the communication path if financial state is affected.

These are not documents to create on the eve of launch. They are the accumulated state of design, threat modeling, risk ownership, testing, vulnerability management, operations, backup and restore, and incident preparation. A review may be brief because the evidence is ready. It may not be brief because the evidence is absent.

Decide blockers before the deadline decides for you

The invoice authorization bypass was a blocker. It was exploitable through a reachable production path and violated a protected state transition. A feature flag or promise to watch the logs could reduce exposure, but neither could make an unauthorized write safe. The release stayed closed until the authoritative boundary rejected the operation and the original path had been retested against the candidate.

The same treatment belongs to a small set of conditions that remove the team’s ability to control production risk:

• a critical exploitable vulnerability on a reachable path;
• missing authentication or authorization for a protected action;
• sensitive-data collection, retention, sharing, encryption, or deletion that has not been reviewed;
• a public interface with no accountable operational owner;
• a critical state change with no credible rollback, disablement, or recovery path;
• sensitive actions that produce no usable security evidence;
• a valid leaked secret in source, build output, artifact, or deployment configuration;
• an expired or unauthorized exception.

A blocker is a property of the release, not a punishment for its team. Labeling a critical finding “accepted” does not restore authorization, observability, ownership, or recovery. If a supposed compensating control cannot interrupt the attack path or contain its consequence, it is not compensation.

Blocker policy must also say who can resolve each outcome. Engineering and security owners may certify that a defect is repaired and evidence is complete. A designated business or service risk owner may accept bounded residual risk within a written delegation. The release manager may enforce the gate and stop rollout. None of those roles may silently assume another’s authority. For severe or cross-business exposure, the organization’s policy may require an executive, data owner, or other named authority. The meeting’s most senior attendee is not automatically the risk acceptor.

Bound a conditional approval

The dashboard parser defect is different from the bypass. The underlying denial event contains the actor, tenant, invoice, decision, request identifier, worker job, deployed version, and original entry point. The field is retained in the security store and can be queried directly; only one dashboard view drops it. The bulk route will open first to two internal tenants, an analyst owns a saved query against the source events, and absence of the expected field in any sampled event stops rollout. The parser fix is scheduled for the next day.

That can be a conditional approval if the authorized risk owner records all of the following:

• the exact unmet requirement and the production consequence;
• the systems, version, users, data, and time period covered;
• the control that narrows exposure and the evidence that it works;
• the metric or event to watch, its owner, and the threshold that stops rollout;
• the remediation owner and due date;
• the person with authority to escalate, revoke approval, or extend it;
• the expiration time, after which the release is blocked unless re-evaluated.

“Fix after launch” is not a condition. It has no boundary and no forcing function. Nor may conditional approval stand in for a fundamental control: absent authorization, absent sensitive-action evidence, an unowned public service, an uncontained critical change, or an exploit path whose repair has not been demonstrated.

Make the decision from an index

The release record should let a reviewer move from a decision to its proof without searching chat history. For the invoice candidate, the evidence-package index contains:

• the approved architecture and data-flow diagrams, with the changed trust and state boundaries identified;
• the current threat model and residual-risk register;
• automated and manual security results tied to the commit and image digest;
• open-vulnerability triage, including reachability, severity, owners, and exception records;
• the rollout, rollback, and recovery plan, plus the latest relevant restore result;
• dashboards, alert queries, on-call ownership, incident playbook, and evidence-preservation instructions;
• the signed release decision and conditional-approval record;
• after deployment, the environment, artifact digest, policy version, actor, time, cohort, and outcome of each rollout step.

The index is a map, not a duplicate archive. Each entry names the artifact, owner, system of record, version or time range, sensitivity, and retention expectation. If a mutable dashboard is the evidence, preserve the underlying query or result needed to reconstruct the decision. Chapter 35 develops that evidence discipline beyond a single release.

The production-readiness record beside the index answers concrete operating questions. Who owns the service now? Which new interfaces and permissions exist? Which telemetry proves the sensitive path? What alert summons a responder? What capacity or dependency limit can force a pause? How is the change disabled, rolled back, or recovered without losing newer state? When was that path last exercised? Who leads an incident, and where will facts and customer impact be recorded? A blank answer is unresolved risk, not clerical incompleteness.

Record one of four decisions

The review ends with approved, approved with conditions, blocked, or exception required. The record names the candidate, scope, evidence index, open risks, decision makers, risk acceptor, conditions, expiration, and post-release plan. “Green” without those facts is only a color.

The invoice candidate is approved with conditions. The service owner approves operational readiness. Security confirms that the repaired invariant and original exploit were retested. The delegated risk owner accepts the temporary dashboard limitation for the bounded cohort until the stated expiry. The release manager is authorized to deploy only while the source-event query remains usable and to stop on the first failed production check. If the parser is not repaired before expiry, wider rollout is blocked; the old decision does not renew itself.

Review depth should follow consequence. A low-risk documentation or internal configuration change may inherit standing controls and automated evidence. A change to authority, sensitive data, public exposure, cryptographic behavior, recovery, or a critical dependency deserves a fresh decision. Scaling the review is sensible. Scaling away the blocker policy is not.

Test the promise in production

Deployment success says that an artifact started. It does not say that the approved security behavior survived production configuration, identity, routing, or telemetry.

For each invoice rollout cohort, the release owner performs the post-release checks named before approval:

1. Confirm the environment is running the approved image, policy bundle, migration, and feature-flag state.
2. Exercise an authorized draft correction and the safe denial of a settled correction through both interactive and bulk paths.
3. Follow each request through the event stream. Confirm the actor, tenant, invoice, entry point, decision, reason, request identifier, job, and version are attributable without exposing invoice contents.
4. Scan the intended exposure: routes, ports, storage, administration surfaces, and dashboards must match the reviewed architecture.
5. Inspect newly created roles, service accounts, tokens, and grants against the least-privilege design.
6. Trigger or safely simulate the expected alert and confirm that the named owner receives enough context to act.
7. Reconfirm that the bulk route can be disabled and that rollback or recovery remains immediately executable.

Each check has an owner, deadline, evidence link, and stop condition. A failed authorization check stops the release. Missing source events stop it. A dashboard parsing failure invokes the approved source-query workaround; failure of that query stops it. Unexpected exposure or privilege stops it until understood. The release manager records whether the cohort advanced, paused, rolled back, or invoked incident response.

The useful end state is modest and exact. The known exploit fails at the authoritative boundary. The released artifact is the one that was reviewed. Responders can see and attribute the consequential behavior. Exposure and authority match the design. Recovery remains credible. The one accepted limitation is bounded, watched, owned, and expiring.

Release review has not made production safe in the abstract. It has made a particular risk decision inspectable—and has preserved the ability to change that decision when production answers back.