← Field Notes · Threats
When the Update Is the Attack: Supply Chain Compromise
The SolarWinds breach showed how attackers can skip the target and compromise the software everyone already trusts instead.
In December 2020, the security firm FireEye disclosed that it had been breached, and in the course of investigating its own compromise, discovered something far larger: attackers had inserted malicious code into a routine software update for Orion, a network-monitoring product made by a company called SolarWinds, used by tens of thousands of organizations including large parts of the United States federal government. Roughly 18,000 organizations downloaded the compromised update. A far smaller, more selectively targeted number were then actually exploited further by the attackers, who were widely attributed by U.S. officials to Russian intelligence.
What made the SolarWinds breach different from a typical intrusion was where the attackers spent their effort. Rather than trying to break into thousands of individual targets one at a time, they compromised a single software vendor that thousands of targets already trusted enough to run its code with elevated system privileges and automatically install its updates. The update mechanism itself, the exact process organizations rely on to stay secure by staying current, was the delivery vehicle.
This is what security researchers mean by a supply chain attack: compromising a trusted intermediary, a software vendor, a code library, a hardware component manufacturer, rather than the ultimate target directly. It is a harder attack to pull off, requiring access to a vendor's build systems or code repositories, but it pays off at a scale that direct intrusion rarely matches, and it exploits a form of trust that is difficult to remove from modern computing without also removing the convenience that makes automatic updates worth having in the first place.
SolarWinds was not the first example and has not been the last. Attacks on open-source package repositories, where a widely used code library is compromised or a malicious package is published under a deceptively similar name to a popular one, have become common enough that major package managers now run automated scanning specifically looking for this pattern. The core vulnerability is structural, not specific to any one vendor: modern software is assembled from dozens or hundreds of dependencies that a development team did not write and, realistically, cannot fully audit.
There is no clean technical fix for this, only mitigations: verifying cryptographic signatures on updates, minimizing the number of dependencies a system trusts, and treating a vendor's security practices as part of the actual attack surface rather than someone else's problem. It is also the strongest existing argument for open, auditable code as a category, not a specific software's marketing claim, since a supply chain compromise inserted into a project whose source is public and actively read by outsiders has a meaningfully shorter path to discovery than one inserted into a closed binary nobody outside the vendor can inspect.