What are the signs that a lockfile may be hiding a typosquatting attack?

Warning signs include unexpected packages in package-lock.json, dependencies pulled from unfamiliar registries, odd scopes, and version numbers that look precise but do not match the intended package lineage. Teams should also treat suspicious diffs between package.json and package-lock.json as a signal that resolution may have captured an unapproved or malicious dependency.

What a suspicious lockfile reveals about package substitution

A lockfile can expose more than dependency version drift. When it contains packages, registries, or scopes that do not match the project’s declared dependency intent, it may indicate that resolution has been steered toward a lookalike package rather than the one developers expected. That matters because lockfiles often become the trusted source for repeatable installs, code review, and build automation.

For package integrity questions like this, a useful external reference is the MITRE ATT&CK Enterprise Matrix, which helps teams think in terms of adversary technique rather than just malformed metadata. In practice, teams usually notice the problem only after the dependency has already been approved in a review path that assumed the lockfile was authoritative.

How typosquatting shows up in dependency resolution

Typosquatting works by exploiting human expectation at the naming layer, then relying on automated package resolution to make the wrong choice look legitimate. In a lockfile, that often appears as a package name that is extremely close to the intended one, but with a different namespace, registry origin, or package lineage. The key issue is not simply that the name is unfamiliar. It is that the lockfile has recorded a resolved artifact that no longer aligns with the dependency relationship the team thought it was approving.

There are a few practical signals to inspect together. First, compare the direct dependency declaration with the resolved entries in the lockfile and ask whether the package name, owner, and registry all make sense for the application. Second, review whether a transitive dependency has appeared in a place where a different package should have been selected. Third, check whether the lockfile includes a version pin that looks precise but is attached to a package whose lineage is not what the maintainers intended.

Unexpected package names or near matches to known dependencies
Registry URLs that differ from the project’s normal source of truth
Odd scope usage or namespace changes that do not fit the package ecosystem
Lockfile entries that changed without a corresponding dependency intent change

Official package metadata guidance from the CISA cyber threat advisories is useful here because it reinforces the habit of treating supply-chain anomalies as security signals, not just build noise. Where teams rely on automated updates or bot-driven dependency management, the lockfile can become the place where a malicious substitution is quietly normalised.

This guidance breaks down when organisations allow multiple registries, mirrored proxies, or vendor-specific package feeds without a clear provenance policy, because the same lockfile pattern can be either legitimate or hostile depending on the approved source model.

Where the false alarms and real compromises diverge

Tighter dependency controls often increase review overhead, requiring organisations to balance supply-chain assurance against developer speed.

Not every odd lockfile entry is evidence of an attack. Monorepos, private package registries, vendored dependencies, and ecosystem-specific resolution rules can all produce changes that look suspicious at first glance. The consensus view is that a lockfile should be validated against the intended software bill of materials and approved source policy, rather than judged on name similarity alone. That distinction matters because a legitimate package update can still change transitive resolution patterns in a way that resembles typosquatting.

The most important edge case is when a dependency name is valid but the package lineage is wrong. In those cases, the lockfile may still look mechanically consistent while pointing to an unapproved publisher or mirror. Teams should therefore treat the lockfile as one input to verification, not as proof of authenticity. If the project permits packages from multiple sources, the review process should require an explicit reason for the source change, not just a passing similarity check.

Another practical wrinkle is that exact version pins can create false confidence. A malicious or unintended package can be pinned precisely and still be wrong for the project. The real test is whether the resolved artifact matches the expected publisher, namespace, and dependency history.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1195 — Supply Chain Compromise	Typosquatting in lockfiles is a supply-chain substitution pattern.
Recommendation — Map suspicious dependency substitution to T1195 and review package provenance before merge.
CIS Controls v8	2 — Inventory and Control of Software Assets	Lockfiles must align with approved software inventory and source policy.
	16 — Application Software Security	Package resolution anomalies are application supply-chain security issues.
Recommendation — Inventory approved packages and block unvetted dependency sources from entering builds. Verify dependency integrity and require review for unexpected lockfile changes.
NIST CSF 2.0	GV.SC — Cyber Supply Chain Risk Management	Lockfile anomalies indicate software supply-chain governance breakdowns.
	PR.IP — Information Protection Processes and Procedures	Review workflows should detect lockfile drift and unapproved dependency changes.
Recommendation — Apply supply-chain governance to validate package origin, lineage, and approval. Enforce review procedures that compare declared dependencies with resolved lockfile entries.

Practitioner Guidance

What to verify: Confirm that the lockfile change can be explained by an approved dependency update, registry policy, or legitimate transitive resolution shift. If the package name is close but the owner, scope, or registry is different, treat that as a verification failure until a maintainer can explain the lineage.

Decision rule: If the lockfile shows a package that was not intentionally introduced, or if a dependency changed sources without a corresponding project change, escalate it as a supply-chain review item rather than a routine merge. That is especially important when automated tooling has rewritten the lockfile and obscured the original selection path.

What good looks like: The declared dependency, the lockfile entry, and the approved registry policy all point to the same package lineage, and reviewers can trace why each resolved artifact exists. When those three views line up, the lockfile is supporting reproducibility rather than hiding substitution.

Practitioner takeaway: The strongest indicator is not simply an unfamiliar package name, but a resolved dependency that cannot be reconciled with the project’s approved source and lineage model.