SolarWinds — a supply-chain attack
This is a real, named company's story, drawn from public sources: SolarWinds' own SEC filings and blog, CrowdStrike's and Microsoft's technical writeups, FireEye/Mandiant's incident disclosure, CISA's directive, and the joint U.S. government attribution statement. The short version undersells it: in early 2020, someone inserted a backdoor into SolarWinds' Orion network-monitoring software — not by editing the source code in GitHub, but by tampering with the build process that turns that source code into a shipped binary — and the result was a fully, legitimately signed update that roughly 18,000 organizations installed voluntarily, trusting it precisely because it looked exactly like every other Orion update they'd ever installed. This page is the mechanics of how that worked, what it took to notice, and — the part that matters most for this course — a precise, honest answer to which of the controls taught elsewhere here would actually have caught it.
Imagine a printing press that everyone trusts completely, because every book it's ever printed has been exactly what the author wrote. Someone sneaks into the print shop at night — not to change the author's manuscript, which is still sitting untouched in the drawer — but to adjust the printing press itself, so that one extra page gets slipped in only while it's printing, and the machine cleans itself up afterward so the manuscript still reads clean the next morning. Every book still gets the publisher's real seal on the cover, because the seal is stamped after printing and the seal-stamper has no idea a page was added. Readers trust the seal. The seal is genuine. It's just answering the wrong question.
Orion: monitoring software running inside tens of thousands of networks
☺ Like you're 10: The tool that watches everything else on a network is itself a single point almost everyone trusted without a second thought.
SolarWinds is an Austin, Texas-based vendor whose flagship product, the Orion Platform, is IT infrastructure and network-monitoring software: it watches servers, routers, and applications and tells administrators when something's wrong. That job requires broad, often privileged access into the networks it monitors — which is precisely what made it such a valuable target. Per SolarWinds' own December 2020 SEC filing, the company had more than 33,000 Orion customers at the time, and — in a detail that reads very differently in hindsight — SolarWinds' own pre-breach marketing had claimed that 425 of the US Fortune 500 used its products. That figure quietly disappeared from SolarWinds' website within days of the breach becoming public.
Of those 33,000-plus customers, SolarWinds' filing states that fewer than 18,000 organizations actually installed a version of Orion containing the compromised update between March and June 2020. That gap — 33,000 licensed, 18,000 exposed — is the first funnel in a story that keeps narrowing at every stage, which is exactly the shape the schematic further down this page is built to show.
SUNSPOT: compromising the build server, not the source code
☺ Like you're 10: Nobody edited the recipe in the cookbook — they snuck into the kitchen and swapped one ingredient only while the cake was actually being baked, then put everything back exactly as it was.
The genuinely novel part of this attack — the part every later course page on build integrity is ultimately arguing against a repeat of — is where the tampering happened. Per CrowdStrike's January 2021 technical report, "SUNSPOT: An Implant in the Build Process," the attackers didn't touch SolarWinds' source code repository at all. Instead, they planted a piece of malware, since named SUNSPOT, directly on SolarWinds' build server. SUNSPOT sat quietly, watching running processes, until it detected MsBuild.exe compiling the specific Orion project. At that exact moment — and only that moment — it silently swapped one source file involved in the build for a backdoored version, let the compiler run against the tampered file, and then restored the original, untouched file immediately afterward. CrowdStrike's report also documents that SUNSPOT computed hashes of files it touched and had safeguards against crashing the build, specifically to avoid drawing an engineer's attention with a broken or unusually slow compile. (Verify the precise technical detail against CrowdStrike's own report — this page summarizes it, not reproduces it.)
| Codename | What it was | Where it ran |
|---|---|---|
| SUNSPOT | The build-server implant that watched for the Orion compile and swapped a source file mid-build | SolarWinds' internal build infrastructure |
| SUNBURST | The resulting backdoor, compiled into SolarWinds.Orion.Core.BusinessLayer.dll and shipped inside signed updates | ~18,000 customer environments that installed the update |
| TEARDROP / RAINDROP | Memory-only loaders that deployed a customized Cobalt Strike Beacon on selected, manually chosen targets | A much smaller set of "of interest" victims, hands-on-keyboard |
| SUPERNOVA (unrelated) | A separate webshell exploiting a distinct Orion API authentication-bypass flaw — a different, opportunistic actor, not part of this campaign | A small number of internet-facing Orion servers |
Sit with why that mechanism matters more than the malware itself: a source-code review, a pull-request diff, or a SAST scan run against SolarWinds' git repository would have found nothing wrong, because there was nothing wrong in the repository. The tampering happened in the gap between "the code an engineer reviewed" and "the artifact that got compiled and signed" — a gap that most of this course's earlier pipeline-security lessons quietly assume doesn't need separate defending, because they're built around scanning source and scanning dependencies, not verifying that the build process itself is telling the truth. Zero trust for pipelines covers the general fix for exactly this class of problem — the build server as untrusted infrastructure rather than an implicitly trusted extension of the codebase — and names this incident as the 2020 predecessor to the 2023 CI/CD compromises that page covers mechanically in full.
SUNBURST: a legitimately signed backdoor
☺ Like you're 10: A real, valid seal on the box tells you the box came from the factory — it doesn't tell you nobody messed with what went into the box before it was sealed.
Because SUNSPOT's tampering happened before compilation, the resulting DLL went through SolarWinds' normal build-and-sign pipeline like any other legitimate release. Public reporting places the first trojanized build at around February 20, 2020, digitally signed with SolarWinds' own, genuine code-signing certificate — no certificate was stolen, no signature was forged. The malicious updates (Orion Platform versions in the 2019.4 HF 5 through 2020.2.1 HF 1 range) then went out through SolarWinds' official update servers between March and June 2020, indistinguishable at the file level from every clean update that came before or after.
"It's signed" and "it's safe" are two different claims, and this incident is the textbook case for why. A signature answers exactly one question: did this bit-for-bit artifact come out of a process this certificate's owner controls? It says nothing about whether that process was itself trustworthy at the moment this specific artifact was produced. Sigstore & cosign and modern SLSA-style build provenance push past plain code-signing for exactly this reason — an attestation that binds the shipped artifact's hash to the exact source commit and build environment that produced it would have created a detectable mismatch here: the signed binary's provenance wouldn't match what was actually sitting in the reviewed git history. A bare signature, the kind SolarWinds had in 2020 and the kind most vendors still ship with today, can't make that comparison at all.
Tradecraft: a two-week nap, and traffic dressed as telemetry
☺ Like you're 10: The intruder didn't run straight for the valuables — it waited quietly for almost two weeks first, then whispered instead of shouting, so nothing about it looked unusual.
SUNBURST's design shows an attacker optimizing hard for one thing: staying undetected for as long as possible, at a scale where thousands of security teams might otherwise have stumbled onto it by accident. After installation, the backdoor waited roughly twelve to fourteen days before making its first outbound call — long enough to outlast most automated sandbox and dynamic-analysis windows, which typically only observe a sample for minutes, not weeks. When it did reach out, its command-and-control traffic was disguised to resemble normal Orion Improvement Program (OIP) telemetry — the same kind of "phone home" diagnostic data Orion legitimately sends — using subdomains under avsvmcloud[.]com generated to blend into ordinary DNS noise rather than stand out as an obvious indicator of compromise. Before fully activating, it also checked the local environment for signs it was running inside a malware-analysis sandbox or on a machine tied to certain security vendors, and quietly declined to proceed if it found one.
That funnel is the point. SUNBURST didn't activate identically everywhere — the attackers appear to have used the initial, broad foothold across roughly 18,000 organizations mainly for reconnaissance, then manually and selectively escalated against a much smaller set of targets they judged worth the risk of exposure. That's a deliberate operational choice: activating everywhere increases the odds someone notices sooner. Staying quiet almost everywhere, and going hands-on-keyboard only where it mattered, is what stretched this campaign's undetected run to roughly nine months after the malicious updates first shipped.
Discovery: found because the attackers breached the wrong company
☺ Like you're 10: The break-in was only discovered because the burglars also broke into a security company, and that company noticed something was missing.
SUNBURST wasn't found by SolarWinds, by a customer's SOC, or by an automated scanner. On December 8, 2020, the incident-response firm FireEye (now part of Mandiant) disclosed that it had itself been breached, and that a set of its own Red Team assessment tools had been stolen. Investigating how that happened, FireEye traced the intrusion back to a trojanized SolarWinds Orion update running inside its own network — and, working with SolarWinds and the U.S. government, disclosed the full scope publicly around December 13, 2020. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) responded the same day with Emergency Directive 21-01, ordering every federal civilian executive-branch agency to immediately disconnect or power down any instance of SolarWinds Orion — an unusually blunt instruction, reflecting how little confidence anyone had, in the first hours, in being able to distinguish a compromised Orion install from a clean one by any means short of pulling the plug.
Notice what that timeline implies: had the attackers not also gone after FireEye specifically — and had FireEye not investigated its own anomaly (an employee's second authentication factor being registered without their knowledge) as rigorously as it did — there's no clear reason SUNBURST's roughly nine-month run would have ended when it did. Discovery here wasn't the product of any control this course teaches catching a bad build. It was one of the highest-skilled incident-response teams on Earth turning its own forensic scrutiny — the same discipline Foxy hosts elsewhere in this course — on itself, and refusing to accept a tidy explanation for one odd login.
Attribution, and who was actually behind it
☺ Like you're 10: Investigators are confident about who did it, but "confident" and "proven in court" aren't the same sentence, and it's worth knowing the difference.
A joint statement from the FBI, CISA, the Office of the Director of National Intelligence, and the NSA — issued January 5, 2021 as the "Cyber Unified Coordination Group" — assessed the campaign as "likely Russian in origin." In April 2021, the U.S. government went further, formally attributing the operation to Russia's Foreign Intelligence Service (SVR) as part of a broader sanctions package. The activity has been tracked under several different names across the security industry, which is worth being precise about rather than treating as one settled label: Mandiant originally tracked the intrusion set as UNC2452 before later folding it into its ongoing tracking of APT29 ("Cozy Bear"); Microsoft named it Nobelium, a designation later absorbed into Microsoft's 2023 threat-actor renaming as part of Midnight Blizzard. Different vendors converging on the same actor under different names, at different points, is normal in this industry — it reflects independent tracking of the same evidence, not disagreement about what happened.
Confirmed U.S. federal victims include the Departments of the Treasury, Commerce (specifically the National Telecommunications and Information Administration), State, Homeland Security, Justice, Energy — including the National Nuclear Security Administration — and Health and Human Services, including the National Institutes of Health. Confirmed private-sector victims include Microsoft and FireEye/Mandiant itself. Microsoft President Brad Smith, testifying before the U.S. Senate in February 2021, put the total number of organizations genuinely, actively compromised — as distinct from the roughly 18,000 that merely received the backdoor — at over 100. It's worth repeating the distinction from earlier in this page: SUPERNOVA, a webshell some researchers found on a handful of internet-facing Orion servers around the same period, exploited an unrelated authentication-bypass vulnerability in Orion's API and is attributed to a different, apparently opportunistic actor — a separate incident that happened to involve the same product at the same time, not a second stage of this campaign.
The reckoning: a directive, a rebuild, and a first-of-its-kind SEC case
☺ Like you're 10: Getting caught wasn't the end of the story — it was the start of years of rebuilding, new rules for everyone else, and a lawsuit that made the security team's own boss personally answerable.
Beyond CISA's Emergency Directive, SolarWinds' own remediation, described across its subsequent public filings and blog posts, included redesigning its build process around parallel, independently maintained build pipelines whose outputs are compared against each other, specifically to surface exactly the kind of silent divergence SUNSPOT depended on going unnoticed, plus a published "Secure by Design" framework and a broader push toward least-privilege access to build infrastructure. Sudhakar Ramakrishna, who became SolarWinds' CEO in the middle of the disclosure in January 2021, has spoken publicly and repeatedly about that rebuild as an explicit response to this incident specifically, not a generic security refresh.
The legal fallout outlasted the technical remediation. On October 30, 2023, the U.S. Securities and Exchange Commission charged SolarWinds and its CISO, Timothy G. Brown, with securities fraud and internal-control failures, alleging that the company's public statements about its cybersecurity practices materially misrepresented known, internal risk assessments made before the attack. On July 18, 2024, a federal judge in the Southern District of New York dismissed the majority of the SEC's claims, but allowed the claim concerning SolarWinds' pre-breach public "Security Statement" webpage to proceed — a genuinely novel test of whether a named CISO can be held personally liable for a company's public cybersecurity claims. This litigation was still developing as of the sources this page draws from; verify the current docket status directly rather than treating any specific outcome here as final.
Two very different institutions responded to the same incident in two very different registers. CISA's answer was purely technical and immediate: disconnect the product, full stop, no exceptions, on the same day disclosure happened. The SEC's answer arrived three years later and was about disclosure honesty, not technical failure — whether what SolarWinds told investors about its security posture, before the breach, was true. Both are legitimate consequences of the same event. A DevSecOps program that only prepares for the first kind of reckoning — patch the thing, rotate the credentials — is unprepared for the second, which is about whether your own internal risk assessments and your public claims about them were ever telling the same story.
What this course's own controls would, and wouldn't, have caught
☺ Like you're 10: Some of the tools from earlier lessons would have stopped this cold. Some wouldn't have noticed anything at all. Knowing exactly which is which is the whole point of studying a real incident instead of a hypothetical one.
It's tempting, reading a course built around SAST, SCA, signing, and SBOMs, to assume the whole toolkit would have stopped SUNBURST. Being honest about which pieces actually would have — and which wouldn't have — is more useful than the flattering version:
- SAST and pull-request review — would not have caught it. The malicious code never appeared in source control. A tool built to scan a repository, or a person built to review a diff, has nothing to look at; the tampering happened downstream of both.
- Build-server zero trust — plausibly would have. Zero trust for pipelines' core argument — treat the build server as untrusted infrastructure, monitor it for unexpected process behavior, and don't let it hold standing, unreviewed access to the compile step for over a year unmonitored — is close to a direct rebuttal of exactly what let SUNSPOT persist undetected on SolarWinds' build infrastructure for so long.
- Plain code signing — did not help, and arguably made this worse. The valid signature is precisely what let a trojanized DLL pass as trustworthy at every customer's door. See the earlier warn callout: a signature proves origin, not integrity of the process that produced it.
- Build provenance (SLSA-style attestation) — plausibly would have. An attestation binding the shipped artifact's hash to the exact source commit and build environment that produced it is a stronger claim than a signature alone, and it's the specific gap SUNSPOT exploited — see Sigstore & cosign for how that attestation actually gets made and checked today.
- SBOMs — would not have detected the backdoor, but would have massively sped up the response. An SBOM describes declared components and versions; it has no concept of "this specific compile of this DLL contains injected code," so it wasn't going to flag SUNBURST on the way in. What it would have done is exactly the scenario software bills of materials opens with: once SolarWinds published the affected version range and file hashes, an organization with an indexed SBOM inventory could answer "do we run any of these, where, and can they reach the internet" in minutes with one query. Every organization without that inventory spent the same December emailing every team individually and waiting for replies — the exact gap this course's SBOM lesson exists to close.
That split — one set of controls that would have prevented it, a different set that would only have sped up the response after the fact — is worth remembering the next time "we have an SBOM" gets treated as a complete answer to supply-chain risk on its own. It's the blast-radius half of the answer, not the prevention half; zero trust for pipelines and secure SDLC gates are the prevention half, and this incident is the argument for taking both seriously rather than treating either as sufficient alone.
Pick a build pipeline you actually run — a CI workflow for a real service, not a toy repo. Answer, in writing, three questions: Can you name every process with write access to your build agent's filesystem during a compile, and when each one was last reviewed? Does your build produce anything beyond a signature — a provenance attestation, a reproducible-build hash comparison, anything — that ties the shipped artifact back to an exact source commit? And if a vendor disclosed tomorrow that one specific version of a dependency you run was compromised at the build level, could you answer "are we affected, and where" from an existing inventory in under five minutes, or would you be sending emails? SolarWinds could not answer any of these three questions well in early 2020. Most teams still can't.
What to steal for your own pipeline
☺ Like you're 10: You don't need SolarWinds' scale to copy the fix — treat your build machine the way you'd treat a stranger, not a coworker.
- Stop treating the build server as an extension of the reviewed codebase. Code review and SAST protect the repository. They protect nothing downstream of it unless something separately verifies that the build process itself did what it was supposed to, every single run — the exact case zero trust for pipelines makes in full.
- Prefer ephemeral, disposable build agents over long-lived ones. SUNSPOT's entire strategy depended on a build server that stayed in the same state, unmonitored, for months at a time. An agent that's torn down and rebuilt fresh after every job has nowhere for an implant like that to persist.
- Move past plain signing toward build provenance. A signature answers "did this come from us." A SLSA-style attestation answers the harder, more useful question: "did this come from the exact source and build process we think it did." Sigstore & cosign is where this course teaches the mechanics.
- Build the SBOM inventory before you need it, not during the incident. The entire value of an SBOM store is answering a blast-radius question in minutes on the worst day, and that only works if the indexing happened months earlier, quietly, as a routine part of every build.
- Rehearse the "we just got a disclosure about a vendor, not our own code" scenario specifically. Most incident-response drills assume the vulnerability is in code your team wrote. This incident, and the honest-caveats section below, argue for practicing the version where the vulnerable thing is something you trusted and didn't build at all.
Honest caveats: what's genuinely uncertain here
☺ Like you're 10: A story this big, told by many different organizations at different times, has a few spots where the details still don't perfectly agree — and it's more honest to say so than to pretend otherwise.
- Attribution is an intelligence assessment, not a courtroom finding. "Likely Russian in origin," and the later, more specific naming of Russia's SVR, are the U.S. government's confident public assessments — the strongest form of public accusation this kind of incident usually gets — but they are not the same epistemic category as a criminal conviction with evidence tested in open court.
- Exact dates vary slightly across sources. CrowdStrike's, Microsoft's, FireEye's, and SolarWinds' own public timelines for when build-system access began and when the first trojanized build was compiled differ by days to weeks depending on which forensic artifact each investigator is dating from. Treat every date on this page as "as publicly reported by the cited source," not as a single, universally agreed timestamp.
- Cost figures are self-reported estimates, not audited totals. SolarWinds' own SEC filings disclose real, material incident-response costs; broader economic-impact estimates circulating in press and insurer reports have run far higher and are genuinely contested. Neither this page nor its sources should be read as a settled, audited dollar figure.
- The SEC litigation was not fully resolved as of the sources this page draws from. The July 2024 ruling dismissed most claims but let the "Security Statement" claim proceed — check the current docket directly before citing a final outcome, since this was still moving.
- Don't conflate SUPERNOVA with SUNBURST. Early press coverage sometimes blurred the two together because both touched Orion in the same window. They are different vulnerabilities, different actors, and different stories — precision here matters for anyone trying to reason accurately about what actually happened.
Foxy: The part that still gets me — SolarWinds' own engineers reviewed that code. Diffed it, approved it, merged it. And it was clean. The malicious version never existed in git at all.
Pip: Which is exactly why I don't just check "is there a signature" anymore. A signature only tells me the box came from the factory. It says nothing about who was standing at the conveyor belt that day.
Timmy: So my gate would've waved this straight through. Scanned repo: clean. Signed artifact: valid. Every box I check says "fine."
Rocky: That's the gap I'd have gone looking for — not the code, the machine that builds the code. Nobody was red-teaming the build server itself. Nobody thought it needed it.
Foxy: And it still took FireEye getting breached themselves, and refusing to shrug off one weird login, before anyone found it. Nine months live, and the thing that ended it wasn't a scanner.
Pip: So I stopped asking "is this signed." Now I ask "signed by what process, from what commit, verified how." That's the whole difference this page is about.
Where this connects in the course
☺ Like you're 10: One incident, four different lessons — pick the one that matches what you're building next.
The build-integrity fix belongs to zero trust for pipelines, which covers the mechanical, no-standing-access answer in full — this page names the incident it exists to prevent a repeat of. The signing and provenance half lives on Sigstore & cosign, and the blast-radius, post-disclosure half on software bills of materials. The gate mechanics — where in a real pipeline a check like this would actually have to sit to matter — are secure SDLC gates & the DevSecOps maturity model. For a different flavor of supply-chain failure — a known, patched CVE nobody inventoried, rather than a novel build-time implant — read the Equifax case study; for platform-scale supply-chain defense from the vendor side rather than the victim side, see the GitHub case study. Return to the glossary for any term on this page you want defined precisely, or to the CDE certification page, which draws on this exact incident.
1. Where exactly did the attackers tamper with SolarWinds' software — the source repository or the build process — and why does that distinction matter for what a SAST scan could and couldn't catch? 2. Why was SUNBURST's digital signature genuine, and what does that tell you about what a signature does and doesn't prove? 3. What did SUNBURST do for its first twelve to fourteen days after installation, and why? 4. Roughly how did the numbers narrow across the funnel — from Orion customers, to organizations that received the backdoor, to organizations confirmed genuinely compromised? 5. Who discovered the intrusion, and how — and what does that say about relying on any single control to catch something like this? 6. Give one example of a control from this course that would have prevented this incident, and one that would only have sped up the response after the fact — and explain the difference.
Check your answers
- The build process, not the source repository — the SUNSPOT implant swapped a source file only during compilation and restored it immediately after, so the malicious code never appeared in git. A SAST scan or a pull-request review, both built around inspecting source control, had nothing to find.
- The tampering happened before compilation and signing, so the resulting DLL went through SolarWinds' normal, legitimate signing process — no certificate was stolen or forged. That means a signature only proves an artifact came out of a process the certificate's owner controls; it says nothing about whether that process was trustworthy at the specific moment this artifact was produced.
- It stayed dormant, making no outbound call for roughly twelve to fourteen days — long enough to outlast most automated sandbox and dynamic-analysis observation windows, which typically watch a sample for minutes, not weeks, reducing the odds of automated detection.
- More than 33,000 total Orion customers narrowed to fewer than 18,000 who actually installed the compromised update, narrowed again to more than 100 organizations Microsoft's testimony described as genuinely, actively compromised, narrowed further to a smaller, publicly unspecified number who received hands-on-keyboard follow-on activity like Cobalt Strike.
- FireEye/Mandiant discovered it while investigating its own, separate breach — the theft of its Red Team assessment tools — and traced the intrusion vector back to a trojanized Orion update. No scanner or pipeline control from either SolarWinds or its customers caught it; discovery depended on one target's own forensic rigor after being independently attacked.
- Build-server zero trust (treating the build agent as untrusted, ephemeral infrastructure) plausibly would have prevented SUNSPOT from persisting long enough to matter. An SBOM inventory would not have detected the backdoor at all, but would have let an organization answer "are we running the affected version, and where" in minutes once SolarWinds published the compromised version range — speeding up response, not preventing the incident.