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

What a suspicious lockfile is really telling you

A lockfile becomes suspicious when it stops behaving like a faithful record of resolved dependencies and starts looking like a place where resolution was steered. The tell is not just that a package exists, but that the package tree contains names, scopes, registries, or versions that do not fit the project’s normal dependency lineage.

Look first for packages that are technically valid but operationally unexpected. Typosquatting often hides in dependency resolution because the package name is close enough to pass a quick review, yet different enough to redirect installs to an attacker-controlled artifact.

Lockfile clues that deserve a closer review

Unexpected packages in package-lock.json are the most obvious indicator, but the stronger signal is inconsistency. A dependency that appears only in the lockfile, a sudden change in package scope, or a registry URL that differs from the team’s approved source can all indicate that the resolved artifact did not come from the intended package lineage.

Version strings can also be deceptive. A precise-looking version is not inherently trustworthy if the package name, maintainer, or registry path does not match the dependency the application was supposed to receive. In practice, attackers rely on reviewers treating the lockfile as routine output rather than as security-relevant evidence of what was actually installed.

Suspicious diffs between package.json and package-lock.json matter because they can reveal resolution drift. If the manifest still reflects the intended dependency set, but the lockfile pulls in a different package, the build may have accepted an unapproved dependency through confusion, typo, or registry manipulation.

How to separate normal dependency churn from an attack signal

Not every lockfile change is malicious. Fresh installs, transitive updates, and legitimate registry migrations can all produce noisy diffs. The practical test is whether the change is explainable by an approved dependency update and whether the package identity remains consistent across the manifest, lockfile, and registry source.

The moment a package name, scope, or registry endpoint is unfamiliar, treat the entry as a supply-chain question rather than a formatting question. That means checking whether the package belongs to a known maintainer, whether the source registry is expected, and whether the dependency graph still matches the project’s approved package set.

For broader background on package and dependency abuse patterns, Malicious Package and Dependency Confusion Guide is the most direct internal reference, and OWASP CICD-SEC-3 Dependency Chain Abuse Guide is useful when the lockfile issue is part of a broader build and dependency control problem.

Practitioner Guidance

What to prioritise: Treat the lockfile as evidence of supply-chain resolution, not just build noise. If the suspicious entry is from an unexpected registry, has an odd scope, or cannot be traced back to an approved dependency, investigate that package first rather than starting with generic build troubleshooting.

What to verify: Confirm the package’s origin, maintainer, and expected lineage against the repository policy, then compare the resolved tree with the manifest and the team’s approved package sources. A clean-looking version number is not enough if the dependency identity is wrong.

Common mistake: Teams often focus on whether the lockfile changed, instead of whether the change is semantically legitimate. The real question is whether the dependency resolution still points to the package the project intended to install.

Practitioner takeaway: A lockfile is suspicious when it preserves the shape of dependency resolution but changes the trust anchor behind it; the safest response is to validate package identity and source provenance before you trust the build.

Related resources from NHI Mgmt Group

• What are the signs that an exposed application is hiding a deeper attack path?
• What are the signs that a package supply chain attack is trying to blend in through mass typosquatting?
• What are the signs that a cloned repository may be part of a typosquatting attack?
• What are the signs that a cyber defense program is failing to stop common attack paths?