CISA's advisory on the SolarWinds Orion compromise says the attacker added a malicious version of an Orion library into the software lifecycle, and that it was signed with SolarWinds' legitimate code-signing certificate. A signature proves who signed a file. It does not prove the file was built from the source you expect.
What CISA reports
Advisory AA20-352A says compromises began at least as early as March 2020. The malicious file was solarwinds.orion.core.businesslayer.dll. After installation it beaconed to a victim-specific subdomain of avsvmcloud[.]com, using a protocol designed to mimic legitimate SolarWinds traffic. The advisory lists five affected Orion Platform builds from 2019.4 HF5 through 2020.2 HF1.
On 13 December 2020 CISA issued Emergency Directive 21-01, ordering federal civilian agencies to disconnect affected devices. On 15 April 2021 the US government attributed the activity to Russia's Foreign Intelligence Service.
What a code signature actually tells you
When a customer's update process checked the signature, the check passed. The file really did come from SolarWinds' signing process. The weakness was upstream of the signature: the malicious code entered before the file was signed.
So a signature answers "did the holder of this key sign it?" It does not answer "is this the code that was reviewed?" or "was the build environment clean?" Those questions need other controls.
Controls that address the gap
- Build isolation. Run builds on ephemeral, locked down infrastructure with limited access, so tampering requires more than one stolen credential.
- Reproducible builds. If independent builds of the same source produce identical output, injected code stands out.
- Provenance attestations. A signed record of which source, builder and steps produced an artifact lets consumers verify the chain. Frameworks such as SLSA describe levels of this.
- Review of build scripts. Pipelines are code. Changes to them deserve the same review as changes to the product.
- Behavioural monitoring on the consumer side. The advisory describes network indicators for the backdoor, which shows why egress monitoring matters even for trusted software.
What customers could do
CISA recommends treating the identity trust store as compromised when administrator credentials or SAML abuse are found, rebuilding from trusted sources, and retaining logs for at least 180 days. For a vendor, the lesson is different: assume your build system is a target and design so a single compromise cannot ship unreviewed code.
A note on scope
The CISA advisory is archived, and it says guidance may have changed. Check CISA's current supply chain resources before acting on it.
Safeguard's SBOM and dependency scanning and its policies and gates can help you decide which third party artifacts reach production. For the identity side of this incident, see what happened after the implant.
Quick check
Did the malicious Orion file have a valid signature?
According to CISA, it was signed with SolarWinds' legitimate code-signing certificate.
Does signing prove the code is safe?
No. It proves who signed it, not how or from what it was built.
Sources
Last reviewed: 19 October 2026.
