What should a security release decision rest on?

Green pipelines are not a decision

Ask most teams what supports their decision to ship and the answer is a pipeline state: the tests passed, the scanners reported nothing above threshold, the review was approved. That is a statement about the checks that ran. It is not a statement about whether the product is ready to be exposed to the internet, and the two are easy to confuse because one is available and the other requires judgement.

The gap shows up after an incident. A team is asked what was known at the time of release, and the honest answer turns out to be that nobody assembled it. There were findings in three tools, an override on one gate, an open item from a penetration test, and a decision made in a chat thread by whoever was available. Individually each was reasonable. Collectively nobody saw them.

A security release decision is the artefact that closes that gap. It has four parts: what was tested, what is known to be wrong, who decided to proceed, and what would change the answer.

State the scope that was tested

The most common defect in release evidence is an implied claim of coverage that nobody made. A report titled “security testing complete” invites the reader to assume the product was tested, when what happened was that a defined subset was examined by defined methods.

Write the scope positively and negatively:

• What was examined: which services, which interfaces, which roles, which environments, at which revision.
• By what methods: automated tests in the pipeline, static and dependency analysis, targeted manual testing, dynamic scanning, code review, and for each, what it is capable of finding.
• What was not examined: components out of scope, an integration that was unavailable in the test environment, an authorisation path that could not be exercised because the test data did not support it.

The exclusions carry most of the information value. “The partner integration was not tested because the sandbox was unavailable” is precisely the sentence that makes a good decision possible, and it is the sentence that disappears from summaries.

Where the product is assessed against a published standard, name the level. The OWASP verification standard is useful here because its levels are explicit about depth—saying which level was applied is a much stronger claim than saying the standard was used.

List what is known to be wrong

Every release ships with known open issues. Pretending otherwise produces a record that nobody believes and that is useless for an investigation.

For each open item, four fields are enough: what it is, what an attacker would need in order to exploit it, what mitigates it in the current deployment, and who owns the fix with a date. Rank by the adjusted severity rather than the base score—CVSS 4.0 separates base metrics from threat and environmental modifiers precisely so the number in your record reflects your deployment rather than the abstract flaw.

Compensating controls belong in the list and should be specific. “Monitored” is not a compensating control; “requests to this endpoint are rate-limited to ten per minute per account and an alert fires to the on-call rota above that” is. The difference matters because the compensating control is what the decision is actually relying on.

Include the overrides. A gate that was bypassed to make the release is part of the known-issue list, with the authoriser and the expiry. If it is not in the record, the record is describing a different release from the one that shipped.

Say what the decision is and who made it

The decision is a sentence, and it should name a person. “Approved for general availability by the product owner, accepting items 3 and 7 for the stated period” is a decision. “Sign-off obtained” is a status.

Two roles need separating. Whoever produced the evidence states what is known and what is not; they should not also be the party who accepts the risk, because that collapses advice and accountability into one signature. Whoever accepts is accountable for the consequence—which means they must have the authority to delay the release, or the acceptance is nominal.

The scope of the decision matters too. Approving a canary to five per cent of traffic with an automatic rollback is a different decision from approving general availability, and recording which one was made prevents a limited approval being cited later as a full one.

The SSDF places this in its practice of archiving and protecting each software release, along with the evidence of the practices applied to it. The archival part is the one that repays itself: the value of the record is realised months later, by someone reconstructing what was understood at the time.

Record the conditions that would reverse it

An approval given at a point in time is valid for the conditions that existed then. Naming what would invalidate it turns a static approval into something operable.

Useful reversal conditions are concrete: exploitation observed against an accepted item; a compensating control failing or being removed; the deployment changing so that a reachability condition in the accepted item becomes true; an accepted item passing its agreed date without a fix; or a new advisory affecting a component in the same path.

This also gives the on-call team something actionable. Without it, an operator who sees unusual traffic against a known-weak endpoint has to reconstruct whether it matters. With it, the relationship between the accepted risk and the signal that would change the decision is already written down.

What obligations add to the record

For products in scope of the EU Cyber Resilience Act and comparable regimes, the release record acquires additional required content: the component inventory, the vulnerability handling process that applies, and the support period during which updates will be provided.

Two of these are worth building into the release rather than producing separately. A bill of materials generated by the build, with verifiable provenance for the artefact, satisfies the inventory question and is independently useful during an advisory response; SLSA provides the vocabulary for the provenance half. The support period is a statement about the future, and its engineering cost is the reproducibility and test capability needed to ship a fix to that branch later.

The general principle is to derive the obligation document from the engineering record rather than maintaining both. Two sources of truth about what shipped will diverge, and the one that diverges is always the one written for an external audience.

Keep the pack small enough to read

A release record that nobody reads before the decision has failed at its only job. One page is a reasonable target: scope in and out, open issues with owners and mitigations, overrides, the decision and its scope, and the reversal conditions. Detail lives behind links.

The test is whether the accountable owner can read it in five minutes and answer a straightforward question afterwards: what are we shipping with, and what would make us change our mind? If they cannot, the pack is documentation rather than decision support—and the release is being made on the strength of a green pipeline after all.