SolarWinds Orion and the build-system compromise that turned a trusted update into public risk

Summary

• The Orion campaign succeeded because attackers compromised a software production process, inserted SUNBURST during automated builds, and allowed SolarWinds' normal signing and distribution machinery to deliver the modified component. A valid signature authenticated the compromised release process; it did not independently establish that the resulting code matched an approved source state.
• Fewer than 18,000 customers may have obtained affected releases, but that figure is not a count of organizations penetrated in follow-on operations. Later public estimates placed confirmed or assessed follow-on compromises at nine U.S. federal agencies and fewer than 100 non-government organizations, while SolarWinds separately estimated fewer than 100 customers were hacked through SUNBURST.
• The Russian Foreign Intelligence Service bears responsibility for the espionage operation. SolarWinds nevertheless controlled the build environment, release provenance, signing path, and product architecture that converted one internal compromise into trusted code at customer sites. Customers and government buyers controlled segmentation, logging, identity hardening, procurement, and recovery. Accountability belongs to each party for the safeguards it could actually operate.
• The legal record is narrower than the operational record. The SEC sued SolarWinds and its chief information security officer in 2023, a federal court dismissed most claims in 2024, and the SEC dismissed the remaining action with prejudice in November 2025. That history neither proves the SEC's original allegations nor establishes that every build-security decision was adequate; it shows why technical preventability, disclosure law, and final legal liability must be analyzed separately.

The update did exactly what trust infrastructure told it to do

The SolarWinds incident is often described as a poisoned software update. That phrase captures the delivery method, but it can make the failure sound like ordinary malware hidden inside an installer. The more consequential fact is that the affected update was produced and delivered through the vendor's legitimate release machinery. Administrators did not have to disable signature verification, visit a counterfeit download site, or accept an unsigned executable. The hostile component was included in a SolarWinds Orion package and digitally signed.

That difference changes the accountability analysis. Software signing is commonly understood as a control over origin and integrity in transit. If a package changes after signing, signature verification should fail. But signing does not, on its own, prove that the source selected for compilation was authorized, that the compiler ran in a clean environment, that a build worker had not been modified, or that the artifact corresponds to the code reviewers approved. When an attacker acts before the signature is applied, the signature can faithfully vouch for an already compromised output.

Mandiant's original technical disclosure of SUNBURST documented a SolarWinds-signed Orion plug-in containing a backdoor. The component could wait for up to roughly two weeks, profile its environment, communicate through DNS and HTTP patterns made to resemble legitimate Orion traffic, and retrieve commands only after the attacker selected a victim. The initial implant was designed to be quiet, selective, and compatible with the host product. Its purpose was not to break every installation at once. Its purpose was to place a credible option inside many networks and exercise only a small subset.

This is why the event belongs in a cloud-dependency and public-continuity record even though Orion was generally installed on customer premises. Orion monitored and managed infrastructure across on-premises, cloud, and hybrid environments. Follow-on activity could reach federated identity and Microsoft 365 resources. The trust relationship operated like a service dependency: customers relied on a continuously maintained vendor product, accepted vendor-produced updates, and placed the software where it could observe or administer consequential systems. The location of the executable did not eliminate dependence on the remote software factory that produced it.

Nor was the principal public harm a conventional outage. Federal email and operational systems did not all stop functioning on one visible day. The compromise instead damaged confidentiality, identity assurance, evidentiary confidence, and the ability to know which communications or decisions had been observed. Public-sector continuity includes the ability to conduct government business over systems whose trust can be defended. A network can remain available while the public function it supports becomes strategically exposed.

What the public record establishes

The strongest account comes from sources with different institutional incentives: SolarWinds' incident disclosures and securities filings; CrowdStrike and Mandiant technical analyses; CISA, NSA, FBI, and affected-agency records; GAO's review of the federal response; congressional testimony; and the later court record. They do not answer every question, but they establish several core facts.

First, an advanced actor maintained access to SolarWinds' environment long enough to study the Orion production process. SolarWinds' May 2021 investigative update said the company could not determine precisely when or how initial entry occurred. It reported evidence of compromised credentials and persistent access to its software development environment and internal systems, including Microsoft 365, for at least nine months before an October 2019 test run. The company narrowed the possible initial routes to a third-party zero-day, brute force such as password spraying, or social engineering, but did not claim to have proved one.

Second, the hostile change was made in the automated build environment, not committed as a lasting modification to the Orion source repository. That is not an exculpatory technicality. It identifies the trust boundary that failed. A reviewer comparing the repository before and after a build could see clean source while the build worker temporarily substituted a malicious file during compilation. Controls centered only on source review would therefore miss the produced artifact's divergence.

Third, the attackers tested their ability to modify builds before deploying the operational backdoor. SolarWinds' January 2021 initial build-system findings placed the earliest then-known suspicious internal activity in September 2019, a test modification in an October 2019 Orion release, the SUNBURST injection beginning on February 20, 2020, and removal of the malicious code from the environment in June 2020. Later company reporting pushed evidence of access further back while preserving the October test and March-to-June distribution window.

Fourth, affected Orion versions were distributed through normal channels. SolarWinds' December 14, 2020 Form 8-K said products downloaded, implemented, or updated during the relevant period contained the vulnerability and estimated that fewer than 18,000 customers may have installed affected releases. Its 2020 Form 10-K later described SUNBURST as injected into builds released from March through June 2020, said the affected software was installed on customer premises, and emphasized that the number exploited was substantially smaller than the number that could have installed an affected version.

Fifth, FireEye discovered the broader campaign in December 2020 while investigating its own intrusion. The public record does not show SolarWinds' release assurance or a federal perimeter program detecting the compromised build before customers received it. That detection gap matters independently of how well SolarWinds responded after notification. A control can perform well during crisis response while having failed to surface the hazardous condition during production.

Sixth, the U.S. government later formally attributed the campaign to the Russian SVR. CISA's April 2021 joint-advisory notice records the U.S. attribution and the corresponding NSA-CISA-FBI guidance; the United Kingdom also publicly associated the SVR with the operation. Attribution establishes the hostile actor's responsibility and geopolitical context. It does not answer whether vendor or customer safeguards were proportionate to a foreseeable class of supply-chain attack.

Three important matters remain bounded. The initial route into SolarWinds was not proved in the cited final company update. The public record does not reveal every organization selected for follow-on access or every item taken from those networks. And an affected update does not prove that an organization suffered interactive exploitation. Those gaps require careful language, not analytical paralysis.

From reconnaissance to a signed backdoor

The campaign was patient because its target was not just a server. It was a repeatable industrial process.

The actor first needed access and understanding. Build environments contain compilers, dependency stores, credentials, orchestration tools, signing interfaces, release scripts, and many intermediate files. Their complexity creates opportunities, but indiscriminate tampering creates noise. A failed compile, a reproducibility mismatch, an unexpected source diff, or a malformed package could alert engineers. The attacker therefore had to learn when Orion builds ran, which source file could carry the implant, how that file reached the final plug-in, and how to avoid destabilizing the product.

The October 2019 test was a critical warning in retrospect. It showed that the actor was validating the injection path before committing the operational payload. In a safe production design, a test modification that exists only during build should still be detected through artifact comparison, isolated builder monitoring, provenance checks, or deterministic release controls. The fact that the test passed into a release without exposing the intruder demonstrated that the build output could diverge from the expected source and still proceed.

CrowdStrike's SUNSPOT analysis explains the mechanism. SUNSPOT watched for MsBuild.exe, inspected command-line information to recognize the Orion solution, and replaced InventoryManager.cs with a malicious variant while the product was being built. It preserved the original file so it could restore it afterward. It included safeguards intended to avoid build failures and operational behaviors designed to let the intruder stop cleanly rather than leave an obviously broken compile. The design treated developer suspicion as the main hazard.

The resulting malicious code became SUNBURST inside SolarWinds.Orion.Core.BusinessLayer.dll. Because the substitution happened during the build, the final package could pass through later packaging and signing steps as an ordinary product output. The signature was real. The provenance claim behind it was incomplete.

Once installed, SUNBURST delayed execution and checked for environmental conditions that might indicate analysis. It generated victim-specific DNS queries and allowed the operator to decide which beacons would proceed to more active command and control. Mandiant's additional technical analysis described the anti-analysis checks, domain-generation behavior, command modes, and efforts to blend state into legitimate Orion configuration. Selectivity reduced the chance that 18,000 potential installations would produce 18,000 visible incidents.

For chosen victims, the backdoor could become an entry point for separate payloads, credential theft, lateral movement, and cloud access. This distinction between a distributed implant and an exploited organization is essential. An organization that downloaded an affected package, one that installed it on an isolated server, one whose server beaconed, and one whose identities were used for follow-on access occupy different impact categories. Collapsing them into one count produces a dramatic number but a poor incident model.

The attackers removed SUNBURST from the SolarWinds build environment in June 2020, months before discovery. That act limited future distribution and removed obvious live evidence from the production system. Customers that had already installed affected releases retained the implant. The operation therefore outlived the actor's presence in the software factory: a production compromise was converted into thousands of independently deployed artifacts, each following the customer's maintenance and retention schedule.

Why source review and code signing were not enough

The Orion incident exposed a gap between software integrity controls that are often treated as interchangeable.

Source review asks whether the code committed for a release is acceptable. Build integrity asks whether the compiled artifact was actually produced from that approved source, approved dependencies, approved tools, and approved instructions in an uncompromised environment. Signing asks whether a particular key authorized the artifact. Distribution integrity asks whether customers received the artifact that was signed. Runtime controls ask what the artifact is allowed to do after installation. Each control can succeed while another fails.

In Orion, the public evidence indicates that the persistent source repository did not carry the SUNBURST modification. Code review therefore could not prove the artifact clean. The build system incorporated the unauthorized source transiently. Signing then attached organizational authority to the output. Distribution delivered that output without a third party modifying it. Those downstream controls did their narrow jobs, but the release decision rested on a broken upstream fact.

This is the supply-chain version of a truthful statement built on a false premise. The package was truthfully signed by SolarWinds. What customers inferred was broader: that the package represented the product SolarWinds intended to release. The incident broke that inference.

The answer is not to abandon signatures. Without them, customers would also be exposed to mirror compromise, network interception, and counterfeit packages. The answer is to strengthen the evidence attached to the signature. A high-assurance release process should be able to show which source revision, dependency set, toolchain, builder identity, build policy, tests, and approvals produced an artifact. It should detect when a worker substitutes a file that is not present in the approved source state. It should prevent the same identity from altering source, build policy, artifact, and signing decision without independent checks.

Reproducible or independently repeated builds can help, but they are not magic. If supposedly independent builders share credentials, orchestration, dependencies, or a compromised control plane, they may reproduce the same malicious output. Comparison matters only when the trust paths are genuinely separated. Similarly, a software bill of materials can identify components while failing to show that the build worker inserted extra first-party code. Inventory is useful; it is not equivalent to provenance.

SolarWinds' later remediation proposal recognized this problem. Its May 2021 update described three separate build environments, changing build systems, separate credentials, and integrity comparison across outputs. In congressional testimony, CEO Sudhakar Ramakrishna presented that design as a way to force an attacker to compromise multiple heterogeneous environments. The company's written Senate testimony is evidence of the response and the architecture claimed at that time. It is not, by itself, an independent certification that every release has since met that design.

The denominator problem: 18,000 was exposure, not confirmed exploitation

Few figures from the incident have been repeated as often as 18,000. It is useful only if its denominator is stated.

SolarWinds initially notified approximately 33,000 Orion customers active on maintenance during and after the affected period. It estimated that fewer than 18,000 may have had an affected installation. Some downloaded but did not install. Some installed on systems that could not reach the command-and-control infrastructure. Some executed the implant but were not selected for follow-on activity. A much smaller group communicated with later infrastructure, and a smaller group still was actively compromised beyond the initial backdoor.

In May 2021 SolarWinds estimated fewer than 100 customers had been hacked through SUNBURST. In March 2021, FBI testimony described more than 16,000 affected public and private customers, nine federal agencies with follow-on compromise, and fewer than 100 non-government entities in that category. The figures are compatible if "affected," "installed," "beaconed," "targeted," and "compromised" remain distinct.

The distinction does not make the incident small. A latent administrative foothold delivered to thousands of organizations is a severe systemic event even when a state actor exercises it selectively. The attacker obtained a menu of potential access and could choose targets based on intelligence value. The risk lies in both realized harm and the scale of trusted opportunity.

It also matters for customer notification. A vendor should not send the same message to every exposure class. Customers need to know whether they merely downloaded an artifact, installed it, executed it, generated a known beacon, received a command-and-control response, or show evidence of follow-on identity abuse. Each state changes preservation, credential reset, rebuild, notification, and continuity decisions. Where vendor-wide telemetry cannot determine the state, the uncertainty itself should be communicated.

The public record also shows why impact cannot be inferred only from vendor telemetry. Orion ran inside customer networks, so SolarWinds could not directly inspect every installation. Customers and cloud providers held parts of the evidence. Some follow-on activity abandoned SUNBURST and used legitimate credentials or forged authentication assertions, making a clean Orion server insufficient proof that the wider environment was clean. Incident accounting had to combine vendor download records, DNS observations, host forensics, identity logs, and affected-organization investigations.

Discovery and the cost of late visibility

FireEye's discovery is often celebrated as a detection success, and it was. It is also evidence that the earlier safety system failed.

For months, affected releases moved through a trusted maintenance channel. The attacker designed the implant to sleep, avoid analysis environments, use familiar process context, and mimic legitimate network behavior. Traditional antivirus and perimeter rules were poorly positioned to recognize a vendor-signed component performing activity that resembled the product's own telemetry. A network-management product also has a naturally broad behavioral envelope. It inventories systems, communicates across segments, holds useful credentials, and may legitimately contact vendor infrastructure. Malicious behavior can hide inside privileges the product requires.

The first public CISA response reflected the seriousness of that ambiguity. Its December 13 alert identified affected versions, and Emergency Directive 21-01 ordered federal civilian agencies to disconnect covered Orion products. The order was not simply "install the patch." An already compromised management server could contain evidence, credentials, or persistence beyond the original DLL. Treating it as a normal vulnerability would risk preserving an attacker after replacing the initial file.

CISA's later eviction guidance addressed networks where the actor may have moved into Active Directory and Microsoft 365. Eviction could require coordinated identity recovery, token and credential invalidation, cloud review, host rebuilding, and monitoring. Those steps can interrupt operations and consume scarce personnel even when public services remain online. The continuity cost of a confidential compromise is measured partly in the work required to restore justified trust.

The United Kingdom's NCSC guidance similarly distinguished affected binaries from serious follow-on impact. It advised isolation, hash and DNS checks, credential resets, investigation of accounts associated with the Orion server, and consideration of a full rebuild. The global consistency of that advice shows that the trust failure was not confined to one government's procurement environment.

Detection responsibility was distributed. SolarWinds was best positioned to monitor build workers, compare artifacts against approved source, supervise signing, and identify unexpected release provenance. Customers were best positioned to restrict Orion's privileges, segment its host, preserve DNS and identity logs, and notice behavior that departed from their own environment. Cloud identity providers could detect anomalous token and account use across tenants. Government coordinating bodies could aggregate reports and issue compulsory action. No single observer had the whole picture, which made timely information sharing a functional control rather than a courtesy.

The response also demonstrates a hard truth about indicators. Hashes and domains are valuable during triage, but a patient actor can rotate infrastructure and move to valid accounts. Absence of a known indicator is not proof of absence once the intrusion has crossed into identity systems. Durable response had to reconstruct the attack path and re-establish trust from known-good states.

Public-sector continuity without a visible blackout

GAO described the campaign as one of the most widespread and sophisticated hacking operations conducted against the federal government and private sector. Its 2022 federal-response review found that agencies formed a Cyber Unified Coordination Group, developed technical guidance and tools, shared information, and identified lessons around coordination, information access, and incident response. The response was substantial because the compromise touched the machinery through which government understands and administers its own systems.

Nine federal agencies were identified publicly as suffering follow-on compromise. The Department of Justice said malicious activity reached its Microsoft 365 email environment and that around three percent of mailboxes were potentially accessed, while it had no indication classified systems were affected. DOJ's January 2021 statement appropriately bounded the known impact. It did not treat unclassified email exposure as harmless, and it did not claim compromise of systems for which it lacked evidence.

Continuity has several layers in this setting.

The first is operational availability. Agencies must continue delivering public functions while isolating management servers, rebuilding hosts, rotating credentials, and investigating cloud accounts. An emergency directive can be technically necessary and operationally disruptive at the same time.

The second is confidentiality continuity. Officials need to know whether policy drafts, procurement information, legal strategy, schedules, or contact networks were observed. An espionage campaign can extract durable advantage without altering or destroying a file.

The third is administrative integrity. Orion's role in monitoring and managing networks meant that customers had to question information supplied by a tool intended to support trust. A compromised management plane can hide activity, expose credentials, or make operators uncertain about the systems they use to investigate.

The fourth is identity continuity. NSA's December 2020 authentication-mechanism advisory explained how privileged on-premises access could lead to forged federated authentication and cloud access. Once local identity trust is manipulated, simply cleaning the initial Orion host does not restore the validity of every session or token derived from it.

The fifth is evidentiary continuity. Agencies need retained DNS, endpoint, identity, cloud, and administrative logs to decide whether a downloaded update became a beacon or a full compromise. If those records have aged out, leaders must operate under wider uncertainty and may need broader remediation.

The sixth is institutional trust. Government buyers ask employees to use shared commercial technology for sensitive public work. That model depends on vendors accurately representing security practices, disclosing incidents with appropriate precision, and supplying enough evidence to support response. A signed update that carries a backdoor weakens the social and administrative assumptions on which patching programs depend.

The campaign did not show that automated updating is inherently unsafe. Delaying authentic security fixes can be far more dangerous. It showed that update assurance must include the producer's development and build environment. Telling customers to patch quickly while treating the software factory as an ordinary corporate network creates a contradiction: the safer customers become at accepting updates, the more leverage a compromised producer gains.

SolarWinds' responsibility: control over the factory

SolarWinds was a victim of a deliberate state operation. It also occupied the control position that made the distribution mechanism possible.

The company controlled access to its software development systems, build workers, release orchestration, artifact verification, signing path, and customer update channel. Customers could not deploy endpoint monitoring inside SolarWinds' builders. They could not compare pre-signing artifacts against the company's approved source, require a second internal build, or stop the vendor's signing key from authorizing a compromised output. Those were producer controls.

Operational accountability follows that control. The relevant question is not whether any reasonable company could guarantee immunity from the SVR. No producer can promise that. The question is whether the release process contained independent controls capable of preventing one compromised environment from silently changing a signed product, or of detecting the change before broad distribution.

The October 2019 test and the later SUNSPOT operation demonstrate that the attacker found room to modify a build without creating a release-stopping discrepancy. The long period of internal access and the failure to detect the production manipulation are adverse facts in a control assessment. The actor's sophistication is relevant to the level of resistance required, but it is not a waiver. A vendor whose product occupies privileged positions in governments and major enterprises should expect to be targeted by capable actors and design the factory accordingly.

Responsibility also includes incident communication. SolarWinds notified customers, worked with investigators, published technical information about SUNSPOT, provided remediations, and funded some customer support. Those actions reduced harm and supplied unusually useful industry evidence. They should count in the record. Accountability is not a search for one permanently blameworthy label; it includes both the controls that failed and the quality of the response.

Company disclosures were careful on several important points. SolarWinds did not independently attribute the actor before government attribution. It distinguished potential installations from confirmed follow-on exploitation. It acknowledged that initial access remained unresolved. Its filings recognized litigation, investigation, cost, customer, and reputational risks. These are meaningful strengths, even though later enforcement litigation disputed aspects of the company's earlier public security representations.

The producer's duty does not end at shipping a corrected binary. SolarWinds needed to prove that the build path itself had changed, that signing authority could not bless an unexplained artifact, that credentials and third-party access were constrained, and that evidence would persist long enough to investigate a patient intrusion. The claimed three-build architecture was responsive to the mechanism. Durable assurance requires independent testing of whether separation survives real operational pressure.

Customer responsibility: constrain the trusted product

Customers did not control SolarWinds' build system, but they controlled the environment into which Orion was installed. Their responsibility begins where the product enters that environment.

Network-management software should not receive unlimited trust merely because broad access is convenient. Customers can isolate management servers, restrict outbound internet access, separate service accounts, minimize standing privileges, protect administrative credentials, monitor the product's network behavior, and retain logs outside the system being monitored. The NCSC noted that an affected server unable to resolve or reach external infrastructure could prevent the initial backdoor from progressing. That is a concrete example of customer-side defense limiting a provider-originated failure.

Customers also controlled whether cloud and on-premises identity trust allowed one compromised management host to become a wider credential authority. Separate administrative workstations, tiered identity, phishing-resistant multifactor authentication, constrained federation, token monitoring, and recovery plans could reduce follow-on reach. These controls could not make the delivered DLL benign, but they could change the consequences of executing it.

Procurement and architecture teams had another duty: classify Orion as a high-consequence dependency. A tool that sees network topology, handles administrative credentials, or monitors critical assets should be assessed differently from an ordinary desktop utility. Buyers should know which products can update themselves, which signing roots they trust, where release artifacts originate, and how quickly they can isolate or replace the product without losing operational visibility.

Customer responsibility must still be bounded by feasibility. In 2020, a customer could not reconstruct SolarWinds' private build provenance from a signed installer. Most buyers lacked contractual rights or technical access to audit the production pipeline. Even excellent segmentation would not tell them whether a signed component matched an approved internal source state. Shared responsibility becomes evasive when it assigns customers a control they cannot exercise.

The proper conclusion is therefore not that customers were helpless or that they caused the compromise by trusting updates. Applying signed vendor updates is generally expected security behavior. Customers are accountable for limiting the blast radius of a trusted component and for maintaining independent detection. SolarWinds is accountable for the integrity of the product it authorized and distributed. Those responsibilities overlap in risk reduction without becoming interchangeable.

Government responsibility: buyer, coordinator, and continuity owner

The federal government was not only a victim. It was a major buyer, a regulator and standard setter, an intelligence holder, and the operator ultimately responsible for public missions.

Before SolarWinds, federal supply-chain risk management was already incomplete. GAO's May 2021 testimony noted that none of 23 reviewed civilian agencies had fully implemented selected foundational information and communications technology supply-chain practices. The timing matters: government cannot reasonably place the whole burden on a vendor while failing to inventory, assess, and continuously manage the critical software on which agencies depend.

Agencies controlled product placement, service-account privileges, network egress, identity architecture, logging, procurement requirements, and recovery capacity. CISA's emergency direction was necessary in part because affected agencies had to act consistently and quickly. A mature continuity plan should already know where Orion is installed, what it can reach, which credentials it uses, what operational visibility disappears when it is disconnected, and how to replace that function temporarily.

Government also held aggregate advantages unavailable to one customer. CISA, the FBI, NSA, ODNI, and sector partners could combine classified and unclassified information, correlate reports, publish indicators, and coordinate eviction. GAO found that the Cyber Unified Coordination Group helped organize the response, while also identifying challenges involving information sharing and private-sector access. Coordination latency has public cost when every affected organization is separately trying to determine whether the same signed file is dangerous.

Procurement is one of government's strongest preventive levers. Buyers can require secure-development attestations, incident-notification terms, artifact provenance, vulnerability disclosure, evidence retention, cooperation during response, and rights to obtain independent assurance. They can also avoid check-box compliance that asks whether a supplier has a secure development lifecycle without testing whether a build can diverge from reviewed source.

The post-incident policy record moved in that direction. NIST's Secure Software Development Framework includes practices for protecting development environments, preserving provenance, verifying releases, responding to vulnerabilities, and preventing recurrence. NIST's cybersecurity supply-chain guidance places supplier risk inside enterprise governance rather than leaving it to a procurement questionnaire. OMB's M-22-18 memorandum required federal agencies to obtain software-producer attestations tied to NIST secure-development practices for covered software.

Attestation is useful only if it is truthful, scoped, and testable. A signed declaration cannot solve the same epistemic problem as a signed binary if the underlying production evidence is unavailable. High-consequence buyers need the ability to request artifacts, exceptions, independent assessments, and corrective plans. False assurance can increase risk by encouraging rapid trust without providing a way to verify the claim.

The legal record does not supply a simple verdict

Operational accountability and legal liability diverged sharply after the incident.

In October 2023 the SEC charged SolarWinds Corporation and chief information security officer Timothy Brown with fraud and control violations. The SEC litigation release alleged that public statements overstated security practices and understated known risks before SUNBURST. Those allegations were significant, but a complaint is an advocate's pleading, not a finding of fact.

In July 2024 the U.S. District Court for the Southern District of New York dismissed most of the SEC's claims. The court allowed securities-fraud claims based on the company's pre-SUNBURST website Security Statement to proceed, finding the amended complaint adequately pleaded misleading claims about access controls and password practices. It dismissed claims based on risk disclosures, the December 2020 Form 8-Ks, post-incident statements, internal accounting controls, and disclosure controls. The decision applied pleading and securities-law standards. It did not conduct a trial on the technical cause of SUNBURST or declare the build process safe.

On November 20, 2025, the SEC and defendants stipulated to dismissal with prejudice. The agency's final litigation release said the decision was an exercise of discretion and did not necessarily reflect its position in another case. Dismissal with prejudice ended that enforcement action. It means the surviving allegations did not become a final liability judgment.

This sequence supports four disciplined conclusions.

First, the SEC's original theory should not be repeated as established fact. Many claims were dismissed, and none produced a trial judgment.

Second, dismissal of the enforcement case should not be presented as technical proof that SolarWinds' build controls met an adequate standard in 2019 and 2020. The case concerned particular statements, elements, statutes, and pleading rules. A court can reject a securities claim while an engineering control failure remains documented.

Third, the surviving website-statement claim before dismissal shows that voluntary security representations can create accountability risk when they are broad and difficult to reconcile with internal conditions. Vendors should describe outcomes, scope, exceptions, and assurance evidence precisely rather than promise a generalized security posture.

Fourth, legal uncertainty does not prevent a control-capability analysis. SolarWinds controlled the factory; customers controlled deployment boundaries; government controlled public procurement and coordination; the SVR controlled the hostile campaign. Contracts, damages, causation, jurisdiction, and statutory duties determine whether that operational map becomes a legal remedy. No source used here supports assigning a percentage of legal liability among those parties.

The episode also revealed a policy tension. Aggressive enforcement may improve candor when companies minimize known incidents. It may also deter internal documentation or voluntary threat sharing if security staff believe every preliminary concern will later be pleaded as fraud. The better accountability regime rewards prompt, confidence-labeled disclosure while penalizing materially false claims proven under appropriate standards. It should not require perfect prevention as the price of being treated as a victim.

Remediation must change the evidence, not just the architecture diagram

SolarWinds reported extensive changes after discovery: broader multifactor authentication, tighter least privilege, stronger review of third-party applications, enhanced monitoring, redesigned build processes, multiple isolated builders, separate credentials, output comparison, static analysis, open-source analysis, penetration testing, and asset tracking. Its public sharing of SUNSPOT details gave other producers a concrete threat model. These are relevant and mechanism-specific responses.

The strongest remediation claim is not "we now build in three places." It is a body of evidence showing that an unauthorized transient source change cannot reach a signed release without creating a detectable mismatch. That evidence should survive personnel changes, deadline pressure, emergency patches, and builder replacement.

A credible assurance package would answer at least these questions:

1. Can every released binary be traced to an immutable approved source revision, dependency set, compiler and build policy?
2. Are build workers ephemeral or restored from a verified state, and are their control planes isolated from ordinary corporate identity?
3. Can one credential alter the build, suppress telemetry, and request a production signature?
4. Are separate builds genuinely independent, or do they share a hidden dependency that can produce identical compromise?
5. Does the signing service verify provenance and policy, or will it sign any artifact presented by an authorized account?
6. Are build and signing logs written to a separately administered, tamper-resistant store and retained for the dwell time expected from a state actor?
7. Are test canaries or controlled fault injections used to prove that unauthorized build variation stops a release?
8. Can the vendor revoke a release, notify customers by exposure class, and provide clean recovery artifacts without destroying forensic evidence?
9. Do customers receive verifiable provenance or only a signature and a marketing assurance?
10. Are exceptions visible to leadership and customers whose risk changes because of them?

These are not demands for disclosure of source code or sensitive production secrets to every buyer. Independent auditors, government assessors, and controlled transparency mechanisms can validate outcomes without publishing an attack map. The objective is evidence proportionate to the product's privilege and systemic reach.

Customers need complementary proof. They should be able to show that Orion or an equivalent management platform cannot freely reach every administrative tier; that service accounts are scoped; that outbound traffic is allow-listed where practical; that identity and DNS logs leave the managed environment; that a compromised management server can be isolated without losing all operational awareness; and that cloud federation can be rebuilt from known-good authority.

Government buyers should test continuity, not just receive paperwork. A tabletop exercise can ask an agency to disconnect its network-management platform within hours, enumerate associated credentials, preserve evidence, restore visibility with an alternative tool, and coordinate identity reset. Failure in that exercise identifies public risk before a real directive arrives.

A practical allocation of accountability

The incident becomes clearer when responsibility is assigned by control capability rather than by proximity to the headline.

The Russian SVR, according to the U.S. and allied attribution, planned and conducted the espionage campaign. It chose to compromise a supplier, engineered SUNSPOT and SUNBURST, selected downstream targets, and used stolen access. Its culpability is primary and intentional.

SolarWinds controlled whether its internal access architecture limited the actor, whether build output had to correspond to approved source, whether builders and signing were independently supervised, whether anomalous release behavior produced an alert, and whether customers received accurate and timely evidence. The company also controlled important parts of remediation and disclosure. Its status as a victim does not remove those responsibilities; its later transparency does not erase the original failure, but it can reduce future harm.

Customers controlled product placement, privilege, network paths, log retention, incident escalation, and identity recovery. An organization that gave Orion unrestricted administrative reach with weak external monitoring accepted more consequence than one that isolated the platform. That difference affects preventability and damages even though neither customer caused the malicious release.

Cloud and identity providers controlled cross-tenant telemetry and mechanisms for detecting or invalidating forged or abused authentication. Follow-on cloud access turned a software-supply-chain incident into a broader identity incident. Provider cooperation and logs were therefore part of restoring trust.

Federal agency leaders controlled mission continuity, inventories, procurement conditions, and implementation of government-wide supply-chain practices. CISA and partner agencies controlled coordinated alerts, directives, tools, and shared incident understanding. Congress and regulators controlled oversight and incentives, subject to the limits of their statutory authority.

Executives and boards at software producers control the resources and incentives that determine whether build security is a product requirement or a best-effort internal project. A build pipeline for software with administrative reach is part of the product's safety boundary. Investment decisions about it should be governed like decisions about the shipped code.

No party's responsibility cancels another's. "The customer should have segmented Orion" does not answer why an unauthorized artifact was signed. "SolarWinds should have protected the build" does not answer why a management server could reach a customer's highest-value identities. "The SVR was sophisticated" does not answer whether independent build verification existed. A mature account allows all three statements to be true and still asks what each party must prove now.

The durable lesson: signatures need a chain of production truth

The SolarWinds compromise changed software-supply-chain policy because it exploited a habit that was otherwise desirable: obtain updates from the vendor, verify the signature, and apply them promptly. The event did not make that habit irrational. It showed that customer trust had outrun the evidence exposed by the production process.

The corrective model is a chain of production truth. Approved source should lead to an identified build request. The request should run in a hardened, observable environment. Dependencies and tools should be pinned and recorded. The resulting artifact should be compared against an independent expectation. Signing should occur only after policy and provenance checks. Distribution should preserve the artifact. Customers should be able to verify more than possession of the signing key. Logs should make every link investigable after a long dwell period.

That model also improves public continuity. When a release is questioned, agencies can determine which artifact they ran, which source and builder produced it, what privileges it had, what it contacted, and which identities must be recovered. Uncertainty narrows. Response becomes targeted rather than indiscriminate. Essential services spend less time rebuilding systems that can be proved clean and more time on those that cannot.

SolarWinds should not be remembered only as a company that was hacked or as a symbol used to demand unlimited vendor liability. The more useful lesson is institutional. A software producer can become infrastructure for its customers even when it sells an on-premises product. Its build system can become a public trust boundary even when customers never see it. And a cryptographic signature can be perfectly valid while the organizational claim people attach to it is false.

The accountability standard should follow from that reality. The attacker is responsible for the intrusion. The vendor is responsible for making the release path resistant, observable, and honestly described. The customer is responsible for containing the product and preserving independent evidence. Government is responsible for buying with those dependencies in view and for sustaining public missions when trust collapses. The 2020 Orion campaign crossed all four domains. Durable remediation must do the same.