Open source malware is no longer just a numbers game. What was once largely a volume problem — thousands of malicious packages flooding public registries through typosquatting, brandjacking, and low-effort deception — has become something more precise and dangerous.

Attackers no longer rely only on high-volume registry abuse. As shown in our Q1 2026 Open Source Malware Index, they exploit the trust developers place in familiar packages, known release paths, and automated workflows.

The result is a software supply chain threat that is quieter, more staged, and often harder to spot before damage is done. Malware is increasingly focused on developer machines, CI/CD environments, tokens, and credentials.

The question is no longer if malicious packages exist in public ecosystems but if your organization can stop them before they reach developers and build systems.

Attackers Are Exploiting Trust, Not Just Code

Unlike vulnerabilities — which are unintentional flaws — open source malware is deliberately designed to cause harm, which changes how it must be defended against.

Malware is increasingly embedded in places developers expect to be safe, including:

• Trusted-looking packages that appear legitimate.

• Release paths that inherit credibility from maintainers, accounts, or build systems.

• Developer workflows where install scripts, build steps, and CI jobs can access credentials and secrets.

Reputation alone is no longer enough. A familiar package name, a widely used ecosystem, or an historically trusted maintainer does not guarantee safety. Attackers are deliberately positioning themselves inside those trust signals, making it critical to verify what you consume.

Developer Machines and CI/CD Environments Are the Target

In 2025, Sonatype identified over 454,600 new malicious packages, pushing the total beyond 1.233 million and signaling a shift toward sustained, industrialized attacks on the software supply chain.

Threat actors now focus on developer machines and CI/CD environments, where high-value assets live: tokens, credentials, environment variables, and access to release systems.

When a malicious package executes during install, compromise can happen before any release-time scan runs.

As a result, end-of-pipeline security is no longer sufficient. By then, malware may have already executed, exfiltrated secrets, or established persistence.

Malware Is Becoming More Staged and Persistent

Open source malware has evolved from simple credential theft into multi-stage attacks designed to persist and spread.

Modern campaigns now:

• Use stolen credentials to move laterally and escalate access.

• Download secondary payloads and establish persistence.

• Hide activity by removing or obfuscating malicious traces.

These patterns are already visible in real-world attacks, as seen in the examples that follow.

SANDWORM_MODE Shows Malware Becoming More Adaptive

SANDWORM_MODE highlights the shift from simple credential theft to adaptive, multi-stage attacks. It used obfuscation and delayed execution to evade detection, then harvested secrets, modified dependencies, and injected itself into developer workflows to spread.

Notably, it also targeted AI tooling, signaling how attackers are adapting to modern developer environments. That points to where open source malware may be heading next: attacks that are not only automated, but adaptive to the developer environment they land in.

Trusted Release Paths Are Now Attack Surfaces

The Trivy and LiteLLM compromise shows how attackers are shifting from fake packages to trusted release paths.

By abusing automation, service accounts, and tokens, attackers can inherit built-in trust and spread widely across pipelines and downstream projects.

The result is a much larger blast radius, making release infrastructure and workflows a critical part of the attack surface.

The Axios Attack Shows the Risk of Small Dependency Changes

The axios compromise shows how minimal changes can create major risk.

Instead of altering the package itself, attackers introduced a malicious dependency that executed on install, deployed a secondary payload, and removed traces of its activity.

This highlights the danger of transitive dependencies, even trusted packages can introduce risk through what they pull in.

Dependency Governance Has to Move Earlier

Organizations need to evaluate dependencies before they are installed. If malicious code executes during installation, security decisions must happen before packages reach developer machines or CI/CD environments.

That requires controlled pathways for open source consumption, including:

• Proxy repositories that mediate access to public registries.

• Policy enforcement to block or quarantine suspicious packages.

• Malware detection at the point of ingestion.

• Repository controls that govern what can be introduced into development.

It also means looking beyond direct dependencies. Transitive dependencies, install scripts, release metadata, publishing behavior, and unusual changes all need to be inspected to catch risk early.

Treat Development Environments as High-Value

Developer and CI/CD environments should be protected with the same rigor as production systems. These environments hold high-value assets like credentials, tokens, and access to release pipelines, making them prime targets for modern malware.

That means putting core protections in place, including:

• Limiting credential exposure.

• Enforcing least-privilege access.

• Monitoring for unusual behavior.

• Rotating secrets quickly and in a coordinated way.

Trust alone is no longer a reliable defense. Popular packages, maintainer accounts, and transitive dependencies can all introduce hidden risk. The goal is not to reduce open source usage, but to consume it safely with controls that allow developers to move quickly without blindly trusting what looks familiar.

Secure the Software Supply Chain Before Code Reaches Production

Open source malware has shifted from high-volume abuse to targeted trust exploitation — focusing on developer workflows, release paths, and early-stage environments.

Defending against it means moving security earlier: screen components before use, inspect transitive dependencies, protect developer environments, and replace assumed trust with continuous verification.

The organizations that succeed won't avoid open source. They'll consume it safely.

To learn more about the evolution of open source malware what you can do now, watch our full webinar on-demand.