What breaks when dependency confusion is allowed in CI/CD pipelines?

Why This Matters for Security Teams

Dependency confusion breaks the trust boundary that CI/CD assumes during package resolution. When a pipeline can be tricked into pulling a public package name instead of an internal one, the install step becomes an execution point for untrusted code with the runner’s network access, cloud tokens, and repository secrets. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls is clear on protecting software and privileges, but dependency resolution adds a supply chain path that many teams still under-model.

NHIMG research on the CI/CD pipeline exploitation case study shows how quickly attacker-controlled packages can convert routine automation into secret exposure. The issue is not just malware in the build. It is that pipeline identities often over-privilege install jobs, making them attractive targets for token theft, artifact tampering, and lateral movement into registries and deployment systems. In practice, many security teams encounter the impact only after a package typo or namespace collision has already exposed credentials, rather than through intentional dependency review.

How It Works in Practice

In a healthy pipeline, internal dependencies should resolve predictably from approved sources. Dependency confusion disrupts that assumption by exploiting package name precedence and registry search behavior. If a build runner is allowed to query public registries, an attacker can publish a package with the same name as a private module and wait for the pipeline to install it. Once installed, the malicious package executes in the build context and can read environment variables, cached tokens, config files, or ephemeral cloud credentials.

The real failure mode is identity exposure. CI/CD runners often hold more privilege than a developer workstation because they need access to package registries, artifact stores, test environments, and signing keys. When a runner installs the wrong package, the code executes as the pipeline identity, not as a sandboxed guest. That is why controls need to focus on provenance, isolation, and runtime authorization, not just malware scanning after the fact.

• Pin dependency sources to approved internal registries and disable fallback to public indexes where possible.
• Use workload identity for runners and short-lived tokens instead of long-lived static secrets.
• Separate install, test, and publish jobs so a compromised install step cannot sign or deploy artifacts.
• Apply allowlists for package namespaces, mirrors, and artifact provenance checks.

Current guidance suggests combining registry controls with secrets minimization and build-time isolation, which aligns with NHIMG analysis in the Guide to the Secret Sprawl Challenge and the Reviewdog GitHub Action supply chain attack. These controls tend to break down when pipelines inherit broad cloud roles and can reach public registries from the same network path used for privileged internal installs.

Common Variations and Edge Cases

Tighter dependency controls often increase build maintenance and release friction, requiring organisations to balance developer speed against supply chain assurance. There is no universal standard for this yet, especially across polyglot repos and mixed public-private package ecosystems. Some teams can fully namespace internal packages; others must rely on artifact proxies, signature verification, and human review for exceptional cases.

Edge cases matter when package managers support multiple sources, when legacy builds cannot disable public resolution cleanly, or when mirrored registries lag behind upstream releases. A package may also be benign at first but later become hostile after a maintainer transfer or dependency takeover. For that reason, dependency confusion should be treated as a control failure that reaches beyond source code hygiene into CI/CD identity governance, secrets handling, and runtime isolation. In mature environments, the question is not whether a malicious package can run, but whether it can see anything valuable once it does.

Related resources from NHI Mgmt Group

• Why do CI/CD pipelines make secret theft easier for attackers?
• What breaks when CI/CD pipelines rely on static secrets?
• What breaks when CI/CD pipelines rely on static YAML alone?
• What breaks when CI/CD pipelines can list tables with long-lived credentials?