Package Squatting

Expanded Definition

Package squatting is a software supply chain attack in which an adversary publishes a package name that looks legitimate enough to attract installs, such as a typo, a namespace variant, or a project name that matches an abandoned dependency. The risk is not the package name alone, but the trust shortcut it exploits: developers, build pipelines, and automation often select packages by familiarity rather than by verifying publisher identity, provenance, or expected dependency graph. In practice, package squatting overlaps with typosquatting, dependency confusion, and namespace impersonation, but those terms are not identical and usage in the industry is still evolving. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant here because software supply chain controls depend on integrity, configuration management, and change assurance rather than simple package availability.

The most common misapplication is treating package squatting as a naming nuisance, which occurs when teams assume package search results are safe because they appear near a trusted project name.

Examples and Use Cases

Implementing package trust rigorously often introduces friction in developer workflows, requiring organisations to weigh installation speed against stronger verification and approval steps.

• A developer searches for an internal library, finds a similarly named public package, and installs it into a production build before noticing the publisher is unrelated.
• An attacker registers a package name after a popular dependency is renamed or abandoned, then waits for automation to pull it into a CI pipeline.
• A build system accepts a package from a broad namespace match instead of an allowlisted source, making a brand-like name sufficient to trigger download and execution.
• A malicious maintainer publishes a package with documentation that mirrors a real project, increasing the chance that a human reviewer approves it during a rushed dependency update.
• An organisation using internal package mirrors fails to verify provenance metadata, allowing a squatted package to enter downstream environments through a trusted cache.

Controls published by the NIST control catalog are most effective when package selection is treated as a governed supply chain decision, not a convenience choice.

Why It Matters for Security Teams

Package squatting matters because software dependencies are now a routine execution path, not a niche development concern. Once a squatted package is installed, it can introduce credential theft, code execution, data exfiltration, or persistence through build scripts and post-install hooks. Security teams need to care about this term because the attack often succeeds before traditional endpoint or network defenses can intervene. The right response usually combines source allowlisting, provenance checks, dependency review, internal package repositories, and alerting on suspicious namespace changes. In identity terms, the issue also connects to NHI governance because build systems, CI jobs, and deployment agents often consume secrets and tokens automatically, which means one malicious package can target machine identities as readily as human users. Guidance from supply chain security work such as the NIST security controls framework helps teams translate the concept into enforceable review and integrity measures.

Organisations typically encounter the real cost only after a compromised build, at which point package squatting becomes operationally unavoidable to investigate and contain.

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?