All case studies

Where keeping it cost them

SolarWinds

Distributed a compromised update to 18,000 customers

A build system with excessive permissions and too many trusted components turned one compromised dependency into an update every customer installed.

Removed: nothing. The build system kept permissions broad enough, and trust in its components loose enough, that a compromised link in the chain reached production without anyone having to approve it.

Outcome: code injected through that dependency was automatically trusted and distributed to 18,000+ customers.

The SolarWinds breach succeeded partly because build systems had excessive permissions and trusted too many components. A compromised build dependency could inject code that was automatically trusted and distributed to 18,000+ customers.

Nothing sophisticated was required at the far end. The build system did what build systems do — took what it was handed and shipped it. Every permission it did not need was another way in that nobody had to argue for, and the number of components it trusted was the number of chances to get it wrong.

The architecture made it easy in a second way: build servers were reachable from developer workstations and were not segmented from distribution, so a compromised workstation could move laterally into the pipeline that signed and shipped the product.

Source: CISA, Advanced Persistent Threat Compromise of Government Agencies, Critical Infrastructure, and Private Sector Organizations (17 December 2020, revised 15 April 2021)