A supply chain attack in which a build system resolves a malicious public package instead of an intended internal one because of naming, versioning, or registry precedence. The risk is not only code substitution but automatic execution inside trusted pipelines that already contain valuable credentials.
Expanded Definition
Dependency confusion is a package resolution failure that turns naming and registry precedence into an attack path. In practice, a build tool may prefer a public package with the same name as an intended internal dependency, then pull that package into a trusted pipeline where it can run with access to secrets, signing keys, or deployment credentials. The term is closely related to supply chain compromise, but it is narrower because the exploit depends on how dependency resolution is configured rather than on direct tampering with source code. Guidance varies across vendors on whether this should be treated as a build-time security flaw, a registry governance issue, or a software supply chain control gap, and all three views are valid in different operating models. For practitioners, the core risk is that an internal package namespace is assumed to be private when the resolver is still willing to search public sources. NIST SP 800-53 Rev 5 Security and Privacy Controls helps frame the governance expectations around software integrity and system configuration. The most common misapplication is assuming a package name is “safe” because it exists internally, which occurs when public registry precedence is not explicitly constrained in CI/CD.
Examples and Use Cases
Implementing dependency resolution rigorously often introduces friction, requiring organisations to weigh developer convenience against stronger registry controls and repeatable builds.
- A CI pipeline installs LiteLLM PyPI package breach-style dependencies from a public registry because the internal package name is not pinned or mirrored.
- An internal library is published to a private registry, but the build tool searches public registries first, allowing a malicious lookalike package to be executed during installation.
- A release job uses broad environment variables and cached tokens, so a substituted package can exfiltrate secrets before the pipeline reaches artifact signing.
- Teams rely on NIST SP 800-53 Rev 5 Security and Privacy Controls-aligned baselines to force package allowlists, source pinning, and build integrity checks.
- Security teams mirror approved packages into an internal repository and block unnamed external resolution, reducing exposure in high-trust build systems.
Dependency confusion is especially relevant when a team has mature application security but weak dependency governance, because the exploit lives in the resolver, not in the application logic itself.
Why It Matters in NHI Security
Dependency confusion matters in NHI security because build systems often contain the very credentials attackers want: API keys, service account tokens, signing certificates, and automation secrets. When a malicious package is loaded into a trusted pipeline, the attack is no longer just code substitution. It becomes an NHI exposure event, because the pipeline may impersonate services, reach internal registries, or mint artifacts that other systems trust. NHI Mgmt Group reports that 96% of organisations store secrets outside of secrets managers in vulnerable locations, including code, config files, and CI/CD tools, which makes compromised builds far more consequential. This is why dependency confusion sits at the intersection of secret handling, privileged automation, and supply chain trust. The issue also maps cleanly to NIST guidance on access control and system integrity, and to operational lessons from incidents such as the LiteLLM PyPI package breach, where package trust became a path to credential exposure. Organisations typically encounter the blast radius only after a build artifact, token, or deployment credential is abused, at which point dependency confusion becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret exposure and package-driven credential compromise in build pipelines. |
| NIST CSF 2.0 | PR.DS-6 | Supports integrity protections for software and data moving through trusted delivery pipelines. |
| NIST SP 800-63 | Relevant where service accounts and automation credentials are impersonated or misused. | |
| NIST Zero Trust (SP 800-207) | Applies zero trust to registry access, build trust, and automated execution paths. | |
| CSA MAESTRO | Agentic and automated build workflows need controlled tool access and provenance checks. |
Constrain dependency sources and protect secrets so a malicious package cannot harvest them during builds.
Related resources from NHI Mgmt Group
- When does a dependency compromise become an identity incident?
- How should teams slow down malicious dependency updates without breaking delivery?
- What is the difference between automating dependency updates and granting them blind trust?
- Should organisations allow pull_request_target for automated dependency workflows?
