The SolarWinds attack explained for developers
When security teams talk about supply chain attacks, SolarWinds is usually the first example cited. It is the highest-profile software supply chain attack in history — compromising US government agencies, Fortune 500 companies, and major security firms simultaneously. But its mechanism is quite different from npm and PyPI attacks, and the lessons it teaches are both directly applicable and frequently misunderstood.
What SolarWinds actually was
SolarWinds makes IT monitoring software called Orion. Thousands of companies and government agencies use Orion to monitor their internal network infrastructure. Because Orion needs to see everything on the network, it runs with highly privileged access to the systems it monitors.
In early 2020 (possibly as early as October 2019), attackers — later attributed to a Russian intelligence unit (APT29 / Cozy Bear) — gained access to SolarWinds' internal build environment. They modified the build process to inject malicious code into Orion software updates.
The modification was subtle. The malicious code — a backdoor called SUNBURST — was added to a DLL that was part of the Orion build. The modified DLL was compiled as part of normal builds, signed with SolarWinds' legitimate code signing certificate, and shipped to customers as a normal software update.
Between March and June 2020, approximately 18,000 organizations installed the compromised Orion update. The backdoor lay dormant for two weeks after installation before activating, to avoid triggering anomaly detection systems that might flag unusual behavior immediately after an update.
The compromise was discovered in December 2020 — six to nine months after the initial build environment access — by FireEye, whose own systems had been compromised using the SolarWinds backdoor.
What makes it different from npm/PyPI attacks
The target. SolarWinds targeted government agencies and major enterprises specifically. The attacker's goal was intelligence gathering, not credential theft at scale. npm and PyPI attacks are typically less targeted — they aim to compromise as many developer machines as possible and exfiltrate whatever credentials they find.
The sophistication. Modifying a build environment, adding dormant backdoor code to a compiled binary, maintaining access for six to nine months without detection — this is significantly more sophisticated than a compromised npm maintainer account. SolarWinds is attributed to a nation-state actor with substantial resources. Most npm and PyPI attacks are criminal operations.
The distribution mechanism. SolarWinds used the software update mechanism — customers explicitly approved the update and installed it. npm and PyPI attacks use the package installation mechanism — developers explicitly run npm install or pip install. In both cases, the distribution channel is trusted.
The detection timeline. SolarWinds went undetected for six to nine months. Most npm and PyPI attacks are detected within days to weeks. The longer timeline reflects both the greater sophistication of the attackers and the use of targeted activation (only affect specific high-value targets) rather than broad exfiltration.
What applies to npm and Python security
Build environment integrity matters. The SolarWinds attack succeeded because the build environment was compromised. For npm packages, this means: the build environment that creates your release artifacts is part of your attack surface. If CI is compromised, the published package is compromised regardless of what's in the source repository. npm Provenance addresses this by attesting to the build environment.
Code signing helps but isn't sufficient. SolarWinds' packages were signed with a legitimate code signing certificate. Signature verification doesn't protect against malicious code signed with a legitimate key — it only protects against code that was modified after signing.
Delayed activation evades behavioral detection. The SUNBURST backdoor's two-week dormancy period was specifically designed to evade immediate behavioral detection. In the npm/PyPI context, this is the "staged execution" technique: malware that doesn't activate on first install but on second import. Veln's canary sandbox runs all install lifecycle hooks at install time, which catches payloads that activate during install. Code that activates only later — when the module is actually imported in application code — requires different detection techniques (import monitoring, runtime analysis).
Supply chain visibility is a prerequisite. Many organizations affected by SolarWinds didn't have a complete inventory of what software was running on their systems. In the npm/PyPI context, many developers don't have complete visibility into their transitive dependency tree. You can't protect what you can't see.
SolarWinds was nation-state sophisticated. Most npm and PyPI attacks are not — and Veln still catches them.