Why do CI/CD pipelines create special risk for malicious code propagation?

How CI/CD pipelines turn one compromise into many

CI/CD pipelines are not risky because they execute code. They are risky because they are designed to trust code, credentials and automation long enough to build, test, package and publish software. Once that trust is abused, the pipeline can become a high-speed propagation channel, turning a single malicious change into a distributed compromise across artifacts, environments and downstream consumers.

The key issue is transitive trust. A pipeline often has access to source repositories, signing material, package registries, deployment targets and cloud credentials, so a malicious payload does not need to stay local to the build job. It can inherit the pipeline's authority and be pushed out as if it were legitimate software.

That is why supply-chain integrity matters as much as runtime hardening. Controls such as provenance, isolated runners, pinned dependencies and restricted publishing paths exist to stop the build system from becoming an amplifier for attacker-controlled content. SLSA is useful here because it frames the problem as build provenance and artifact integrity, not just code execution.

Why malicious code can survive the build process

A malicious dependency, tampered action, poisoned package or injected script can look ordinary at the point where the pipeline consumes it. The danger is that CI jobs are often granted more trust than developer laptops or application runtime containers, because they must fetch secrets, sign outputs or publish artifacts automatically.

If that trust boundary is weak, the code does not need to “break out” in the classic malware sense. It only needs to run during a privileged step, where it can read environment variables, access tokens, alter release content, or modify the next stage of delivery. In practice, the pipeline itself becomes the execution environment for propagation.

For teams using external actions, reusable workflows or third-party build helpers, the trust chain extends beyond the repository. That makes dependency hygiene, commit pinning and vendor review part of pipeline security, not optional hygiene. NHIMG's CI/CD Pipeline Identity Security Guide is a useful companion for understanding how token scope, OIDC federation and trusted publishing change the blast radius of a compromised job.

What makes propagation especially dangerous at scale

Propagation is what separates a local code compromise from a supply-chain event. A successful injection can produce artifacts that are then consumed by multiple teams, environments or customers, and each downstream system tends to treat the output as trusted because it came from the official pipeline.

That trust can also persist after the original malicious code is gone. Signed packages, cached layers, stored artifacts and mirrored registries can keep distributing a compromised build until the release chain is cleaned up. This is why incident response for CI/CD often focuses on artifact recall, token rotation and rebuilds, not just source-code cleanup.

NHIMG has repeatedly documented this pattern in real incidents, including token theft, poisoned workflows and secret exposure. Cases such as ArtiPACKED 2024 show how build outputs can leak live tokens, while tj-actions/changed-files compromise 2025 shows how a compromised action can expose secrets at scale. For a broader propagation view, Megalodon GitHub Actions attack 2026 is a strong example of how one poisoned workflow can spread across thousands of repositories.

Risk and Threat Considerations

CI/CD compromise is especially valuable to attackers because it gives them a trusted distribution path, not just a foothold. The attacker can steal signing credentials, alter release artifacts, harvest secrets from logs or environment variables, and then use the legitimate delivery process to spread malware or backdoors to many targets at once.

Failure mechanism: A malicious dependency, workflow change or runner compromise executes inside a privileged build step, captures credentials or alters artifacts, and then uses trusted publishing to move the payload into downstream systems.

Impact: The result can include secret theft, unauthorized releases, compromised signed artifacts, widespread customer exposure and a long-lived trust break that is expensive to unwind.

Practitioner Guidance

What to prioritise: Protect the publishing path first, because that is where build compromise becomes propagation. Limit which jobs can sign, publish or access long-lived credentials, and treat any runner that can reach production secrets as part of the high-value trust boundary.

What to verify: Confirm that builds are reproducible enough to investigate, that dependencies are pinned to known-good revisions, and that secrets are not broadly available to jobs that only need to compile or test. If the build can access production trust material, assume a malicious step can abuse it until proven otherwise.

Practitioner takeaway: The security question is not whether a pipeline can execute untrusted code, but whether that code can inherit authority and leave the pipeline carrying trust outward.

Related resources from NHI Mgmt Group

• Why do source code changes create such a high security risk in CI/CD pipelines?
• Why do unexpected code executions in CI/CD pipelines create such a high supply chain risk?
• Why do CI/CD pipelines create special NHI governance problems?
• Why do CI/CD pipelines create non-human identity risk?