A supply-chain tactic in which a public package is named to resemble an internal or private dependency so that automated resolution pulls in the wrong artifact. This exploits trust in package naming, registry configuration, and developer expectations during install time.
Expanded Definition
Package namespace shadowing is a dependency-resolution attack that abuses trust in naming rather than code execution. In NHI and software supply-chain contexts, the risk appears when build tools, package managers, or internal registries resolve a public artifact before the intended private package, especially when names are similar enough to pass human review. The term overlaps with dependency confusion, but namespace shadowing is narrower in emphasis: the attacker aims to occupy or mimic a package namespace that developers already expect to be internal. That makes registry policy, naming conventions, and repository priority just as important as scanner coverage.
Definitions vary across vendors on whether the problem is a naming attack, a registry misconfiguration, or a broader artifact impersonation issue. For governance purposes, NHI Management Group treats it as a control failure at the resolution layer, because the wrong package can inherit the trust assigned to the intended one. NIST guidance on software and identity controls, including NIST SP 800-53 Rev 5 Security and Privacy Controls, supports the need to enforce source integrity, access restrictions, and change control around code ingestion. The most common misapplication is assuming package names alone are safe, which occurs when teams rely on human recognition instead of registry-scoped policy and explicit source pinning.
Examples and Use Cases
Implementing defenses against namespace shadowing rigorously often introduces friction in developer workflows, requiring organisations to weigh fast package resolution against tighter registry governance and review steps.
- A team publishes an internal package to a private registry, but the build agent is configured to search public registries first, so a similarly named public package is installed instead.
- An AI agent with tool access pulls a dependency during autonomous setup and inherits a malicious artifact because the namespace was not pinned to the trusted source.
- A CI pipeline uses broad wildcard allowlists for package names, creating room for a public package to masquerade as a private internal module.
- During incident review, investigators trace credential exposure to a malicious install-time payload, similar to cases documented in the LiteLLM PyPI package breach, where package trust and install-time execution became security-relevant.
- Security teams compare the package source chain against NIST SP 800-53 Rev 5 Security and Privacy Controls to verify approved repositories and artifact provenance.
Why It Matters in NHI Security
Package namespace shadowing matters because NHI environments increasingly depend on automated software delivery, agentic toolchains, and secrets-bearing build systems. If a malicious package is resolved instead of the intended internal artifact, attackers can steal tokens, modify deployment logic, or implant backdoors before runtime protections ever engage. This is especially dangerous when service accounts and CI identities have broad privileges. NHI Mgmt Group reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, underscoring how often identity abuse becomes the impact path after an initial supply-chain foothold. In practice, the control failure is not just code integrity but identity integrity, since the compromised package may execute in a context that can reach vaults, registries, or cloud APIs.
For this reason, namespace shadowing should be evaluated alongside registry trust boundaries, package provenance checks, and least-privilege NHI design, not as a standalone developer hygiene issue. The broader NHI lifecycle guidance in Ultimate Guide to NHIs helps frame why visibility, rotation, and offboarding matter once a compromised dependency has already touched automated systems. Organisations typically encounter the consequence only after a build or deployment has already been abused, at which point namespace shadowing becomes operationally unavoidable to address.
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 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret and dependency trust failures that enable malicious package resolution. |
| OWASP Agentic AI Top 10 | A-04 | Agent toolchains can fetch shadowed packages during autonomous execution. |
| NIST CSF 2.0 | PR.DS-6 | Addresses integrity of data in transit and at rest, including software artifacts. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero trust limits implicit trust in internal network location or naming. |
| NIST SP 800-63 | Identity assurance principles inform trust in service identities that fetch packages. |
Pin trusted registries and verify artifact provenance before any NHI-bound install or deployment.
Related resources from NHI Mgmt Group
- How should teams reduce risk from malicious npm package installs?
- When does a compromised developer package become a major security risk?
- When should teams treat a package compromise as a cloud security event?
- How should security teams protect npm and package publishing workflows from identity compromise?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
