The Breach: A Summary
In early 2020, attackers infiltrated SolarWinds' build environment, embedding malicious code into the Orion platform update process. When SolarWinds released the compromised update, about 18,000 organizations unknowingly installed software containing a backdoor. This breach remained undetected for months, allowing attackers ongoing access to victim networks.
The issue wasn't a flaw in the Orion code itself. Instead, attackers manipulated the build process to inject malware into legitimate, signed software updates that passed existing security checks.
Timeline of Events
Early 2020: Attackers accessed SolarWinds' build environment, injecting malicious code into Orion updates.
March - June 2020: Compromised Orion updates were released, and organizations downloaded the trojanized software through standard update channels.
December 2020: FireEye discovered the breach during an investigation of their own network compromise, raising industry-wide awareness.
Post-disclosure: Security teams globally rushed to identify affected systems and assess exposure, revealing significant gaps in validating software supply chain integrity.
Failed or Missing Controls
Build Environment Isolation: Attackers should not have accessed production build systems. SolarWinds lacked adequate segmentation between development networks and critical infrastructure for compiling and signing release artifacts.
Code Integrity Verification: No automated process detected discrepancies between the compiled binary and the source code repository. The build pipeline failed to confirm if the artifact matched the developers' original code.
Dependency and Build Tool Scanning: If malicious code entered via a compromised dependency or build tool, pre-build scanning could have flagged the anomaly before reaching production systems.
Artifact Signing Validation: Although SolarWinds signed their updates, customers couldn't verify that the signed artifact matched known-good builds or detect if the signing process was compromised.
Runtime Behavior Monitoring: Post-deployment, the malicious code exhibited network behaviors that should have triggered alerts. Most organizations lacked visibility into what "normal" looked like for their Orion installations.
Relevant Standards and Requirements
NIST 800-53 Rev 5 addresses supply chain risk management. SR-3 requires organizations to employ defined supply chain controls to protect against risks. SR-4 mandates documenting and verifying the origin of system components.
For software builders, SA-10 requires maintaining the integrity of system changes during development. SA-15 demands security requirements for the development environment itself—what failed at SolarWinds.
PCI DSS Requirement 6.3.2 states that security vulnerabilities must be identified and addressed throughout the software development lifecycle, including the build and release process. Requirement 6.2.4 extends to the tooling and infrastructure used to build software.
ISO/IEC 27001:2022 Annex A.8.31 covers the separation of development, test, and production environments, requiring controls to reduce risks from unauthorized access or changes to production systems, including build systems.
NIST Cybersecurity Framework maps to these requirements through the Identify and Protect functions, emphasizing understanding dependencies and protecting development environment integrity.
These standards exist because attackers target the weakest point in your deployment chain. For SolarWinds, that point was the build pipeline.
Lessons and Action Items for Your Team
Treat Your Build Environment as Production Infrastructure: If an attacker compromises your CI/CD pipeline, they control everything downstream. Apply the same access controls, monitoring, and hardening as for customer-facing systems.
Action: Implement network segmentation to isolate build systems from general development networks. Require MFA for all build system access. Log every action in your build pipeline and alert on anomalies.
Verify Artifact Integrity Automatically: Ensure the binary you're deploying matches the source code in your repository.
Action: Implement reproducible builds where possible. Generate and store cryptographic hashes of build inputs and outputs. Compare these hashes across builds to detect unexpected changes.
Scan Dependencies Before They Enter Your Build: Malicious code could enter through a compromised library or build tool.
Action: Integrate dependency scanning into your CI pipeline before the build step. Fail the build if vulnerabilities are detected or if a dependency hasn't been explicitly approved. Open Source Software Security
Give Developers Visibility into the Vulnerability Landscape: Developers need tools that surface vulnerability information when selecting or updating libraries.
Action: Deploy a vulnerability database that integrates with your development workflow. Developers should see security information in pull requests and dependency update proposals.
Implement Signing and Verification Throughout the Supply Chain: Signing alone isn't enough; verify the signing process itself hasn't been compromised.
Action: Use separate, highly restricted signing infrastructure. Implement a process where multiple parties must approve signing operations for critical releases. Verify signatures and maintain a record of known-good artifact hashes.
Monitor Runtime Behavior Against a Baseline: Even if malicious code reaches production, behavioral anomalies should trigger investigation.
Action: Establish baseline network and system behaviors for each application. Alert when applications contact unexpected external hosts, spawn unusual processes, or access files outside their normal scope.
The SolarWinds breach wasn't due to a zero-day exploit or sophisticated malware. It occurred because the build pipeline lacked basic integrity controls. Your organization likely has similar gaps. The question is whether you'll find them before an attacker does.
