How should security teams prevent artifact poisoning in CI/CD pipelines when signing releases?

Why Artifact Poisoning Changes the Release Trust Model

Artifact poisoning is not just a build problem, it is a trust-boundary problem between what was produced and what was ultimately released. When signing is tied to a mutable tag, an attacker who can repoint that tag after build can cause the signature to cover the wrong payload. Pinning the digest before signing makes the release object explicit and stable.

The key practitioner question is whether the signed object is immutable from build to deployment. If the answer is no, the pipeline can still produce a valid signature over an artifact that is no longer the one reviewers or release automation think they approved. That is why digest-based verification matters at both ends of the flow, especially where registry state can change independently of the build record.

Signing the exact artifact also creates a cleaner audit trail. The release record should show one digest, one signature, and one verification step that resolves to the same object. Anything less leaves room for a repackaged binary, a retagged image, or an out-of-band registry mutation to slip through as a trusted release.

Controls That Make Signing Safe in CI/CD

Teams should treat the digest as the release identity and the tag as a convenience label only. The build stage should resolve and record the immutable digest, the signing stage should use that digest directly, and deployment should verify the same digest before promotion. This removes ambiguity and prevents the signature from becoming detached from the actual release payload.

That pattern works best when the pipeline preserves provenance, not just integrity. A signed digest is stronger when the system can also show where the artifact came from, which build produced it, and whether the registry lookup or promotion step re-resolved anything mutable. SLSA is useful here because it frames artifact provenance and verification as part of the release assurance model, not an afterthought.

Security teams should also ensure their repository and registry controls prevent late-stage mutation of signed material. If a registry, tag namespace, or release channel allows overwrite or retargeting, the signing process is only proving that something once existed, not that the deployed object is the same one that was reviewed. The release gate should fail closed when digest resolution does not match the signed reference.

For teams looking for a broader supply-chain reference point, NHIMG’s Ultimate Guide to NHIs is useful for understanding why long-lived credentials, CI/CD tool access, and poorly governed automation create conditions where pipeline state can be altered without clear ownership. The same operational discipline applies here, even when the immediate issue is artifact integrity rather than identity hygiene.

What Breaks First When Artifact Poisoning Succeeds

The first failure is usually not detection, it is trust confusion. Reviewers, scanners, and deployment automation may all believe they are operating on a vetted release while the actual artifact has been swapped after build. That creates a gap between approval and execution, which is exactly where an attacker with write access to the registry or tag space can act.

One common failure mechanism is signing a name instead of a content address. A tag can be repointed, a manifest can be replaced, or a registry lookup can resolve differently at deployment time than it did at build time. The result is a valid-looking signature attached to an object that was never the intended release candidate.

The impact is downstream integrity loss across the software supply chain. A poisoned artifact can introduce malicious code, configuration drift, or a backdoored dependency into production while still appearing to satisfy ordinary release checks. In practice, that means incident response may begin only after the wrong binary is already deployed and trusted.

NHIMG’s Reviewdog GitHub Action supply chain attack and CI/CD pipeline exploitation case study are relevant examples of how pipeline trust can fail when mutable automation or mismanaged build assets are allowed to persist past the point of approval.

Practitioner Guidance

What to verify: Verify that the digest signed by release automation is the same digest stored in the build record and the same digest referenced at deployment. If tags are still present for human convenience, treat them as non-authoritative metadata only.

Decision rule: If any stage can re-resolve the artifact by tag, rebuild the artifact reference as a digest before proceeding. If the deployment system cannot prove digest equality end to end, stop the release rather than compensating with manual approval.

Common mistake: Teams often harden the signing key and still leave the artifact reference mutable. That improves key protection but does not stop repointing, so the real control objective is immutable artifact selection plus digest verification.

Practitioner takeaway: Release signing is only meaningful when it binds to the exact bytes that will run, because integrity breaks the moment the signed reference can drift from the deployed object.

Related resources from NHI Mgmt Group

• How should security teams prevent CI/CD pipelines from treating build failures as successful releases?
• How should security teams implement SBOM signing in CI/CD pipelines?
• How should security teams prevent 403 errors in CI/CD pipelines?
• How should security teams prevent malicious Docker images from entering CI/CD pipelines?