What signals show that CI/CD automation has been poisoned?

How poisoned CI/CD looks in the execution chain

Poisoning usually shows up when the release path still “works” but the trust chain no longer matches the expected source of truth. The strongest clue is divergence: the tag, commit, workflow, artifact, or release asset now points to code or metadata that does not line up with prior history. That is why forced tag movement, history gaps, and unexpected asset creation matter together rather than as isolated anomalies.

In practice, the signal is not just “something changed.” It is that a release identity has been reused or rewritten, while execution identity has shifted underneath it. A workflow that still claims the same release label but runs different code is especially suspicious because it can preserve the outward appearance of a normal build while quietly changing what is actually shipped.

False positives do happen during emergency fixes, release retags, or repository migration. The difference is whether the change has an obvious, approved change path and whether the resulting commit graph and workflow provenance remain internally consistent. If the chain cannot be reconciled cleanly, treat it as a compromise indicator, not a routine delivery issue.

What changed artifacts and history tell you

Unsigned commits where signed ones were expected often indicate that the attacker is trying to bypass the normal trust signal rather than replace the whole pipeline. Impossible parent-child commit history, rewritten tags, or a release asset that appears without a corresponding, approved build event are all forms of provenance drift. They suggest the release was either injected, repointed, or produced outside the intended control plane.

That matters because CI/CD poisoning rarely begins with a dramatic failure. More often, the pipeline remains operational while the attacker alters a dependency, action, build step, or publishing path just enough to inherit trust from an existing project. The result can be secret theft, malicious artifact publication, or the silent replacement of code that downstream users assume is legitimate.

When a tag points to one commit in the repository UI but the workflow run or published artifact reflects another, the issue is not cosmetic. It is evidence that the release process no longer provides a reliable link between source, build, and distribution. At that point, the build record itself becomes part of the incident evidence.

Why release and execution identity diverge

Poisoned automation usually exploits the gap between what developers think is being executed and what the runner or publishing step actually consumes. That gap can be created by compromised credentials, a malicious workflow change, an injected release asset, or a tampered dependency that alters the build output without obvious source changes. The common feature is that the control you trust is no longer the control that ran.

Supply-chain abuse becomes easier when release processes reuse long-lived tokens, accept mutable references, or allow broad publishing rights. In that environment, the attacker does not need to break every layer. They only need one trusted path that can still sign, tag, upload, or dispatch under the project’s name. The poison is effective because it borrows legitimacy from the pipeline’s own automation.

For teams that want a deeper treatment of build provenance and release integrity, SLSA is the right external reference point. It frames why provenance, reproducibility, and verifiable build inputs are central to detecting this class of abuse.

Risk and Threat Considerations

Poisoned CI/CD is high-impact because it can turn a routine release into a trusted distribution channel for malicious code, stolen secrets, or altered artifacts. The danger is amplified when the attacker preserves the outward release name or tag, because downstream consumers may continue to trust the artifact while the underlying code path has already been subverted.

Failure mechanism: An attacker rewrites a trusted reference, compromises a workflow or publishing credential, or swaps the code behind a release label so the visible release identity no longer matches the actual execution identity.

Impact: Teams may ship tampered artifacts, leak signing or cloud credentials, and lose confidence in the integrity of build and release records until the entire provenance chain is rebuilt and verified.

Practitioner Guidance

What to verify: Confirm that tags are immutable or protected, that signed commits remain signed at release time, and that the workflow run producing the artifact can be traced to the same source revision you expect. If any one of those checks fails, treat the release as suspect even if the pipeline completed successfully.

What good looks like: The repository history, release metadata, workflow run, and published artifact should form one consistent chain. If the chain requires manual explanation to make sense, the automation is already giving you weaker assurance than you probably think it is.

Practitioner takeaway: The key question is not whether CI/CD still runs, but whether the release it produces is still attributable to a verifiable source and build path. Once those identities split, the pipeline may be functioning operationally while being untrustworthy security-wise.

Related resources from NHI Mgmt Group

• What is the main risk when automation systems store ServiceNow credentials?
• How should teams respond when CI or developer secrets are exposed?
• When does CI/CD automation create more risk than it reduces?
• Who should own credentials used by CI/CD policy automation?