Attacks rewritten: Where malware enters the build

Most software supply chain attacks do not only affect your production deployments. They also affect your CI/CD clusters, your developer workstations, and many other systems that you considered safe. And they start in the supply chain outside your organization and sneak in via package managers and binary dependencies. We’ve seen supply chain attacks like this evolving rapidly recently, with users of Trivy, litellm, and axios, among others, feeling the effects.

As illustrated by the attacks mentioned above, the world has changed a lot in the past few weeks. At Chainguard Assemble 2026, we explored how modern software supply chain attacks work, how malware can enter systems, and what teams can do to enhance the security of both production systems and developer workstations. We’ll talk about this at a high level in this post, and you can watch the full session below.

From a simpler time to a complex ecosystem

The software world today is massive and complex:

• Ecosystems contain hundreds of thousands of projects

• Dependencies pull in complex graphs of additional dependencies

• Releases ship continuously

• Attackers iterate as fast as maintainers

Software is now built on software that is built on software. Every dependency introduces more dependencies. What ships to production is the result of a complex, interconnected system involving package registries, CI systems, developer workstations, and automation, and the attack surface has expanded accordingly.

The shift in attacker strategy

Early supply chain attacks focused on exploiting vulnerabilities in production systems. A high-severity CVE in a popular library could expose sensitive data.

Log4Shell is a defining example. CVE-2021-44228 affected an enormous portion of the internet. Attempted exploitation targeted a large percentage of business networks globally. Hundreds of millions of devices were affected, but many attacks resulted from the vulnerability.

However, attackers discovered a more fruitful strategy. Instead of exploiting known vulnerabilities, they began injecting malicious code upstream into the software supply chain itself.

Where malware enters the build

Modern supply chain attacks frequently target one or more of these entry points:

1. Compromised maintainer accounts

If an attacker gains access to a maintainer account, they can publish a malicious version of a legitimate package. Consumers upgrade as usual and unknowingly install the malicious code. This is what happened in the recent axios attack, where a maintainer's credentials were compromised and used to publish malicious versions.

2. Dependency confusion

In dependency confusion attacks, an attacker publishes a package with the same name as an internal dependency to a public registry. If build systems prefer the public version, they pull the malicious package instead of the intended private one. We saw this happen before in PyTorch.

3. Preinstall and postinstall scripts

In the JavaScript ecosystem, preinstall and postinstall scripts can execute arbitrary code during package installation. That code runs in the context of the developer machine or CI environment. A very famous recent example of this is the recent Shai-Hulud attack.

4. Native code in unexpected places

Python wheels can include native extensions. Java artifacts may embed JavaScript web assets. Visual Studio Code extensions rely heavily on JavaScript packages.

Ecosystems overlap and blend. A compromise in one language can affect others. The boundaries between ecosystems are thinner than most teams assume.

5. Typosquatting and slopsquatting

Typosquatting involves publishing a package with a name that closely resembles a popular project. Slopsquatting extends this concept in the age of AI coding assistants, where models may hallucinate package names that attackers quickly register. Most of these attacks are found early and prevented, but some always slip through, even if just for a short time.

Scale and blast radius

The scale of modern ecosystems amplifies every mistake.

As of mid-2025, PyPI alone hosts over 750,000 projects and serves 4.6 billion downloads daily. The npm Registry and Maven Central operate on a much larger scale. Each download is a trust decision.

When malware replaces a popular package, the blast radius is enormous. A single compromised release can propagate through CI systems, developer laptops, container builds, and production images in hours.

In many cases, the build system becomes a more attractive target than production. It has:

• Access to source code

• Access to signing keys

• Credentials for registries and cloud providers

• Broad network connectivity

Compromising the build can yield more leverage than exploiting a single runtime vulnerability.

The trust problem

Every time a developer runs npm install or pip install, they execute code from a remote source. That code may include scripts that run during installation. It may include compiled native components. It may include secondary payloads that activate only under certain conditions.

Visibility into package contents is not enough.

You cannot reliably determine whether a package is safe solely by inspecting its metadata. You need verifiable proof of how it was built.

Without knowing who built the artifact, from which source, or using what process, you are relying on trust that can be broken silently.

Trends

Recent attacks show several patterns:

• Secondary payloads that activate only after installation

• Malware mixed with legitimate functionality

• Self-deactivation after initial compromise to avoid detection

• Cross registry publication strategies

• Attacks targeting cryptocurrency and CI infrastructure

• Automation and AI are used to generate more convincing malicious packages

AI lowers barriers and increases attackers' productivity. It can generate plausible README files, documentation, and code that looks legitimate. It can scale phishing and package publication campaigns.

Registries and index operators are under heavy pressure. They scramble to detect and remove malicious packages, often after downloads have already occurred.

Why building from source changes the equation

Since a main problem is prebuilt artifacts from public registries, a defensive strategy can focus on controlling the build process itself and trusting only the maintainers and the source code. Building from source introduces several key advantages:

• You control the exact source code that is compiled

• You generate provenance that describes how the artifact was created

• You can attach a software bill of materials to each output

• You can apply curated patches and CVE fixes

That’s exactly what we do in the Chainguard Factory, and there is a path for you to get started. Chainguard Libraries are available for Python, JavaScript, and Java. Chainguard Libraries also includes SBOM and provenance information and is ready for you to use in your application development, no matter what build and packaging tool you use.

Ready to secure your production systems and developer workstations in an era of accelerating attacks on language ecosystems? Reach out about Chainguard Libraries and protect your organization’s software supply chain.

Catch all the sessions from Assemble on-demand here.