Why do dependency confusion attacks keep working in mature organisations?

Why This Matters for Security Teams

dependency confusion works because software supply chains still contain implicit trust decisions that are easy to overlook during fast-moving build and release cycles. A package resolver that accepts the first matching name, or a repository policy that does not clearly separate internal and public namespaces, can turn a routine install into a code execution path. That is why this issue remains relevant even in mature organisations with modern CI/CD tooling.

The operational risk is not limited to malicious code landing in a build. It also creates a blind spot in vendor assurance, release integrity, and incident detection because the package may look legitimate until it is already executing inside the pipeline. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces the need for supply chain controls, change control, and provenance checks, but the practical gap is usually policy enforcement rather than lack of awareness.

Teams also underestimate how dependency confusion intersects with attacker tradecraft. Once a malicious package is pulled into a build environment, the next steps often resemble established intrusion techniques such as credential access, persistence, and lateral movement, which map cleanly to the MITRE ATT&CK Enterprise Matrix. In practice, many security teams encounter dependency confusion only after package telemetry or outbound traffic has already revealed the compromise, rather than through intentional namespace governance.

How It Works in Practice

The attack usually starts with a predictable internal package name that is referenced in source code, lock files, or build manifests. If the organisation does not strictly pin the source registry, the build tool may query both private and public repositories. An attacker publishes a package with the same name and a higher version number, or simply one that is chosen first by resolver behaviour, and the pipeline downloads it as if it were trusted.

Once the package is installed, the attacker can trigger arbitrary code during install hooks, test execution, or build steps. The most dangerous cases are those where the build environment has access to secrets, signing keys, cloud credentials, or release automation tokens. This is why dependency confusion is not just a package hygiene issue. It is a privilege boundary problem inside the software delivery system.

• Separate internal and public registries with explicit allowlists, not implicit fallback behaviour.
• Reserve internal package names in public ecosystems where possible, so attackers cannot claim them.
• Pin versions and enforce lockfile integrity so unexpected package sources are detectable.
• Scan build logs and artifact metadata for anomalous package resolution events.
• Limit build-time secrets and use short-lived credentials so compromise has less value.

For organisations building higher-risk automation, threat modelling should also consider how autonomous tooling discovers packages, retries failed installs, and inherits credentials. That matters even more as AI-assisted development pipelines expand, because model-generated code may introduce new dependencies without strong human review. Current guidance suggests treating package provenance as a control surface, not a convenience layer. These controls tend to break down when legacy build tools silently support public fallback and teams assume repository configuration is inherited everywhere, because the resolver behaviour differs across languages and CI runners.

Common Variations and Edge Cases

Tighter registry controls often increase maintenance overhead, requiring organisations to balance developer convenience against supply chain assurance. There is no universal standard for resolver behaviour across ecosystems, so teams need language-specific controls instead of one policy statement that assumes parity between npm, PyPI, Maven, NuGet, or Go modules.

Some environments reduce risk by mirroring approved packages into an internal repository, but that only works if mirroring is paired with namespace governance and source verification. Otherwise, the mirror simply propagates untrusted material faster. In regulated or high-assurance environments, dependency confusion can also become a governance issue because the attack path touches code signing, release approval, and audit evidence, not only package management.

Another edge case is internal package publication to public ecosystems for open-source reasons. Best practice is evolving here: teams should maintain a clear distinction between public and private ownership, but there is no single industry standard for handling name reservation across every registry. Where identity and automation intersect, the build service itself should be treated as a non-human identity with tightly scoped privileges, short-lived secrets, and explicit provenance checks. For a broader threat lens, CISA cyber threat advisories and the attack pattern coverage in MITRE ATT&CK Enterprise Matrix are useful references, while AI-assisted pipelines warrant closer attention to agentic abuse patterns described in the Anthropic — first AI-orchestrated cyber espionage campaign report and the MITRE ATLAS adversarial AI threat matrix.

Related resources from NHI Mgmt Group

• How should organisations keep access working when the identity provider is unreachable?
• How do organisations evaluate whether deception is working against autonomous attacks?
• Why do social engineering attacks keep working against modern IAM controls?
• Why do spoofing attacks keep working even when users are trained?