A dependency confusion attack tricks software into installing a malicious package instead of the intended internal one. Attackers publish a public package with the same name as a private dependency, then exploit package resolution rules to capture code execution, exfiltrate secrets, or tamper with build and deployment pipelines.
How Dependency Confusion Works
dependency confusion exploits package managers that prefer a higher version from a public registry when an internal dependency name is reused. The attacker is not breaking the build system directly, they are abusing normal resolution behaviour to insert code where trusted software expected an internal package.
This attack is especially dangerous because package installation often happens inside CI/CD, developer workstations, and build automation, where the package can run with broad filesystem, network, and token access.
Why It Becomes a Supply Chain Problem
A dependency confusion event is a software supply chain issue, not just a package naming mistake. Once the wrong package is installed, it can alter build output, intercept secrets, poison artifacts, or create a foothold in downstream environments that trust the build pipeline.
The same pattern can also affect transitive dependencies and internal package mirrors, especially when organisations mix public and private registries without strict namespace controls or explicit source pinning. NHIMG’s Software Supply Chain Security Guide covers the broader controls that reduce this class of abuse.
How Teams Check Exposure
Exposure is usually found by reviewing package naming, registry precedence, and where private packages are published or resolved from. Teams should inventory internal package names, identify whether those names are already visible in public ecosystems, and check whether build systems can reach public registries during normal installs.
It also helps to review repository configuration, lockfiles, and package manager behaviour across languages, because the risky condition is often inconsistent resolution policy rather than a single vulnerable application. The Open Source Security Guide is a useful companion for pinning, provenance, and dependency hygiene.
Prevention, Detection, and Recovery
Prevention relies on making package origin explicit, reducing reliance on ambiguous names, and refusing to trust a public package simply because it matches an internal identifier. Build systems should prefer internal registries, require provenance where possible, and block unexpected package-source switches.
Detection should focus on unusual package publication, unexpected outbound connections during installs, new postinstall activity, and secrets that appear in logs, artifacts, or network telemetry. After a confirmed incident, assume any tokens, keys, or sessions accessible to the build or developer environment may have been exposed and review downstream artifacts for tampering.
NHIMG’s Malicious Package and Dependency Confusion Guide and Top 10 CI/CD Security Risks are the most direct internal references for incident patterns and pipeline controls.
Risk and Threat Considerations
Dependency confusion matters because it turns a naming collision into code execution inside trusted delivery environments. The usual consequence is not just one bad install, but secret exposure, build compromise, and the possibility that poisoned artifacts move further than the original workstation or pipeline.
Failure mechanism: An attacker publishes a public package that out-ranks or shadows a private one, then waits for automation or developers to install it under ordinary dependency resolution rules.
Impact: The malicious package can run install-time code, steal credentials or tokens, tamper with build outputs, and create downstream trust in compromised artifacts.
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 addresses the attack and risk surface, while SLSA, CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply chain integrity | Dependency confusion is a software supply chain integrity failure. |
| Recommendation — Harden package provenance and source control to prevent shadowed dependencies from entering builds. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | This attack exploits dependency handling in software delivery and build processes. |
| Recommendation — Apply secure software development controls to govern dependency sourcing and build-time execution. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | Malicious package substitution undermines integrity of software acquired and executed. |
| Recommendation — Verify software provenance and integrity before allowing dependencies into build pipelines. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Dependency resolution and package trust are architecture concerns in application security. |
| Recommendation — Design dependency sourcing so untrusted packages cannot transparently replace intended ones. | ||
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Third-party package abuse can expose secret-bearing automation and trust relationships. |
| Recommendation — Audit third-party package trust paths and limit secrets reachable during dependency installation. | ||
Practitioner Guidance
Governance implication: Treat dependency naming and registry policy as security controls, not just developer convenience. Ownership should be clear for internal package names, approved registries, and any exception that allows public resolution in build paths.
Common misunderstanding: Many teams assume private packages are safe because they are not published publicly. In practice, the risk appears when package managers can still reach a public registry and resolve a higher version of the same name.
Practitioner takeaway: If a build can install from both internal and public sources, the package namespace itself becomes part of the attack surface.
Related resources from NHI Mgmt Group
- Who should own containment when a dependency attack exposes cloud and repository credentials?
- What breaks when dependency confusion is allowed in CI/CD pipelines?
- Why do package hallucinations and dependency confusion increase supply chain risk?
- Why do squatting and dependency confusion matter for IAM teams?