They work because attackers exploit trust in package names, versions, and automated resolution behavior. Inflated versions can outrank internal packages, while impersonation names can lure developers into installing attacker-controlled code. The result is a supply chain risk that can bypass normal review if teams rely on manual checks or delayed scanning instead of registry-level detection and policy enforcement.
Why These Campaigns Keep Paying Off
Dependency confusion and package impersonation persist because software delivery systems are designed to prefer convenience, reuse, and automation. When package resolution trusts name similarity, version ordering, or upstream registry defaults too much, attacker-controlled packages can look legitimate long enough to be fetched, installed, and executed before a human notices.
This is not just a one-time hygiene problem. The same resolution behaviour repeats across development machines, build runners, CI/CD jobs, and ephemeral test environments, so a single naming weakness can keep reappearing wherever package lookup is automated. That makes the exposure durable, especially when teams rely on manual inspection after the fact.
Controls that improve provenance and policy enforcement are the natural counterweight here, especially when paired with stronger supply chain practices such as SLSA and the broader ecosystem work coordinated by OpenSSF. The operational lesson is that package trust has to be enforced where resolution happens, not only where code is reviewed.
For a concrete incident pattern, NHIMG’s LiteLLM PyPI package breach shows how package compromise can quickly move from dependency trust into credential exposure, while the Reviewdog GitHub Action supply chain attack illustrates how CI/CD trust can turn a seemingly routine update into secret theft.
Where the Persistent Risk Comes From
The persistence comes from structural assumptions, not from a single bad package. Many environments permit outbound access to public registries, accept new versions automatically, and resolve dependencies based on naming and semver logic. If an internal package name is not tightly controlled, an external package with the same or a confusingly similar name can become visible first and win resolution or developer attention.
Package impersonation is effective for the same reason. Attackers choose names that resemble legitimate libraries, typos, or vendor-adjacent packages because installation habits often depend on quick recognition rather than cryptographic verification. Once a malicious package enters a build or dev workflow, it can persist through cached artifacts, forked repos, copied manifests, and repeat installs across many projects.
That persistence is amplified when organisations treat scanning as a later-stage check instead of a gate at resolution time. Delayed detection can miss the first install event, and by the time a malicious package is identified, copies may already exist in logs, containers, caches, and CI outputs. In practice, the risk is less about one compromise and more about a pattern of repeated exposure.
NHIMG’s PyPI Breach and Nx Package Attack, 2,300+ Credentials Leaked are useful references for how package-centric compromise can scale into broader secret exposure and developer environment abuse. They also show why package trust must be treated as a control problem, not just a code review problem.
What Practitioners Should Enforce
Prioritise controls that reduce ambiguity at the registry and pipeline layers. Pin dependencies where appropriate, require approved sources, block unexpected namespace collisions, and validate package provenance before code is allowed into trusted build paths. If internal packages exist, reserve the namespace and make accidental external takeover harder.
What to verify: Check whether build and install jobs resolve packages from a policy-controlled source of truth, whether internal names are reserved, and whether dependency changes trigger deterministic review. If a team cannot explain which registry won in a given build, the control is too weak to trust.
Common mistake: Treating malware detection as a substitute for resolution control. By the time a scanner flags a package, the malicious code may already have executed in a developer workstation, pipeline runner, or release job.
Practitioner takeaway: Persistent risk exists because package ecosystems reward automation and trust by default, so the strongest defence is to make package selection deterministic, policy-bound, and verifiable before installation ever occurs.
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 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-3 — Remote Access is Managed | Registry and pipeline source trust must be policy-managed to prevent unintended package acquisition. |
| PR.DS-6 — Integrity Checking Mechanisms | Package provenance and integrity checks reduce the chance of malicious or impersonated packages being trusted. | |
| DE.CM-8 — Vulnerability Scans are Performed | Scanning helps detect malicious packages and exposed secrets after ingestion, but should not be the only gate. | |
| Recommendation — Enforce controlled package sources and approve dependency resolution paths before build execution. Verify package integrity and provenance before allowing artifacts into trusted pipelines. Run dependency and artifact checks early enough to block suspicious packages before execution. | ||
| CIS Controls v8 | 6.3 — Uninstall or Disable Unnecessary Services | Dependency minimization reduces the number of packages that can be abused through impersonation or confusion. |
| 16.11 — Software Integrity and Verification | Package confusion campaigns are directly countered by verification of software and dependencies. | |
| 16.13 — Monitor and Control Third-Party Software Components | Dependency confusion is a third-party component trust problem that needs controlled intake. | |
| Recommendation — Remove unnecessary dependencies to shrink the attack surface exposed to package lookalikes. Require integrity and provenance verification for external packages before they reach production builds. Control third-party dependencies through approved sources, inventory, and review. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Storage and Exposure | Package attacks commonly lead to secret exposure in CI/CD and developer environments. |
| NHI-05 — Overprivileged Non-Human Identities | Build and automation credentials often have excessive access, increasing the blast radius of a malicious package. | |
| Recommendation — Protect secrets that packages or build tools can access so compromise does not cascade. Reduce pipeline and automation privilege so a malicious dependency cannot reach broad systems. | ||
Related resources from NHI Mgmt Group
- Why do coordinated fake package campaigns create more risk for software supply chains than a single malicious package?
- Why do dependency confusion attacks create such a high supply chain risk for software teams?
- Why do compromised maintainer accounts create such large NHI risk in software pipelines?
- Why do package hallucinations and dependency confusion increase supply chain risk?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
