How should teams stop CI from accepting unverified green runs?

Why a green status is not enough

A green pipeline badge only says a job reported success. It does not prove which code, inputs, runner, dependencies, secrets or environment produced that result, so a forged replay or altered execution record can look legitimate. Teams need the release decision to depend on evidence that binds the result to the exact run, not on the visual status alone.

That distinction matters because CI output is easy to replay, tamper with or separate from its original context. If the gate trusts status alone, an attacker or an unreliable automation path can substitute a stale or manipulated success signal for the real execution evidence.

What the release gate should verify

The control objective is to make the green run verifiable, not merely visible. A trustworthy gate checks that the attestation or execution record is signed, that it names the exact commit or artifact under test, and that the recorded environment matches the run that produced the result.

Just as important, the verification should be detached from whatever the CI system displays in the UI. The gate should read the evidence, confirm integrity and reject runs that cannot be cryptographically linked to the checks that actually executed. That prevents a badge, log snippet or rerun from being accepted as proof on its own.

Teams should also treat the verification policy as part of release provenance, not as a last-minute checkbox. The gate is only effective when it checks the full chain, from inputs and runner identity through to the signed result that a downstream release process consumes.

Why this fails in practice and how to harden it

Unverified green runs fail when the pipeline separates status from provenance. Common failure modes include rerunning a job on a different environment, copying a successful log, accepting a badge after partial re-execution, or allowing mutable inputs to change after the checks completed. In each case the badge survives while the evidence trail does not.

Hardening means narrowing what can count as success. The release gate should require immutable inputs, signed execution evidence and a clear match between the claimed result and the recorded run context. Where reruns are allowed, the rerun itself must be separately attested and evaluated as a new event, not treated as the same green result.

Risk and Threat Considerations

When CI accepts an unverified green run, it creates a trust gap between observed success and actual execution. That gap can let manipulated artifacts, changed inputs or substituted logs pass the release gate, which turns pipeline convenience into a supply-chain exposure.

Failure mechanism: The pipeline relies on a mutable status signal instead of verifying signed evidence for the exact run, so a replayed, tampered or stale result can be mistaken for a genuine pass.

Impact: Malicious or invalid code can move forward as if it were tested successfully, weakening release integrity and increasing the chance that bad artifacts reach production.

Practitioner Guidance

What to verify: Treat the attestation as the control point, not the badge. Verify that the evidence binds the commit, artifact, checks and environment together, and reject any green run that cannot prove that linkage.

Decision rule: If the system cannot prove what actually executed, fail closed and require a fresh, signed run instead of trusting the latest visible success signal. If the evidence is present but does not match the release candidate exactly, treat it as irrelevant.

Practitioner takeaway: The right standard is not “did CI go green?”, but “can we prove this exact green result came from the exact code and environment we are about to release?”

Related resources from NHI Mgmt Group

• How should security teams stop malicious CI/CD workflow commits from executing?
• What breaks when CI/CD pipelines execute unverified artifacts or scripts from external sources?
• How should security teams implement CI/CD security gates so they stop risky code before deployment?
• Why do CI/CD secrets become so dangerous when a workflow runs untrusted code with elevated permissions?