What is the difference between Dependency Confusion and Typosquatting?

Dependency confusion abuses package-resolution rules by publishing a malicious package with a higher-precedence name than an internal dependency, while typosquatting relies on lookalike names that users or tooling mistype. Both target software supply chains, but dependency confusion exploits ordering and trust, whereas typosquatting exploits naming errors. Defend with package allowlists, namespace controls and dependency validation.

How Dependency Confusion Differs from Typosquatting in Practice

dependency confusion and typosquatting both exploit how package ecosystems resolve trust, but they succeed in different ways. Dependency confusion wins when a resolver prefers the wrong source or precedence order, while typosquatting wins when a human or tool selects a lookalike package name. The operational distinction matters because the defensive control points are different.

That difference is why package managers, private registries and CI pipelines should be treated as part of the attack surface. The first attack abuses resolution logic and namespace handling; the second abuses naming hygiene, search behaviour and user expectation. A team can be vulnerable to one, both, or neither depending on how dependencies are named, fetched and validated.

For a practical example of the broader risk pattern, see the Malicious Package and Dependency Confusion Guide, which covers how package namespace decisions, typosquats and registry controls interact in real supply-chain environments.

What Each Technique Tries to Exploit

Dependency confusion usually depends on an organisation having an internal package name that is also available, or can be made to appear available, in a public registry. If the build or install process is not strict about source priority, the external package can be pulled in instead of the intended internal one. In other words, the attacker is betting on ordering, ambiguity and trust in the resolver.

Typosquatting is simpler in concept. The attacker publishes a package whose name is close enough to a popular or expected dependency that someone mistypes it, copies a wrong install command, or accepts a misleading suggestion. The attack succeeds through resemblance, not precedence. It is closer to phishing by package name than to resolver abuse.

The practical consequence is that dependency confusion is often an infrastructure and policy problem, while typosquatting is often a naming, review and allowlisting problem. Good source controls reduce both, but the specific failure mode is different.

That is why broader supply-chain controls such as the Open Source Security Guide are relevant here: pinning, trusted publishing and package validation reduce the chance that either naming tricks or source-precedence errors turn into code execution.

The same distinction shows up in incident analysis. A malicious package can be harmful even if the name is not deceptive, because the resolver accepted the wrong source. Conversely, a perfectly ordinary package can still be dangerous if it is chosen because the user mistyped the intended one. The abuse path is different, so the prevention strategy must address both source trust and name trust.

Controls That Stop One Attack Without Leaving the Other Open

The safest baseline is to require explicit package source rules, namespace controls and dependency validation instead of relying on default resolver behaviour. Dependency confusion is best prevented by ensuring internal packages are pinned to approved registries or scopes, and that build systems do not silently fall back to public sources for names that should be private. Typosquatting is best reduced by allowlists, exact-name validation, and human review of new dependencies.

Teams should also verify dependency provenance before trusting a package, especially when a package is newly introduced or unusually similar to an existing one. Open source security programs that combine SBOMs, dependency pinning and provenance checks help because they make the package origin visible before installation or deployment. A good control is not only “is this name expected?” but also “is this source and package lineage expected?”

For organisations standardising their open source controls, the OpenSSF guidance is useful because it centres package integrity, trusted publishing and ecosystem hygiene rather than treating every dependency risk as the same problem.

If the concern is broader software supply-chain governance, the Software Supply Chain Security Guide is the stronger anchor for provenance, dependency policy and secure build controls across source, build and dependency stages.

Risk and Threat Considerations

Both techniques can deliver the same end result, malicious code inside a build or runtime environment, but they do so through different weaknesses. Dependency confusion is especially dangerous where internal package names are predictable and source priority is loosely configured. Typosquatting is especially dangerous where developers install packages manually, accept search suggestions, or rely on weak review habits.

Failure mechanism: Dependency confusion succeeds when the resolver trusts precedence or registry fallback more than source authenticity, while typosquatting succeeds when a near-match package name slips past human or tool-based review.

Impact: Either path can introduce malicious code into builds, leak secrets during install or runtime, and create a supply-chain foothold that is difficult to detect after the package is already trusted by downstream systems.

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 addresses the attack and risk surface, while SLSA, OWASP ASVS, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
SLSA	Build Provenance	Dependency confusion and typosquatting both target artifact origin trust.
Recommendation — Require provenance checks before accepting packages into builds.
OWASP ASVS	V13 — Configuration	Package source precedence and allowlists are configuration controls that prevent wrong-package retrieval.
Recommendation — Enforce explicit dependency source configuration and approved registries.
CIS Controls v8	CIS-15 — Service Provider Management	Third-party package trust and supply-chain vetting depend on managed external software sources.
Recommendation — Vet external package sources and restrict unapproved software ingestion.
NIST CSF 2.0	PR.DS-01 — Data-at-Rest is Protected	Package integrity and source validation protect the software artifacts that build systems consume.
Recommendation — Protect software artifacts with integrity checks and source validation.
OWASP Non-Human Identity Top 10	NHI-03 — Vulnerable Third-Party NHI	Third-party package compromise is an external dependency trust problem with supply-chain exposure.
Recommendation — Assess third-party package trust and block unsafe dependency sources.

Practitioner Guidance

What to verify: Confirm that private package names cannot be resolved from public registries unless that is explicitly intended, and test whether your build tooling will fall back to public sources when an internal package is missing. Then verify that new dependencies are checked against an allowlist or registry policy rather than accepted because they look plausible.

Decision rule: If the package is supposed to be internal, treat any public resolution as a failure; if the package name is new or unusually similar to an existing one, require explicit review before it is allowed into the build. That rule catches both precedence abuse and lookalike naming.

Practitioner takeaway: Dependency confusion is a trust-and-ordering problem, while typosquatting is a naming-and-selection problem. Mature controls need to lock down both the registry path and the package name path, or the weaker one becomes the attacker’s entry point.