Sonatype research: only 9% of malicious open source packages rely on typosquatting alone
Sonatype research: only 9% of malicious open source packages rely on typosquatting alone

An analysis of more than 4,300 malicious open source packages by Sonatype found that 91 percent went beyond name misspelling — instead using package names engineered to look legitimate within the conventions of the ecosystems they were targeting.

Typosquatting — registering package names with deliberate spelling errors close to popular libraries — has been the dominant framing for open source supply chain attacks for years. Sonatype's data suggests that framing is now outdated for the majority of malicious packages.

The broader category the whitepaper describes is manufactured legitimacy: naming packages to match the vocabulary, formatting conventions, and structural patterns that developers and AI coding assistants recognise as routine. A package that looks like a React utility, uses standard naming patterns, and arrives at a moment when a developer is updating dependencies does not trigger the same review threshold as a misspelled name of a well-known library.

Typosquatting is table stakes now. Attackers aren’t just misspelling popular package names — they’re copying the language, structure, and habits of real software ecosystems. By the time a malicious package has built a reputation, it may already be in a developer workstation,

Brian Fox (CTO and Co-Founder, Sonatype)

The numbers from the study are specific. Of the 4,300-plus malicious packages analysed, 74 percent targeted developer data — environment variables, secrets, or both. One hundred and seventy-four distinct campaign families were identified, suggesting industrialised attack development rather than opportunistic individual actors. Five hundred and forty packages specifically targeted the React framework.

In response, Sonatype is extending its Firewall product to cover third-party repositories and mixed repository environments, not just the primary package registries it has protected previously. The argument is that organisations routing dependencies through internal or hybrid repositories need the same inbound screening as those pulling directly from public sources.

Developers and AI agents need safer defaults, not more dashboards. The winning model is to approve, block, guide, and remediate when a component is chosen — not after bad code is already in the build.

Brian Fox (CTO and Co-Founder, Sonatype)

The expansion matters partly because AI coding assistants change the dependency graph in ways that are harder to review manually. An assistant that adds a dependency it has seen referenced in training data may surface a package name that has since been hijacked or cloned, without the context to distinguish that from a legitimate library.

More News