Typosquatting

Expanded Definition

Typosquatting is a supply chain deception technique in which an attacker publishes a package, module, or dependency name that differs only slightly from a trusted one, hoping automation or hurried developers will install it. In NHI and software delivery contexts, the target is often build pipelines, package managers, or internal dependency mirrors, where a single character can determine whether trusted code or attacker-controlled code is executed. The term is closely related to lookalike domains and dependency confusion, but typosquatting is specifically about exploiting naming mistakes rather than routing mistakes or namespace collisions.

Definitions vary across vendors on whether the term includes Unicode homograph attacks, repository impersonation, or only direct spelling substitutions. For operational use, NHI Management Group treats typosquatting as any malicious package naming strategy that relies on human error or automated resolution to impersonate a legitimate dependency. Guidance in the NIST Cybersecurity Framework 2.0 supports the broader need for software supply chain integrity, even though it does not use the term itself.

The most common misapplication is treating typosquatting as a user-awareness issue only, which occurs when package validation and allowlisting are absent from the delivery pipeline.

Examples and Use Cases

Implementing controls against typosquatting rigorously often introduces friction in developer workflows, requiring organisations to weigh faster package installation against stricter verification and review.

• A CI pipeline installs reqeusts instead of requests because the repository allows unrestricted outbound dependency resolution.
• An internal developer copies a dependency name from chat and misses a one-letter change, allowing attacker code to enter a build artifact.
• A package registry is pre-seeded with a plausible variant of a popular library, tricking automated tooling that trusts name similarity over provenance.
• A team hardens its process by pinning dependencies, validating publisher identity, and checking hashes before install, reducing exposure to lookalike packages.

This risk is especially visible in environments with weak NHI governance, where Ultimate Guide to NHIs notes that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools. Package name abuse becomes far easier when build systems already trust unstable inputs. The relevant defensive model is reinforced by NIST Cybersecurity Framework 2.0, especially where software acquisition and supply chain risk need explicit controls.

Why It Matters in NHI Security

Typosquatting matters in NHI security because software delivery systems increasingly depend on non-human identities such as automation accounts, CI/CD tokens, and package publishing credentials. If those identities can install or publish dependencies without strong provenance checks, a single typo can become a privileged execution path. In practice, the threat is not limited to developer error. It also affects build bots, repository sync jobs, and release automation that resolve names faster than humans can verify them. Strong NHI governance reduces this exposure by tying package access to identity assurance, restricted token scope, and approval workflows.

NHIMG research shows that 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, which helps explain why malicious dependency naming is rarely a harmless nuisance. It becomes a major issue when secrets, signing keys, or deployment credentials are reachable from a compromised build step. The Ultimate Guide to NHIs is directly relevant here because NHI exposure, rotation gaps, and weak visibility amplify the blast radius of a poisoned dependency. Operationally, this overlaps with the supply chain integrity expectations reflected in NIST Cybersecurity Framework 2.0.

Organisations typically encounter the operational cost of typosquatting only after a malicious package has been pulled into a pipeline and a release, at which point the issue becomes unavoidable to investigate and contain.