Engineering organizations deploy dependency scanners, train developers, secure endpoints, and establish policies for open source components. Yet malicious packages still reach developer workstations, build systems, and CI/CD environments.

The easy explanation is that a developer mistyped a package name or failed to inspect a dependency. But that explanation is increasingly incomplete.

According to Sonatype's latest research on malicious open source packages, only 9% used traditional typosquatting to imitate legitimate software. The remaining 91% relied on broader naming variations designed to resemble legitimate plugins, configurations, SDKs, utilities, wrappers, scoped modules, and versioned extensions.

Attackers are exploiting naming conventions and workflow familiarity, not just hurried keystrokes.

Engineering leaders should ask a different question: not why a developer selected the wrong package, but why the development process let a plausible-looking package execute before anyone verified that it was safe.

That problem stems from five systemic challenges:

• Malicious packages no longer look obviously wrong.

• Fast development leaves little time for package verification.

• Post-download detection can come too late.

• Attacker campaigns move faster than package reputation.

• Attackers exploit the least-governed path into development.

Malicious Packages No Longer Look Obviously Wrong

Malicious packages no longer look obviously malicious because attackers design them to resemble legitimate parts of the software ecosystem.

Sonatype researchers found that 91% of the brandjacking malware in our dataset went beyond traditional typosquatting. Instead of relying on spelling mistakes, attackers used naming variations — such as prefixes, suffixes, scoped modules, and familiar terms like plugin, config, or sdk — to make malicious packages appear trustworthy.

The shift is significant. Traditional typosquatting exploits typing errors. Modern naming-variant attacks exploit developer expectations. In ecosystems full of plugins, wrappers, and integrations, a malicious package only needs to look like it belongs.

As a result, checking package names is no longer enough. Organizations need security controls that evaluate package context before software reaches developers.

Fast Development Leaves Little Time for Package Verification

Developers download risky packages because modern software workflows prioritize speed over manual package verification.

Adding a dependency is often just another step in completing a task. Developers may install packages while:

• Resolving a build error.

• Testing a new framework.

• Following online documentation.

• Working against a deadline.

• Accepting a recommendation from an AI coding assistant.

In those moments, a malicious package often looks no different from a legitimate one. Both may have plausible names, professional documentation, and little publishing history.

That makes package verification a systems problem, not a developer problem. Organizations need security controls that evaluate components automatically before they reach developer workstations or build pipelines.

Post-Download Detection Can Come Too Late

Post-download detection may be too late because many malicious packages execute as soon as they are installed.

Unlike vulnerabilities, which are unintended weaknesses in legitimate software, malware is intentionally designed to steal data, establish access, or deliver additional payloads. A malicious package may begin doing exactly that as soon as it is installed.

Sonatype found that 74% of the malicious packages analyzed targeted developer data, including environment information, secrets, or both. Common behaviors included host-information exfiltration, secrets theft, droppers, backdoors, and obfuscated code. Development environments often contain API keys, GitHub tokens, cloud credentials, registry tokens, SSH keys, and CI/CD secrets — all valuable targets for attackers.

By the time a scanner identifies the package in a manifest or repository, the initial compromise may already have occurred. Engineering leaders should therefore evaluate software supply chain security tools not only by whether they detect malware, but by whether they stop it before download.

Attacker Campaigns Move Faster Than Package Reputation

New malicious packages often spread faster than reputation-based defenses can identify them.

By the time public reports, download counts, or other trust signals indicate a package is dangerous, it may already have reached developer workstations, test environments, and build systems.

Sonatype identified 174 campaign families that reused naming tactics, publisher behavior, infrastructure, and malicious objectives across packages and ecosystems. Rather than publishing isolated malicious packages, attackers increasingly operate repeatable campaigns that move faster than traditional reputation systems.

That is why automated quarantine matters. Instead of trusting every unfamiliar package or blocking every new one, organizations can temporarily hold suspicious components while additional analysis determines whether they should be released or blocked.

Attackers Exploit the Least-Governed Path Into Development

Attackers exploit the least-governed path into development because security controls rarely cover every way software enters an organization.

Dependencies enter organizations through far more than a centrally managed repository. They also arrive through:

• Direct downloads from public registries.

• Developer workstations.

• CI/CD pipelines and build systems.

• Containers and container images.

• AI-generated dependency recommendations.

• Temporary or unmanaged development environments.

Malware prevention is only as strong as the least-governed path. Organizations may tightly control their internal repository while allowing software to enter elsewhere with little or no inspection.

Engineering leaders should identify every path through which software enters the organization and apply consistent controls across those workflows. Sonatype Firewall extends malicious package protection across repositories, endpoints, and the network edge, helping prevent unsafe components from reaching developers regardless of how they are introduced.

The Better Model: Stop Malware Before Download

Organizations reduce malicious package risk by evaluating software before it reaches developers instead of after it enters the environment.

That means:

• Evaluating packages before installation.

• Assessing publisher, naming, ecosystem, and campaign context.

• Automatically quarantining suspicious components.

• Protecting every path through which software enters development.

• Keeping trusted software moving without unnecessary friction.

Modern malicious packages are designed to look ordinary. They no longer rely primarily on spelling mistakes. They rely on manufactured legitimacy.

Organizations need open source security controls that evaluate components before they reach developers, block malicious packages before they enter repositories, and continuously guide teams toward trusted components instead of leaving every dependency decision to individual developers.

This approach requires accurate, timely intelligence. Public vulnerability databases and reputation signals provide valuable context, but they often lag behind emerging malware campaigns or lack the detail needed to make confident policy decisions. Sonatype Research Labs continuously investigates malicious open source packages, validates findings beyond public sources, and delivers proprietary threat intelligence that helps organizations identify and stop malicious components earlier.

That intelligence powers software supply chain security capabilities, enabling engineering teams to build with confidence without slowing development.