What breaks when CI/CD security is only checked at release time?

Where release-time-only CI/CD checks fail

Checking only the final release artifact assumes the dangerous work happens last, but pipeline abuse usually happens earlier. If commits, dependencies, build scripts, or runner state are altered upstream, the release gate can still pass a package that already contains the compromise. The control is verifying delivery, not the trustworthiness of everything that produced it.

That is why release-only review misses the difference between what was shipped and how it was assembled. A malicious change can be introduced in source control, hidden in a dependency, or injected through a workflow step, then carried forward into a signed release. Once that happens, the artifact may look legitimate even though its provenance is not.

In practice, the missing control is provenance assurance. Build integrity depends on checking the inputs that feed the pipeline, not just the output it emits, which is the core idea behind SLSA. If you cannot explain which commit, dependency set, and build environment produced the artifact, a release-time check is too late to establish trust.

What attack paths stay invisible until after release

The main blind spot is poisoning before the final packaging step. Attackers do not need to wait for release approval if they can alter a dependency, swap a workflow action, abuse a token, or tamper with the build environment. The end result is the same: a signed or published artifact that carries attacker-controlled content while still appearing to come from a normal pipeline.

Release-only controls also struggle with persistence across successive builds. If the compromise lives in a reusable action, cached dependency, poisoned branch, or long-lived secret, every later build can repeat the same failure mode until someone investigates upstream state. That is why pipeline security has to cover the whole chain, not a single promotion point. Cases such as the tj-actions/changed-files compromise 2025 and reviewdog Action compromise 2025 show how pipeline trust can be undermined before release validation ever runs.

That same failure pattern is why build compromise is so dangerous: once an attacker reaches the pipeline, they can convert ordinary automation into a delivery mechanism. The compromise may be visible only in retrospect, after secrets are exposed, artifacts are poisoned, or downstream systems consume a tainted package. The release gate then becomes a false reassurance rather than a meaningful trust decision.

What good CI/CD security checks earlier

Effective CI/CD security validates the material that shapes the release, not just the release itself. That means commit integrity, dependency integrity, workflow integrity, and build-environment integrity all need controls before packaging and signing occur. If those checks are absent, the final approval step becomes a quality check on the attacker’s output.

Practitioners should treat provenance, signing, and attestation as layered controls, not a substitute for source and build review. A trusted signature only has value when the signer, inputs, and pipeline state were already constrained. If the build can be influenced by unpinned actions, mutable dependencies, or exposed secrets, the signature may attest to a compromised process as easily as to a clean one.

For release engineering, the practical test is simple: can you prove the artifact came from known inputs in a known environment, with no privileged mutation along the way? If not, you have release integrity, but not supply-chain integrity. That is the boundary the control should be designed to enforce.

Risk and Threat Considerations

Release-time-only checking creates a deceptive sense of safety because the final artifact can still be malicious even when the release gate succeeds. The risk is not just undetected tampering, but the possibility that the pipeline itself becomes the delivery path for code, secrets, or signing material that should never have reached release.

Failure mechanism: An attacker or faulty dependency alters source, workflow logic, build inputs, or runner state earlier in the pipeline, then the release step signs or publishes the already-compromised artifact.

Impact: Teams may ship trusted-looking builds with hidden backdoors, exposed secrets, or corrupted provenance, forcing rotation, rebuilds, and downstream trust recovery after distribution has already occurred.

Practitioner Guidance

What to verify: Verify commit integrity, dependency pinning, workflow immutability, and runner trust before the artifact is produced. If those inputs are not controlled, do not treat release approval as a security checkpoint.

Decision rule: If the control only inspects the final artifact, treat it as a release governance control, not a CI/CD security control. Security review belongs at the points where code, dependencies, and build parameters can still be changed.

Common mistake: Teams often add signature verification at the end and assume the pipeline is now trustworthy. In reality, signing can legitimize a poisoned build unless the upstream build path is already constrained.

Practitioner takeaway: The real question is not whether the release passed review, but whether every material input to that release was already trustworthy before packaging and signing began.

Related resources from NHI Mgmt Group

• What breaks when medical device security is only checked after release?
• What breaks when CI/CD security relies only on artifact scanning?
• What breaks when API security is not built into CI/CD pipelines?
• What breaks when security scanning sits outside the CI/CD workflow?