Supply-chain case study · retrospective
SolarWinds / SUNBURST · December 2020The SolarWinds campaign hit 18,000+ organisations through a single compromised vendor build pipeline. We are not going to claim that a registry would have detected SUNBURST in customer environments — SUNBURST shipped signed by SolarWinds' own code-signing certificate, through the legitimate update channel. What we will tell you is how OrbitalReg is built so that this class of attack on our own build pipeline is externally verifiable.
What happened
Between September 2019 and at least September 2020, the actor commonly tracked as APT29 (Cozy Bear / Nobelium) maintained access inside SolarWinds' build infrastructure. They injected the SUNBURST implant into the build output of the SolarWinds Orion network-monitoring product without touching the upstream source tree.
Builds were signed with the legitimate SolarWinds code-signing cert and published through the legitimate auto-update channel. 18,000+ Orion customers — including multiple US federal agencies — received the trojanised update and ran it. SUNBURST lay dormant ~12 days post-install before reaching out to its C2 infrastructure via DNS, then selected high-value targets for hands-on-keyboard escalation.
The campaign was discovered in December 2020, when FireEye identified that their own red-team tooling had been exfiltrated. Reverse-engineering led to the Orion compromise. By that point the implant had been distributed for months.
The honest framing
SUNBURST was not a public-registry attack. It was an attack on a single vendor's own build infrastructure, distributing a signed product update to that vendor's own customers. No package-registry CVE-gate, signature check, or air-gap-mode flag would have prevented the binary from running, because the binary was trusted on every axis a registry checks: it was the right version, signed by the right key, served by the right vendor.
The defenses against the SolarWinds class of attack live on the vendor's side, not the customer's side. Reproducible builds, externally verifiable provenance, SBOMs for every release, Sigstore identities tied to public OIDC accounts rather than internal signing-key vaults. Each of these makes the relevant kind of attack externally observable, instead of "you'd have to already be inside the vendor to know."
We can't promise our customers a registry will save them from the next SolarWinds. We can promise the way we build and ship OrbitalReg itself is designed to make a SolarWinds- class compromise of us something a careful customer could detect from the outside.
How we build OrbitalReg
Every OrbitalReg release tag is buildable from source on customer-side build infrastructure. The published binary's SHA-256 matches the rebuild's SHA-256. A SolarWinds-class compromise of our build server would produce a binary whose hash does not match — a discrepancy any customer can detect in CI, without our cooperation.
Release artefacts are signed with the OrbitalReg GitHub Actions OIDC identity via Sigstore. There is no "code-signing cert in a vault" for an attacker to steal. To forge a release, an attacker would need to compromise the public CI workflow itself — which is auditable in the public git history.
Each release ships with a CycloneDX 1.5 SBOM listing every dependency by name and version. Maps cleanly to NIST SSDF, the EU Cyber Resilience Act, and US EO 14028. A SolarWinds- style implant would have to add or modify entries the customer can diff against the previous release.
Air-gapped customers receive updates as signed bundles on signed media or via signed HTTPS — never runtime phone-home, never an auto-update channel we control unilaterally. The operator pulls when they're ready, after they've verified. SolarWinds-style auto-update is not a delivery mode we offer.
For your records
Honest caveats
This is not "use OrbitalReg to defend against SolarWinds-class threats." SolarWinds was a vendor-pipeline attack. Defending against it as a customer requires watching your vendor's provenance signals — reproducible builds, public CI, SBOM diffs — which OrbitalReg cannot do for you, but can do about itself.
It is "we built OrbitalReg to make a SolarWinds-class compromise of us externally visible." The four commitments above are designed so that a careful customer running rebuild verification in their own CI is positioned to detect a compromise of our pipeline before we are.
We are not claiming we'd never be breached. Determined nation-state actors with multi-year dwell time can compromise any infrastructure. The claim is that when it happens, our customers have the tools to know about it from first principles, rather than having to wait for us to send a disclosure.
Primary sources
Want to externally verify our build pipeline?
Rico, the founder, walks you through how to wire OrbitalReg release verification into your own CI — and what the resulting independent-attestation evidence looks like to your auditors.
