For decades, the software security model was built on a simple premise: verify the vendor, verify the certificate, trust the update. SolarWinds shattered that model in a way that is still reshaping how organisations think about trust. This article breaks down exactly how the attack worked, why it succeeded despite the victims having mature security programmes, and the specific controls that every organisation must now have in place — informed by the single most instructive supply chain attack in cybersecurity history.
SolarWinds, 2020
FireEye, December 2020
Cyentia Institute, 2021
What Actually Happened
The SolarWinds attack was not a brute-force breach. It was a precision operation that exploited one of the most trusted channels in enterprise IT: the software update pipeline. Here is the sequence.
The exact initial vector is still disputed — likely a phishing attack or compromise of a developer credential. The attackers spent months learning the build environment before touching anything.
The attackers modified the source code of SolarWinds Orion — a network monitoring platform used by Fortune 500 companies and US government agencies — to include a sophisticated backdoor. The modification was designed to survive code review: it looked like legitimate code, was placed in an obscure file, and included a 2-week dormancy period before activating.
SolarWinds built, signed with their legitimate digital certificate, and distributed updates containing SUNBURST to approximately 18,000 customers. Every customer who applied the update installed the backdoor — through exactly the same process they would use for any routine security update.
Of the 18,000 organisations that installed the backdoor, the attackers actively exploited approximately 100 — selected based on strategic interest. Targets included the US Treasury, Department of Homeland Security, FireEye, Microsoft, and dozens of other high-value organisations.
FireEye, a leading cybersecurity company and one of the victims, published a blog post disclosing that their red team tools had been stolen. This set off the investigation that led to the discovery of SUNBURST three days later.
Why This Attack Was Fundamentally Different
Most security programmes are designed to detect attackers doing attacker things: scanning ports, exploiting vulnerabilities, moving laterally with stolen credentials. The SolarWinds attack did none of these things in the initial stage. It did legitimate things — installing a legitimate update, activating through a legitimate domain lookup, communicating with a command-and-control server that mimicked legitimate Orion traffic patterns.
"The SolarWinds attackers did not exploit a vulnerability in the traditional sense. They exploited trust — the trust every organisation places in its software vendors, in signed updates, in the security of their suppliers' build pipelines."
Most of the 18,000 organisations that installed SUNBURST had mature security programmes. Many had ISO 27001 certification. Several were cybersecurity companies. Their controls were not deficient — they were simply not designed to detect malicious code arriving through a trusted, signed, vendor-endorsed software update channel. That is the lesson.
The Kill Chain — Where It Could Have Been Stopped
Every stage of the kill chain had at least one control that would have interrupted it. Understanding where those gaps were is the starting point for building defences against the next SolarWinds.
- 1Build pipeline integrity (would have prevented insertion)The SUNBURST backdoor was injected into the build pipeline — the automated process that compiles source code into an installable package. A build environment with strict integrity controls — reproducible builds, cryptographic verification of source code before compilation, separation of build systems from corporate networks — would have either prevented the injection or detected the modified output before signing.
- 2Code signing policy (would have flagged the anomaly)SolarWinds' legitimate code signing certificate was used to sign the malicious update — making it indistinguishable from legitimate updates at the certificate level. A certificate transparency log and anomaly detection on signing operations (unusual files being signed, signing outside normal windows) could have flagged the suspicious signing event.
- 3Network anomaly detection (would have detected earlier)SUNBURST used DNS requests to avsvmcloud.com as its command-and-control channel. This was designed to look like legitimate Orion activity — but the domain was unusual and the DNS patterns were subtly anomalous. Organisations with mature network traffic analysis and DNS monitoring detected the malicious activity faster than those relying only on signature-based detection.
- 4Zero Trust architecture (would have limited blast radius)In environments with Zero Trust principles — where Orion would only have the specific network access it needed for its legitimate function — lateral movement was significantly harder. Attackers in Zero Trust environments still gained a foothold but found it much harder to pivot to high-value systems. The environments hit hardest were those where Orion had broad network access consistent with its administrative function.
6 Lessons Every Security Team Must Apply
Verify the build, not just the binary
A signed binary proves the binary was signed by the vendor — not that the build pipeline producing it was secure. Implement build provenance verification. The SLSA framework provides a practical maturity model for securing the build pipeline itself.
Know your software components (SBOM)
A Software Bill of Materials is the inventory that tells you exactly which components are in every application in your environment. When the next SolarWinds happens, the difference between hours and weeks of response time will come down to whether you can answer "are we affected?" immediately.
Vendor risk management is not enough
SolarWinds would have passed any vendor security questionnaire. ISO 27001 certification, mature security programme, Fortune 500 customer base. Traditional TPRM did not — and could not — detect a compromised build pipeline. Supply chain security requires technical controls, not just contractual ones.
Treat software update channels as attack vectors
Every automatic software update is a potential supply chain attack vector. This does not mean disabling updates — it means monitoring what updates install, where they come from, and what network behaviour changes immediately after installation. Anomalous post-update behaviour is a detection signal.
Segment privileged management tools
Orion was powerful because it was a network management platform with broad access. Every privileged management tool in your environment — RMM, SIEM, endpoint management — is a high-value supply chain target. These tools should be network-segmented, zero-trust-enabled, and closely monitored for anomalous behaviour.
Assume breach in your detection model
The 14-month dwell time happened because defenders were looking for attackers doing attacker things. Assume that a determined adversary is already inside and look for anomalous behaviour by trusted processes and legitimate credentials — not just for obvious indicators of compromise.
The SBOM Imperative — Your Most Urgent Action
Of all the lessons from SolarWinds, the Software Bill of Materials is the most immediately actionable. An SBOM is a machine-readable inventory of every software component in an application — every library, framework, and dependency with its version and source.
When Log4Shell was disclosed in December 2021 — a critical vulnerability in a logging library used by millions of applications — organisations with SBOMs were able to determine their exposure in hours. Organisations without them spent weeks manually scanning, guessing, and discovering affected systems after the fact. The same dynamic applies to supply chain attacks: if you know what is in your software, you can respond to a supply chain compromise immediately rather than reactively.
The US Executive Order 14028 on Improving the Nation's Cybersecurity (2021) mandates SBOMs for software sold to the federal government. The EU Cyber Resilience Act (CRA) introduces SBOM requirements for products sold in the EU market. DPDP Act Section 8(5) reasonable safeguards are increasingly interpreted to include supply chain transparency. If you sell software, SBOM is becoming mandatory — not optional.
Supply Chain Security and Compliance Frameworks
| Framework | Supply Chain Control | What Is Required |
|---|---|---|
| ISO 27001 | A.5.19 — Information security in supplier relationships; A.5.21 — ICT supply chain management | Documented supplier security requirements, contractual controls, continuous monitoring of supplier security posture |
| SOC 2 | CC9.2 — Vendor and business partner risk management | Vendor risk assessment processes, contractual security obligations, monitoring of vendor compliance |
| NIST CSF | ID.SC — Supply chain risk management function | Supply chain risk assessment, supplier vetting, response planning for supply chain compromises |
| DPDP Act | Section 8(5) — Reasonable security safeguards | Supply chain security increasingly interpreted as part of reasonable safeguards for data processors |
| EU CRA | Article 13 — Obligations of manufacturers | SBOM required for products with digital elements sold in EU market; vulnerability handling policy mandatory |
Frequently Asked Questions
The SolarWinds supply chain attack involved nation-state attackers compromising SolarWinds' software build pipeline and inserting a backdoor called SUNBURST into the Orion platform update. Approximately 18,000 organisations downloaded the malicious update, trusting it because it was signed with SolarWinds' legitimate digital certificate. The attackers had access to some victim environments for up to 14 months before discovery.
A direct attack targets your own systems — your firewall, your applications, your employees. A supply chain attack targets a vendor or software component that you trust and install in your environment. The attack reaches you through the trust relationship. This makes supply chain attacks particularly dangerous because your security controls are not designed to detect malicious content arriving through a trusted, signed, verified update channel.
An SBOM is a machine-readable inventory of every software component in an application — libraries, frameworks, dependencies, and their versions. In a supply chain attack scenario, an SBOM allows you to rapidly determine whether a compromised component is present in your environment, which systems are affected, and what the blast radius might be. Organisations with SBOMs answered the Log4Shell question in hours; those without spent weeks scanning.
SLSA (Supply chain Levels for Software Artifacts) is a security framework that defines four levels of supply chain security maturity — from basic build integrity through fully verified, tamper-resistant provenance. At SLSA Level 4, the build process is hermetic, fully audited, and the provenance is cryptographically verified. The SolarWinds attack occurred in a build environment with no SLSA-equivalent controls.
ISO 27001:2022 Annex A.5.19 and A.5.21 directly address supply chain risk — documented supplier security requirements, contractual controls, and continuous monitoring. SOC 2 CC9.2 requires vendor risk management. These controls require organisations to assess and monitor suppliers, but the SolarWinds attack showed that even mature supplier controls cannot catch a compromised software update channel without technical build pipeline integrity controls.