flawopen.com/Incidents/SolarWinds SUNBURST
A locksmith is trusted by thousands of buildings to service their locks, and sends out sealed, stamped service kits every few months. Someone breaks into the factory where the kits are assembled and adds a small extra part to each one — before the seal and the stamp go on. Every building receives a kit that is genuinely, verifiably from the locksmith, and installs it. The seal was never broken, because the tampering happened before the sealing.
In December 2020 the security firm FireEye, investigating its own breach, identified a backdoor inside SolarWinds Orion — a widely deployed IT infrastructure monitoring platform. The malicious code, named SUNBURST, had been inserted into a legitimate Orion component and distributed through SolarWinds' normal, digitally signed software updates between roughly March and June 2020.
Around 18,000 customers are believed to have installed a trojanised update. The attackers then selected a much smaller set — including US federal agencies and major technology companies — for hands-on follow-up intrusion. The activity was subsequently attributed by the US government to a Russian state intelligence service.
Rather than committing malicious code where a reviewer might see it, the attackers positioned themselves inside the build environment and injected the backdoor as the software was being compiled. The source repository remained clean. Developers reading the code saw nothing wrong, because nothing was wrong in the code.
Because tampering occurred before signing, the shipped artefact carried a valid SolarWinds signature. Every downstream integrity check — the ones organisations are told to rely on — passed correctly. Signature verification confirms that a vendor produced an artefact; it says nothing about whether that vendor's factory was under someone else's control.
SUNBURST stayed dormant for roughly two weeks after installation, checked for analysis tooling and security products before activating, avoided specific environments, and disguised its command-and-control traffic to resemble the Orion product's own legitimate protocol. Monitoring software talking to its vendor's infrastructure is not anomalous.
A separate flaw in Orion, tracked as CVE-2020-10148, allowed authentication bypass to the product's API and was also used in related activity.
Orion's function is to monitor an organisation's entire infrastructure. To do that it needs broad network reach and high-privilege credentials for the systems it watches. Compromising it therefore granted the attackers a position that would have taken enormous effort to build directly.
This generalises to an uncomfortable rule: the software you trust most is your largest single point of failure. Monitoring agents, endpoint protection, backup software, configuration management and CI runners all share the same profile — installed everywhere, running with elevated privilege, and rarely treated as a threat.
Not by patching or configuration alone — the update was legitimate and correctly signed. Customers could have limited the consequences: restricting Orion's outbound connectivity, segmenting its network access, and scoping the credentials it held would each have constrained what the backdoor could accomplish.
Both are supply chain compromises, but the access route differs. XZ was reached through social engineering of an open-source project's governance; SUNBURST was an intrusion into a commercial vendor's internal build infrastructure. The shared lesson is that the artefact's journey from source to customer is itself an attack surface.