On December 13, 2020, FireEye disclosed that an adversary had breached SolarWinds' Orion build system, injected the SUNBURST backdoor into legitimately signed updates, and used that foothold to compromise something like eighteen thousand downstream customers including nine US federal agencies. It was the moment "software supply chain security" stopped being a niche concern of artifact-signing nerds and started being the phrase that executives kept repeating on earnings calls. Two years in, the policy landscape has moved a lot: Executive Order 14028, the first full draft of the NIST Secure Software Development Framework, the SLSA specification reaching v0.1, and Sigstore reaching general availability. The question is whether any of that has made the actual attack — compromise the build, sign a backdoor, ship it through the normal update channel — materially harder. The short answer is: in narrow pockets, yes. Across the industry average, not really. Here is the honest accounting.
What did the SUNBURST attackers actually do to the build system?
The SUNBURST attackers modified the Orion build process so that during compilation, a malicious source file was injected, compiled into the signed DLL, and then the source was deleted, leaving the committed repository clean. Crowdstrike's reverse-engineering report on SUNSPOT — the implant that performed the injection — described a tool that watched for MsBuild.exe processes compiling specific Orion project files, replaced the InventoryManager.cs file on disk at the moment of compilation, then restored the legitimate file once the compiler had read it. The result: a build artifact containing code that appeared nowhere in version control, signed with SolarWinds' real Authenticode certificate, and distributed through the exact update infrastructure that enterprise customers had been told to trust.
This is the attack pattern that SLSA, SSDF, and the in-toto attestation framework were all designed to make harder. The defense is not one control — it is an entire chain of them, each breaking one step of that kill chain.
Which defenses have actually been adopted at scale?
The defense that has actually been adopted at scale is artifact signing for public open-source releases, driven almost entirely by Sigstore. By the end of 2021, npm had announced plans for Sigstore-based signatures, Python's PyPI was running experimental support, and Kubernetes had signed every release artifact for v1.24 onward. Google's internal SLSA adoption, according to their public writeups, covers roughly the entire Google-authored open-source footprint for levels 2 and 3. That is real progress.
The defenses that have not been adopted at scale are the ones that matter most for the SolarWinds scenario specifically: hermetic, reproducible builds for proprietary enterprise software. A 2021 Atlantic Council survey of enterprise build practices found that roughly seven percent of respondents could reproduce a release binary bit-for-bit from source, and fewer than two percent ran builds in ephemeral, network-isolated environments. The overwhelming majority of enterprise builds still happen on long-lived Jenkins or TeamCity agents, with broad network access, mutable filesystems, and the same attack surface that SUNSPOT exploited.
What did Executive Order 14028 actually require?
Executive Order 14028, signed May 12, 2021, actually requires federal software suppliers to produce attestations of secure development practices and to provide Software Bills of Materials on request. The operative word is "attestations" — self-reported, not audited. NIST SP 800-218 (the SSDF) and the accompanying NIST 800-161r1 (C-SCRM) were published in February 2022 to give those attestations some common vocabulary, but the enforcement mechanism is procurement: agencies are directed to require these attestations from vendors, and vendors who cannot provide them lose federal business.
What that has produced, in practice, is an industry-wide scramble to generate SBOMs that technically satisfy the NTIA minimum elements — supplier name, component name, version, dependency relationship, author, timestamp, and unique identifier — without necessarily reflecting the full composition of what ships. A CycloneDX or SPDX document with three hundred components looks better than one with thirty, but the forty percent of enterprise apps that include vendored dependencies, private forks, or statically linked native libraries still mostly under-report.
Has Sigstore solved the signing problem for proprietary software?
Sigstore has solved the signing problem for public open source, and has not yet solved it for proprietary software because most proprietary builds do not have a public, federated identity to sign with. The elegance of Sigstore for open-source projects is that the signing identity comes from OIDC — "this artifact was built by GitHub Actions running in the kubernetes/kubernetes repo on commit abc123" — and the transparency log (Rekor) makes tampering detectable. For a proprietary enterprise build that does not want to publish its commit hashes to a public log, that model does not translate directly.
The workable pattern for enterprise is a private Rekor deployment, a private Fulcio CA tied to the company SSO, and keyless signing against internal OIDC. Chainguard's early 2022 release notes describe this setup, and a handful of regulated financial services firms have stood it up, but it is deeply non-trivial. For the median enterprise, signing is still "we have an HSM somewhere, someone knows where the key is."
# What a SLSA v0.2 provenance looks like for a signed release
_type: "https://in-toto.io/Statement/v0.1"
predicateType: "https://slsa.dev/provenance/v0.2"
subject:
- name: "orion-setup.exe"
digest: {sha256: "a1b2c3..."}
predicate:
builder: {id: "https://github.com/org/repo/actions"}
buildType: "https://github.com/slsa-framework/..."
invocation:
configSource:
uri: "git+https://github.com/org/repo@refs/heads/main"
digest: {sha1: "abc123..."}
What should a post-SolarWinds build pipeline look like in 2022?
A post-SolarWinds build pipeline in 2022 should have four properties that SolarWinds' pipeline demonstrably did not: ephemeral build environments, explicit input materials, signed attestations tied to those inputs, and downstream verification. Ephemerality means the builder is a fresh, network-restricted container or VM that is destroyed after the build — a SUNSPOT-equivalent implant has nowhere persistent to live. Explicit inputs means every file the compiler reads is enumerated, hashed, and recorded. Signed attestations means the provenance document is produced by the build platform itself, not the maintainer's laptop. Downstream verification means the deploying system (Kubernetes admission, Windows installer trust, a package manager) refuses artifacts without a matching attestation.
Google's internal build system, Microsoft's CBL-Mariner pipeline, and GitHub's own Actions hosted runners all satisfy some version of this today. Most enterprise Jenkins estates do not, and the gap is the SolarWinds attack surface.
How Safeguard Helps
Safeguard ingests SBOMs from every build in your pipeline, validates SLSA provenance attestations against the source repository they claim to come from, and flags artifacts where the provenance is missing, unsigned, or inconsistent with the build configuration. The policy-gate engine lets you refuse to deploy artifacts that fail those checks, turning the attestation from a compliance document into an enforced control. Griffin AI surfaces composition drift — the signal that SUNSPOT-style build tampering would produce — by comparing each new SBOM against the expected baseline for that service. For suppliers you depend on but do not control, the TPRM module tracks their SLSA level and attestation quality over time, so a SolarWinds-class vendor regression is visible before the next update lands in production.