Developers have spent years being told to watch for the software-supply-chain version of a misspelled street sign: lodsh instead of lodash, reqeusts instead of requests, one bad keystroke away from malware.
In a new report released Wednesday from Sonatype researchers suggest the better adversarial analogy is a confidence game.
The attacker is not always the obvious fraud in the dark alley. More often, it is the impostor in the right uniform, using the right jargon, standing in a place where everyone expects to see another plugin, config file, SDK, wrapper or helper package. The name looks useful, the package looks adjacent and the workflow feels normal. That is what gets it waved through.
Open source attacks now hide in plain sight
As part of Sonatype’s report “Beyond Typosquatting Attacks” it analyzed 4,309 malicious open-source packages and found that 91% of brandjacking malware went beyond simple typosquatting. The packages were not merely built to catch rushed developers who mistyped a trusted name. They were designed to look plausible inside real development ecosystems.
The finding reframes a familiar supply-chain problem. Open-source package abuse has moved beyond the classic “developer mistyped the package name” story. Attackers are borrowing the vocabulary, structure and extension logic of legitimate software work, especially in ecosystems where plugins, configs, wrappers and helpers are everywhere, according to Sonatype.
The danger is in the package that looks useful
For defenders, the question is no longer just whether a name looks wrong. It is whether a package looks normal for the wrong reasons.
Recent supply-chain incidents underscore the importance of understanding this shift.
TanStack said a May attack published 84 malicious versions across 42 npm packages after abusing GitHub Actions workflows. The malware was built to harvest cloud, Kubernetes, Vault, GitHub, npm and SSH credentials and then spread through other packages maintained by the victim. Unit 42 has tracked TeamPCP attacks against trusted security and developer infrastructure, including Trivy, KICS, LiteLLM and the Telnyx Python SDK. GitLab separately documented npm malware that harvested GitHub, npm, AWS, GCP and Azure credentials and propagated by infecting packages owned by victims.
Those cases were not just about suspicious spelling. They were about trusted-looking software paths becoming routes to credentials, build systems and downstream compromise.
Verizon’s 2026 Data Breach Investigations Report paints a broader picture. The report found that 31% of breaches now start with software vulnerabilities, surpassing stolen passwords as the leading initial access path, and that 48% of breaches involve ransomware.
Sonatype’s research is more focused and highlights the same defensive reality. Attackers increasingly win by exploiting trusted relationships organizations already rely on.
The install is not the jackpot. The jackpot is the developer data the package can reach after it runs: environment variables, API keys, package registry tokens, GitHub tokens, cloud secrets, SSH credentials and CI/CD secrets.
The report found that 74% of malicious packages targeted developer data: environments, secrets or both.
“Brandjacking attacks turn a plausible package name into execution, access, and follow-on compromise,” Sonatype wrote.
As painfully played out in recent headlines, credentials can turn one bad dependency into a broader compromise.
A stolen GitHub token can expose source code. A package registry token can let an attacker publish malicious updates. Cloud keys can reach infrastructure. CI/CD secrets can give attackers a path into build systems, where trusted software is assembled and shipped.
“Those credentials can amplify the attack beyond the original install,” Sonatype wrote.
Sonatype’s list of the top 20 tokens added to malicious package names is filled with ordinary development language: plugin, config, sdk, ui, native, test, web, core, typescript, utils, api and server. None of those words looks especially dangerous. That is the point.
It is not just misspellings. It is the grammar of modern software development.
“The blind spot appears at the moment of adoption,” Sonatype wrote. “This is less a problem of developer carelessness than control design.”
What developers and DevOps teams should flag
Sonatype isn’t suggesting that every developer now needs to become a package-name detective. Instead teams need better pause points before a new dependency enters a developer machine, build pipeline or production path.
The first check is naming context. Packages that add ordinary-sounding terms such as plugin, config, sdk, utils, api, server, core, ui or test should not be trusted simply because they sound useful. Those words are common in legitimate development, which is exactly why attackers use them. Security teams should also flag packages that use suffixes, prefixes, scoped names, internal-looking names, version mimicry or names that appear adjacent to a popular project without being clearly connected to it.
The second check is publisher behavior. A single package may not look obviously malicious. A publisher tied to repeated naming tricks, multiple package families or a sudden burst of similar uploads is a stronger signal. Sonatype argues defenders should look at campaign patterns, not just individual packages.
The third check is timing. Reputation systems can lag. A package may reach a developer workstation, test job or CI pipeline before it has enough external warning signs to look risky. That makes first-seen dependencies a control point. New packages should face extra review before they are allowed into builds, lockfiles or internal repositories.
The fourth check is blast radius. Build systems should not expose more secrets than they need. Environment variables, GitHub tokens, registry tokens, cloud keys, SSH credentials and CI/CD secrets should be tightly scoped and monitored. If a malicious package runs, the goal is to keep it from turning one install into access to source code, cloud infrastructure or the software release process.
For developers, the takeaway is to slow down when installing unfamiliar ecosystem-adjacent packages. For DevOps and platform teams, it is to build gates around new dependencies and lockfile changes. For AppSec teams, it is to monitor naming patterns, publisher behavior and campaign clusters. For security leaders, it is to stop framing the issue as developer carelessness. This is a workflow problem, and the attack happens at the moment a plausible-looking package is allowed to become trusted.
One question the report does not answer is how AI-assisted coding changes the risk.
AI coding tools add a dependency trust problem
Sonatype does not attribute the naming-variant campaigns to AI coding tools. The package patterns it describes also predate generative AI. Developers have long installed plugins, helpers, SDKs and config packages by hand.
But AI-assisted development adds pressure to the same weak spot.
Code assistants can recommend dependencies. Agentic coding tools can edit files, add imports, update lockfiles and run install commands. In that workflow, a plausible package name carries more weight, not less.
The risk is no longer only that a human developer mistypes a package name. It is that a human or AI-assisted workflow accepts a dependency because it looks like something that should exist.
That is where Sonatype’s findings connect to a larger AI security problem. If attackers are already designing malicious packages to look like ordinary plugins, configs, SDKs and helpers, AI coding tools could make those names feel even more routine. A package that sounds right to a model may also sound right to the developer reviewing its output.
To be clear, this report does not prove AI tools are driving these attacks. However, neither should AI-generated code get a pass on dependency trust.
Applying Sonatype’s advice to AI-assisted development means any package suggested by a coding assistant, added by an agent or introduced through a generated lockfile should be treated as a first-seen dependency. Teams should verify the package, inspect the publisher, confirm the project relationship and limit the secrets exposed during installation and build.
Photo by Bernard Hermant on Unsplash
