They exploit trust in automation. A developer or AI assistant can be steered toward a package name that looks legitimate, while the build process resolves a malicious public dependency instead of an intended internal one. The risk increases when governance cannot verify package origin quickly enough or when CI/CD access is overly broad.
Why This Matters for Security Teams
Package hallucinations and dependency confusion are dangerous because they turn ordinary software retrieval into a trust decision. When developers, build pipelines, or AI assistants choose dependencies by name alone, the organisation may import code that was never intended, reviewed, or approved. That creates a direct path for malicious packages to enter CI/CD, reach production, or contaminate downstream artefacts. Current guidance from the NIST Cybersecurity Framework 2.0 is clear that supply chain risk must be managed as an operational control problem, not just a developer hygiene issue.
The practical concern is not only malware. A poisoned package can steal secrets, alter build output, introduce backdoors, or impersonate internal libraries that teams assume are safe. In AI-assisted development, the problem gets sharper because an LLM may confidently recommend a plausible package name without knowing whether it is internal, public, deprecated, or malicious. That makes provenance, allowlisting, and dependency policy central to software trust. In practice, many security teams encounter dependency confusion only after a build has already consumed the wrong package rather than through intentional package governance.
How It Works in Practice
Dependency confusion typically succeeds when an internal package name also exists, or can be registered, in a public repository. If the build tool prefers the public source, or if resolution order is ambiguous, the attacker’s package can be fetched instead of the private one. Package hallucination is the adjacent failure mode: an AI assistant suggests a convincing but incorrect package name, and the developer or automation accepts it without checking provenance, publisher identity, or internal catalogue records.
Operationally, the risk is amplified by weak controls around package registries, outbound internet access from build runners, and excessive permissions in CI/CD. The right response is to combine policy, technical enforcement, and review. That usually means:
- forcing explicit source precedence for internal packages
- maintaining an approved software catalogue with ownership and versioning
- requiring provenance checks and signed artefacts where available
- scanning dependencies before build and again at release time
- restricting pipeline credentials so a compromised package cannot freely exfiltrate secrets
For identity and access teams, this is where Non-Human Identity governance matters. Build agents, package managers, service accounts, and automation tokens all need tightly scoped access to registries and secret stores. The OWASP Non-Human Identity Top 10 is useful here because package trust failures often become credential misuse problems once a malicious dependency lands in the pipeline. These controls tend to break down when multiple registries, shadow repositories, and loosely governed AI coding assistants all participate in the same release path because ownership and source-of-truth decisions become inconsistent.
Common Variations and Edge Cases
Tighter package governance often increases developer friction and release overhead, so organisations need to balance speed against verification depth. That tradeoff is real, especially in polyglot environments where teams pull from multiple language ecosystems and internal package mirrors. Best practice is evolving, and there is no universal standard for every repository pattern yet.
Edge cases often appear in monorepos, fork-based development, ephemeral test environments, and internal tooling that reuses public package names. In those environments, a simple allowlist is not enough unless ownership, namespace rules, and registry routing are also enforced. Where AI coding assistants are used, human review still matters because package suggestions can be plausible but wrong. The strongest control pattern is to make trusted package sourcing deterministic rather than relying on developer memory.
Security teams should also distinguish between prevention and detection. Preventing public package substitution is ideal, but alerting on newly seen package names, unusual registry lookups, or unexpected dependency graph changes can reduce blast radius when prevention fails. The NIST SP 800-53 Rev 5 Security and Privacy Controls is especially relevant for control mapping around supply chain oversight, configuration management, and integrity verification.
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 NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.SC-1 | Supply chain dependencies are a core risk management input for this issue. |
| OWASP Non-Human Identity Top 10 | Build agents and tokens are non-human identities often abused after dependency compromise. | |
| NIST SP 800-53 Rev 5 | SA-12 | System and component acquisition controls map to secure dependency sourcing. |
Inventory software sources and rank dependency risk before allowing builds to consume new packages.
