SolarWinds, 2020: the attack came through the build system.

SolarWinds' own filing is precise about where the compromise happened (SolarWinds Form 8-K): the vulnerability "was introduced as a result of a compromise of the Orion software build system and was not present in the source code repository of the Orion products." The malicious code was not in the repository at all: it was added somewhere between source and shipped release.

CISA's advisory AA20-352A names the affected versions (including Orion Platform 2019.4 HF5 and 2020.2 HF1), the malicious DLL, and the SUNBURST malware it delivered, with initial compromise from at least March 2020. It also records that this was not the only way in: CISA saw evidence of other initial access vectors, including password guessing, password spraying and inappropriately secured administrative credentials reached through external remote access services, and abuse of SAML tokens after the actor compromised a SAML signing certificate.

For a software supplier the lesson is about the integrity of the pipeline from commit to release. For a customer it is about trust in a vendor's updates: a legitimate update from a known supplier was the carrier.

• Reach: SolarWinds had over 300,000 customers; it wrote to about 33,000 Orion maintenance customers and estimated that fewer than 18,000 had installed an affected version.
• Government response: CISA published AA20-352A on 17 December 2020, addressed to government agencies, critical infrastructure and private sector organisations.
• SEC: on 30 October 2023 the SEC charged SolarWinds and its CISO, alleging they overstated the company's cybersecurity practices and understated known risks from its October 2018 IPO to the December 2020 announcement. These were allegations and were contested; this page does not track the later course of the litigation, so check the SEC's case materials for its current status.

• Source and change control: the GitHub integration checks default and long-lived branch protection, required pull-request reviews, required status checks, a CI workflow, CODEOWNERS, signed commits required, independent approval on merged pull requests, and two-factor authentication for the organisation.
• Code entering the pipeline: the SDK runs static analysis, secret scanning and dependency checks in your CI, with a pre-push gate.
• Privileged accounts: Okta and Google Workspace super-admin counts, GCP project owner count and personal accounts holding Owner or Editor, AWS root account MFA.
• Suppliers: a vendor register where you record suppliers, what they access and when you reviewed them. Entries are maintained by your team; TryTrustable does not score or monitor vendors automatically.

TryTrustable does not verify the integrity of build artefacts or compare shipped binaries with source. Branch and review controls protect the repository; the SolarWinds case shows the build system needs its own controls as well.

These are the checks TryTrustable runs today. None of them is a claim about what would have happened in this incident: they test whether the control is in place in your environment, continuously, and record the result as audit evidence.

• CISA advisory AA20-352A: Advanced persistent threat compromise of government agencies, critical infrastructure, and private sector organizations (17 December 2020)
• SolarWinds Corporation, Form 8-K filed 14 December 2020
• SEC press release 2023-227: SEC charges SolarWinds and chief information security officer (30 October 2023)

Every figure on this page is taken from the official documents listed here, read in October 2026. Regulatory findings quoted are the regulator's; where a company neither admitted nor denied them, or where proceedings are still open, the page says so. Not legal advice.

More case studies: all breach case studies · Research