Safeguard
Supply Chain•

SolarWinds 2020: the build compromise timeline in plain words

A dated walk through the SolarWinds Orion compromise, from the first test change in 2019 to discovery in December 2020, and the numbers to treat with care.

Safeguard Security Team
3 min read

The SolarWinds Orion attack ran for more than a year before it was found. Attackers were in the build infrastructure by September 2019, malware reached Orion updates in March 2020, and FireEye confirmed the trojaned update as the attack route on 15 December 2020. About 18,000 users downloaded the compromised versions.

The timeline

From the Wikipedia article on the 2020 United States federal government data breach:

  • By September 2019. Attackers were in SolarWinds' software publishing infrastructure.
  • October 2019. First known malicious modification, a proof of concept.
  • December 2019 to February 2020. Command and control infrastructure set up.
  • March 2020. Malware planted in Orion updates.
  • April 2020. The malware began contacting command servers.
  • March to June 2020. Infected Orion versions, 2019.4 through 2020.2.1 HF1, were released.
  • 8 December 2020. FireEye announced that its red team tools had been stolen.
  • 13 December 2020. Breaches at the Treasury and Commerce Departments were publicly confirmed.
  • 15 December 2020. FireEye confirmed the Orion update as the attack vector.

Names to know

FireEye named the malware SUNBURST. Microsoft called it Solorigate. CrowdStrike later isolated the tool used to insert SUNBURST into Orion updates and called it SUNSPOT.

Numbers to treat with care

SolarWinds reported 300,000 customers, 33,000 of them using Orion, and about 18,000 government and private users downloaded the compromised versions. The article stresses that downloading the update did not automatically mean a breach. Each case needed investigation. So do not write that 18,000 organisations were breached.

How it was found

FireEye found the supply chain attack while investigating the theft of its own tools. It reported to the NSA, which was not known to have been aware beforehand. Discovery came from an investigation of a different incident, not from a control in the build.

What it teaches

  • Signed does not mean safe. The update came through the normal channel.
  • The build system is a target. Protect it like production.
  • Detection needs a trigger. Plan for finding things you did not expect.

For your own pipelines, ask who can change build scripts, whether builds are reproducible, and whether you would notice an extra step in the output.

Build pipeline questions

Ask who can modify your build scripts, and how a change is reviewed. Ask whether a build runs in a clean environment each time, and whether you could rebuild a past release and compare output. Ask where signing keys live, and who can use them. Ask what alerts fire if a build step makes an unexpected network connection. If several answers are uncertain, you have a short list of tasks that would reduce exposure to an attack of this shape.

Quick check

What did FireEye call the malware?

SUNBURST. Microsoft called it Solorigate.

Did downloading the update mean a confirmed breach?

No. Each case needed investigation, per the source cited below.

Safeguard supports policies and gates on builds and pull requests, plus SBOM scanning, and offers a free scan at gold.safeguard.sh/scan.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.