Why does dependency confusion create a risk for developer workstations and build infrastructure?

Dependency confusion works because package managers may resolve a public package over an internal one when names overlap and the public version satisfies the request. If the attacker package is chosen, malicious code can execute in trusted development or build contexts, exposing credentials, altering artifacts, or extending access into critical software delivery systems.

Why the Package Resolver Turns a Naming Collision into a Security Problem

dependency confusion becomes risky because the resolver is not just choosing a library, it is choosing what code to trust inside a development or build workflow. When an internal package name overlaps with a public one, the public package can win if it better satisfies version rules or registry precedence. That makes the package name itself a trust boundary, which is dangerous in systems that automatically fetch and execute dependencies.

The practical issue is not only that a bad package may be downloaded. It is that package installation often happens in environments that already hold source code, signing material, cloud credentials, tokens, or access to internal services. That makes a seemingly ordinary dependency lookup a path into trusted workstations, CI jobs, and artifact pipelines.

When the attack path is about package selection and build-time execution, the useful controls are supply-chain oriented rather than purely endpoint oriented. Practitioners should treat package namespace management, registry precedence, pinning, and provenance verification as part of the same control surface, because a dependency confusion event is ultimately an integrity failure in software acquisition.

For broader supply-chain controls and build integrity guidance, see SLSA and the OpenSSF resources.

Why Developer Workstations and Build Infrastructure Are High-Value Targets

Developer endpoints and build systems are attractive because they are trusted choke points. A workstation may contain cached credentials, repository access, signing keys, local config, and authenticated sessions. A build agent may have permissions to pull private dependencies, publish packages, deploy artifacts, or write into release pipelines. If malicious code runs in either place, the attacker can often inherit that trust instead of having to break it.

The risk is amplified by automation. Workstations may install packages with broad user context, while build infrastructure may run unattended with repeatable access to source, secrets, and artifact stores. Even a short-lived execution window can be enough to exfiltrate tokens, tamper with build outputs, or stage persistence through a later pipeline step.

This is why dependency confusion is not just a malware delivery trick. It is a way to place attacker-controlled code at the exact point where software is assembled, tested, signed, or promoted. Once that happens, the blast radius can extend from one developer machine to shared CI systems and then into production release paths.

Grounding the operational impact in real-world patterns, the LiteLLM PyPI package breach, the Nx Package Attack, 2,300+ Credentials Leaked, and the PyPI Breach all show how package trust failures can expose developer secrets and expand access.

Risk and Threat Considerations

Dependency confusion creates both exposure risk and attacker opportunity. The exposure comes from running untrusted code in environments that already have privileged network reach and sensitive material. The attacker opportunity comes from the fact that package managers and build tools are designed to resolve dependencies automatically, so malicious code can be introduced without a visibly suspicious action by the developer.

Failure mechanism: name collision plus resolver precedence allows a public package to satisfy an internal dependency request, after which malicious install-time or import-time code can run in a trusted context and reach credentials, source, or build outputs.

Impact: stolen secrets, modified artifacts, poisoned builds, compromised developer machines, and potential compromise of downstream systems that trust the build pipeline.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK, OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS 4 — Secure Configuration of Enterprise Assets and Software	Dependency confusion exploits software acquisition and resolver configuration.
	CIS 6 — Access Control Management	Build and developer contexts often expose privileged credentials and tokens.
	CIS 16 — Application Software Security	Dependency confusion is a software supply-chain weakness in delivered code.
Recommendation — Harden package sources, pin dependencies, and restrict software acquisition paths. Limit build and developer access to only the credentials and systems they need. Validate dependency provenance and secure the software build pipeline.
NIST CSF 2.0	PR.DS — Data Security	Malicious dependencies can expose secrets, source, and artifact data.
	PR.IP — Information Protection Processes and Procedures	Resolver rules, pinning, and provenance checks are protective procedures.
Recommendation — Protect sensitive build data and secrets from unauthorized disclosure. Define and enforce dependency resolution and release integrity procedures.
MITRE ATT&CK	T1195 — Supply Chain Compromise	Dependency confusion is a supply-chain compromise path through package trust.
Recommendation — Map package trust abuse to T1195 and hunt for poisoned dependency activity.
OWASP Non-Human Identity Top 10	NHI-01 — Secrets and Credential Management	Malicious packages frequently steal build tokens and developer secrets.
	NHI-03 — Overprivilege and Least Privilege	Build and developer identities often have more access than they need.
	NHI-09 — Third-Party and Supply Chain Risk	Public package resolution can substitute untrusted third-party code for internal code.
Recommendation — Rotate exposed secrets and move them out of developer and CI environments. Reduce build and developer permissions to the minimum required for each pipeline stage. Require package provenance checks and namespace protections for third-party dependencies.
OWASP Agentic AI Top 10	A1 — Agent Goal Hijacking and Unauthorized Tool Use	Malicious build code can misuse trusted tool access in automated environments.
Recommendation — Constrain tool and action permissions for automated build execution.

Practitioner Guidance

What to verify: confirm that internal package names cannot be shadowed by public packages and that the resolver order, index configuration, and lockfile behavior are explicit and tested. If a build can reach production secrets, treat dependency resolution as an access control decision, not just a dependency-management setting.

Decision rule: if a package is allowed to execute during install or import, assume it can interact with the developer or build identity that launched it. Prioritise namespace isolation, pinned versions, and provenance checks before trying to detect whether a malicious package has already been used.

Practitioner takeaway: the key judgement is to protect the trust boundary around package resolution, because once attacker code runs inside the build path, the resulting compromise is usually about credential and artifact access, not just a bad library import.