Software Supply Chain Attacks: When Your Build Runs Malware

A software supply chain attack can compromise your application without exploiting a flaw in your own code. It targets code you never wrote and never read, but compile every day.

The danger is timing. Bad code in a dependency can run during the build, before your application is deployed and sometimes before its tests begin.

What Is a Software Supply Chain Attack?

It is any attack that reaches you through code or tooling you trust rather than code you own.

Most projects pull in hundreds of packages. You choose a handful. The rest arrive as transitive dependencies, dragged in by the ones you picked. Nobody reviews them.

Attackers work that gap three main ways:

• Account takeover. A maintainer's account is hijacked and a bad version ships under a trusted name.
• Typosquatting. A package named one character off the real one.
• Dependency confusion. A public package shadows your internal one.

How Does a Build-Time Attack Work?

Package managers let dependencies run code during installation or compilation. That feature exists for good reasons. It also hands an attacker execution on your machine.

The chain is short:

1. The attacker gets a package published under a trusted name.
2. That package adds one new dependency.
3. The new dependency carries a build or install script.
4. A developer or CI runner builds the project.
5. The script runs with that user's permissions.

Nobody clicked anything. Nobody deployed anything. The build itself was the delivery.

Why Does It Matter?

A build machine is the worst place to hand an attacker code execution. It holds registry tokens, cloud keys, signing keys, and source for every branch.

Advisory-based dependency scanning is not enough on its own. A newly published malicious version may appear before a vulnerability advisory exists.

Real-World Example: The arrayref Crate Incident

On 20 August 2026, three Rust crates were published with malicious releases: arrayref 0.3.10, internment 0.8.7, and append-only-vec 0.1.9. The Rust Security Response Team said the author was not believed to be acting maliciously and that their computer or credentials were likely compromised.

Each release added a single line to its manifest: a dependency on proc-macro1, a typosquat of the widely used proc-macro2. The attacker first published a clean copy of that package earlier the same day, then released a version carrying the malicious payload.

Its build script rebuilt a payload host and a command-and-control address from base64 fragments. It then fetched a second-stage binary with certificate checks switched off and launched it. A fresh cargo build, cargo check, or cargo test that pulled and built the malicious dependency could execute the payload.

The malicious versions were removed quickly. arrayref 0.3.10 was online for about 86 minutes, internment 0.8.7 for 90 minutes, and append-only-vec 0.1.9 for 107 minutes. RUSTSEC-2026-0260 records no evidence of actual usage of the compromised arrayref release. The widely quoted 245 million figure is arrayref's all-time download count, not the number of poisoned installs.

This was a near miss, caught by researchers at Nextron Systems. The mechanism should worry you, not the body count.

How to Prevent Software Supply Chain Attacks

Assume a dependency will turn hostile one day. Design the build so it does not matter much.

Control what you pull:

• Commit lockfiles and enforce them. cargo build --locked fails if the lockfile would change. Most ecosystems have an equivalent.
• Use vendored, mirrored, or pre-fetched dependencies for offline builds. Cargo's --frozen combines --locked and --offline, preventing lockfile changes and network access during the build.
• Do not auto-upgrade. Let new versions age first.
• Review dependency diffs. A new transitive package needs a human to look.

Harden the build:

• Disable install and build scripts where your ecosystem allows it.
• Run builds in ephemeral containers, destroyed afterwards.
• Apply an egress allowlist. A compiler rarely needs to reach an arbitrary IP.
• Keep long-lived secrets out of build jobs. Use scoped, short-lived tokens.

Watch for trouble:

• Generate an SBOM so you can answer "are we affected" in minutes.
• Monitor advisory feeds for your ecosystem.
• Alert on outbound connections from build agents.

Also Read: Application Security vs DevSecOps

What Should Security Testing Cover?

Ask your testers to attack the pipeline, not just the app:

• What a build job can reach on the network
• Which secrets are readable from inside a build
• Whether CI enforces the lockfile or silently resolves new versions
• What a stolen CI token unlocks in your cloud and registry

How OraSec Can Help

OraSec tests build pipelines the way an attacker would use them. We check what a poisoned dependency could reach and how far one build-time execution travels. You get a proven blast radius and a fix order.

Conclusion

A software supply chain attack does not need your application to be vulnerable. It needs your build to be trusting.

Pin your dependencies. Strip secrets from build jobs. Cut egress. Treat every build machine as if it already ran something hostile. Then test that.

FAQs

Does dependency scanning stop supply chain attacks? Not on its own. Traditional SCA tools often rely on known advisories, while a newly published malicious package may have no advisory yet.

Are lockfiles enough? They stop silent version drift, a large share of the risk. They do nothing if you deliberately upgrade to a poisoned release.

Is one ecosystem safer than another? No. npm, PyPI, and Cargo all allow code to run at install or build time. The lesson transfers.

What if a bad package reaches our build? Treat the build host as compromised. Rotate every token and key it could reach, then rebuild.

Does an SBOM prevent attacks? It prevents slow responses. When an advisory drops, an SBOM tells you in minutes whether you shipped the affected version.