Industry Analysis

SolarWinds Post-Incident Governance Changes Reviewed

Four years after SUNBURST, SolarWinds has rebuilt its SDLC around signed pipelines, parallel builds, and a new CSO office. How much of it is real?

Nayan Dey
Senior Security Engineer
5 min read

SolarWinds reported fiscal Q2 2024 results on August 8, and for the first time since December 2020 the prepared remarks did not open with a reference to SUNBURST. The transcript did reference the July 18 federal ruling that dismissed most of the SEC's fraud charges against the company and its CISO Tim Brown, leaving only claims tied to the public "Security Statement" in place. That outcome, plus the company's $26M shareholder settlement in 2022 and its go-private deal with Turn/River in February 2024, roughly closes the legal chapter of the incident. What remains is the engineering and governance work the company has actually done, which is substantial and underreported. We spent July pulling apart the publicly documented changes and talking to three SolarWinds engineering alumni. Here is what they look like from the outside.

Did SolarWinds actually rebuild its build pipeline?

Yes, and the architecture is meaningfully different from the 2020 system that SUNBURST abused. The pre-SUNBURST pipeline was a single MSBuild server that produced the Orion Platform installer; the attackers inserted SUNSPOT to splice malicious source into the compile step. The new pipeline, which SolarWinds calls "Next-Generation Build System," runs three parallel, ephemeral build environments that each produce an artifact, and the release is gated on bytewise equivalence across all three. A compromise would have to land the same malicious change in all three clean-room environments within the same build window.

  source commit
       |
   +---+---+---+
   |       |       |
  Build A  Build B  Build C    (ephemeral, distinct toolchains)
   |       |       |
   +---+---+---+
       |
   sha256 quorum gate
       |
   signed release

What changed in their SDLC outside the pipeline?

Four things worth noting. First, all product source now lives in a single consolidated GitHub Enterprise tenant with branch protection enforced, replacing the mix of TFS and Git repos that existed in 2020. Second, release signing moved to hardware HSMs with quorum signing and an offline code-signing cert root. Third, SBOMs are now produced for every Orion, Platform, and Observability release in CycloneDX 1.5, and are published to customers. Fourth, threat modeling is now gated in the SDLC ticket system; a story cannot leave grooming without a documented threat model review if it touches a privileged path.

Did the CISO role actually change?

In function, yes. In title, only slightly. Tim Brown, the CISO named in the SEC complaint, was reorganized under a new Chief Information Security Officer Office and given a narrower product-security scope; governance and risk moved under a separate CSO role reporting to the CEO. The practical change is that security decisions about public statements, customer disclosures, and SEC reporting no longer sit on one engineer's desk. Whatever one thinks of the legal merits of the case, the operational lesson is the same as Equifax's in 2017: do not concentrate disclosure authority at the CISO level.

Has customer behavior actually changed?

Partially. The US federal space has meaningfully tightened. CISA's 2024 Software Attestation Common Form, M-22-18, and the DoJ False Claims Act actions that followed it have forced contractors to produce attestations specifically citing secure development practices like SolarWinds-era failures. In the commercial space, TPRM questionnaires routinely now ask for build-system attestations and SBOMs, but the rate of customers who actually parse and act on the returned artifacts is still well under 30% based on vendor-side data we have seen. The governance change SolarWinds made is more advanced than the one most of its customers have made.

Is SUNBURST-class risk actually lower now?

Industry-wide, yes, modestly. The specific technique SUNSPOT used, injecting source at compile time on a persistent build host, is substantially harder on any pipeline that uses ephemeral runners, which is the GitHub Actions and GitLab default. But the underlying class, "trusted software vendor ships a backdoor to every customer simultaneously," is not solved. CrowdStrike's July 19 outage showed how quickly the blast radius can develop without an adversary. Kaseya 2021, 3CX 2023, and the polyfill.io 2024 incidents all re-used pieces of the SUNBURST playbook. What has changed is that SBOMs and signed provenance make post-incident forensics dramatically faster, which is why the disclosure-to-remediation interval has compressed from months (SUNBURST) to days (3CX) to hours (polyfill).

What should peer vendors borrow?

Three things. Parallel-build quorum is the single highest-leverage control any mid-sized ISV can adopt; the infrastructure cost is roughly 3x a single pipeline, the risk reduction is large, and it is testable. Offline root signing with HSM quorum is table stakes for any product that auto-updates. And separating the "person who signs security attestations to the SEC" from the "person who runs product security" is worth doing before an incident, not after.

How Safeguard Helps

Safeguard operationalizes the lessons SolarWinds paid for. Our TPRM module captures build-pipeline attributes, parallel-build quorum, HSM signing, and SBOM cadence as structured vendor data, so security teams can filter their inventory for suppliers that still ship from a single non-ephemeral build host. Griffin AI ingests vendor SBOMs and attestations on every release and diffs them against the previous version, flagging new components, licensing changes, or unexpected signing key rotations. Reachability analysis then tells you whether a new or changed component is actually on a load-bearing code path in your environment, which is the difference between a Tuesday upgrade and a Saturday war room. Policy gates in Safeguard can block ingestion of any vendor artifact whose attestation fails the CISA Common Form schema.

Never miss an update

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