The Supply Chain Attack Problem Is Getting Worse

In December 2020, security researchers discovered that SUNBURST malware had been distributed inside a legitimate software update from SolarWinds, a company whose network monitoring software was used by thousands of organizations including the US Treasury Department and Department of Homeland Security. The attackers had compromised SolarWinds' build pipeline and inserted their code months before the malicious update was distributed. By the time the intrusion was discovered, roughly 18,000 organizations had installed it.

The attack was sophisticated, patient, and largely undetectable using traditional security approaches. It also taught the security industry a lesson it has been slowly internalizing ever since: the software supply chain is an attack surface, and it's a badly defended one.

Why This Vector Is Attractive

A direct attack on a hardened target — a bank, a government agency, a major tech company — requires penetrating perimeter defenses that have received years of investment. There are monitoring systems, threat intelligence, skilled security teams, and incident response procedures.

The organizations that provide software to those targets are often smaller, less well-resourced, and less hardened. They also have trusted, established channels directly into their customers' systems: software update mechanisms that automatically deploy code, libraries that run at high privilege, and development tools that execute during the build process.

Compromising a software vendor can give an attacker everything a direct compromise would provide, without ever touching the defended perimeter.

The Open Source Dimension

The problem is compounded by the software ecosystem's dependence on open source packages. A typical JavaScript web application might have hundreds of transitive dependencies — packages that depend on other packages, which depend on other packages, down through multiple layers. The code that actually runs is often authored by dozens or hundreds of individuals, many of them anonymous contributors to small utility libraries.

An attacker who can publish a malicious update to a widely-used package — either by compromising a maintainer's account or by taking over an abandoned package — can inject code into thousands of downstream applications. This has happened repeatedly: the event-stream incident, node-ipc, colors, faker, and others.

What's Being Done

The response has been multi-pronged, though none of the individual measures is sufficient:

Software bills of materials (SBOMs) — structured inventories of every component in a software artifact — are now required in US federal software procurement. They don't prevent attacks but make it possible to assess exposure quickly when a vulnerability is discovered.

Package signing has become more widespread. PyPI now requires publishers to sign packages with Sigstore, and npm has improved its provenance attestation. These mechanisms make it harder to distribute malicious packages undetected.

Reproducible builds — the discipline of ensuring that the same source code always produces bit-for-bit identical binaries — lets users verify that the binary they're running actually corresponds to published source code. Adoption is growing but still limited.

Dependency auditing tools scan dependency trees for known-vulnerable packages. They're widely used but only effective against known threats.

The Structural Problem

None of these defenses address the underlying issue: software ecosystems are structured around implicit trust between strangers, with minimal verification of identity or intent. A package that has been trustworthy for five years can change hands without users being notified. A maintainer account can be compromised silently.

Building defenses against supply chain attacks ultimately requires changing assumptions that have been built into package ecosystems for decades. That's a slower process than writing new tooling. The attacks are moving faster.