SLSA and SBOM in delivery
SolarWinds and the XZ backdoor shipped through trusted build pipelines, not exploits. SLSA provenance plus signing proves how an artifact was built and that it is the one you reviewed; an SBOM lists what is inside so you can answer 'am I affected' in minutes.
Your scanners were green. Every dependency had a clean CVE report, the image passed the registry policy gate, and the deploy went out on a Friday. Three weeks later you learn the version you shipped was never the version in your repo: someone with write access to a self-hosted build runner swapped one compiled object after the tests ran. That is exactly the SolarWinds shape — a malicious DLL injected into a trusted, signed, passing build, distributed to 18,000 organizations. No exploit kit cracked the perimeter. The perimeter built the malware for them. The whole class of supply-chain compromise lives in the gap between “this artifact passed” and “this artifact is the one I reviewed” — and closing that gap is what SLSA provenance, artifact signing, and SBOMs are for.
By the end of this lesson you’ll know what provenance and signing actually prove (and what they don’t), where an SBOM fits, and how to reach the SLSA level that would have caught a SolarWinds-style tamper.
The trust gap a passing build leaves open
A normal pipeline answers “did the code pass?” It does not answer “is the thing I’m about to deploy the genuine output of that passing run, unmodified, from source I control?” Those are different questions, and the second one is where supply-chain attacks live. SolarWinds (a build-system implant), Codecov (a leaked bash-uploader credential rewriting CI output), and the 2024 XZ Utils backdoor (a malicious maintainer landing obfuscated code into release tarballs that differed from the git tree) all bypassed every input-scanning control teams had. None of them was an injection bug or an unpatched CVE. They were tampering with the production of the artifact — and your dependency scanner, by design, never looks there.
So the supply-chain problem decomposes into three questions you must be able to answer about anything you deploy:
- How was it built? — the build’s provenance: which source commit, which builder, which parameters, with no human able to silently inject steps. This is SLSA’s domain.
- Is this the exact artifact that was built? — integrity, established by a cryptographic signature over the artifact’s digest, verified at admission time.
- What is inside it? — its bill of materials: every component and version, so when the next Log4Shell drops you can answer “are we affected?” from an index instead of a frantic grep across every service. This is the SBOM.
SLSA, signing, and SBOM are not competing standards — they answer those three questions in order, and you need all three. Provenance with no signature is a claim anyone can forge; a signature with no provenance proves who released it but not that the build was honest; both without an SBOM leave you blind the day a transitive dependency turns out to be radioactive.
SLSA: provenance and the levels ladder
SLSA (Supply-chain Levels for Software Artifacts, pronounced “salsa”) is a framework that grades how trustworthy a build process is. Its core artifact is provenance: a signed, machine-readable statement that says this output digest was produced from that source revision, by that builder, with these parameters. The point is non-repudiation of the build itself — a verifier downstream can check that the binary in front of it actually came out of the pipeline it claims to, rather than being swapped in afterward.
SLSA v1.0 defines a Build track with levels that escalate the guarantees about the builder, not the amount of paperwork:
| Build level | What it requires | What it stops |
|---|---|---|
| L0 | No guarantees | Nothing — the default |
| L1 | Scripted build + provenance exists (may be unsigned) | Mistakes-of-record; “what built this?” is answerable |
| L2 | Hosted build platform + signed provenance | Forged provenance; tamper after build is detectable |
| L3 | Hardened, isolated builder; provenance is unforgeable by build steps | A malicious build step injecting itself — the SolarWinds shape |
The jump that matters is L2 → L3. At L2 a signed provenance proves the artifact wasn’t swapped after the build, but a compromised build script could still lie in the provenance it generates. L3 demands the build run in an isolated, ephemeral environment where the provenance is generated by the platform, not by user-controlled build steps — so the malicious step that swapped SolarWinds’ object can’t also forge a clean attestation about itself. That isolation is the actual security boundary; the level number is just shorthand for “how much can a bad build step lie.”
The practical path is unglamorous: most managed CI (GitHub Actions with the official SLSA generator, GCB, Tekton Chains) gives you signed L2/L3 provenance for the cost of a workflow change. The trap is a self-hosted runner you reuse across jobs — shared state between builds collapses you back below L3 no matter what attestation you emit, because a prior job can poison the next.
Signing: keyless, with a transparency log
Provenance is only as good as the signature over it, and key management is where signing programs go to die. The modern answer is keyless signing (Sigstore’s cosign): instead of a long-lived private key sitting in a secret store waiting to leak, the builder authenticates with a short-lived OIDC identity (e.g. the GitHub Actions workload identity), Fulcio issues an ephemeral certificate bound to that identity, the signature is made, the key is discarded, and the whole event is recorded in Rekor, a public append-only transparency log.
This buys two things a static key can’t. First, there’s no key to steal — the signing key existed for seconds. Second, the Rekor entry is tamper-evident: a backdated or forged signature has no matching transparency-log record, so verification can require “must appear in Rekor before timestamp T.” You verify by identity and provenance, not by trusting that a key was kept safe for three years.
▸Common mistake
The seductive mistake is treating a green signature as proof of safety. A signature only proves integrity and origin — “this is the exact artifact identity X published.” It says nothing about whether the artifact is malicious. The XZ backdoor was, in a sense, properly released by the project’s own maintainer; a signature would have verified cleanly. Signing stops tampering and impersonation; it does not vouch for intent. You still need provenance (was the build honest?), SBOM-driven scanning (what’s inside?), and code review (is the source itself trustworthy?). Treating “signed” as “safe” is how a verified-but-evil artifact sails through the gate.
SBOM: answering “are we affected?” in minutes
An SBOM (Software Bill of Materials) is the ingredient list: every component, version, and license inside an artifact, in a standard machine format — SPDX or CycloneDX. You generate it at build time (e.g. Syft, or your build tool’s native exporter), attach it as a signed attestation alongside the provenance, and store it where incident response can query it.
Its value is asymmetric and shows up on exactly one kind of day. When Log4Shell broke in December 2021, the teams without an SBOM spent days running find across hundreds of services to discover whether log4j-core was bundled — often transitively, three levels deep, inside a fat JAR they didn’t know contained it. The teams with a queryable SBOM index answered “which of our 400 deployed artifacts contain log4j-core in the affected range?” in minutes and scoped their response to the handful that did. The SBOM doesn’t prevent the vulnerability; it collapses your mean-time-to-answer from days to a query, which is the difference between a controlled rollout and a weekend of panic.
The senior nuance: an SBOM is only trustworthy if it’s generated from the built artifact and signed as an attestation, not hand-maintained in a wiki. A stale or build-from-source-only SBOM that misses what the final image actually bundled is worse than none, because it answers “are we affected?” with false confidence.
A team builds release artifacts on a self-hosted CI runner that is reused across all jobs, signs them with a long-lived private key stored in the secrets manager, and emits SLSA provenance. They want to actually prevent a SolarWinds-style tamper. Pick the change that closes the real gap.
What does an artifact signature (e.g. cosign) actually prove?
Why is the SLSA L2 → L3 jump the one that matters for a SolarWinds-style attack?
Order the verified supply-chain pipeline from source to running workload:
- 1 Reviewed source commit enters an isolated, ephemeral builder
- 2 Builder produces the artifact + its digest
- 3 Platform emits signed SLSA provenance and an SBOM attestation
- 4 Admission gate verifies signature, provenance, and policy
- 5 Artifact admitted and the workload runs
- 01Explain the three questions SLSA, signing, and SBOM each answer, and why you need all three.
- 02Why is the SLSA L2→L3 jump the security boundary, and what does keyless signing add on top?
Supply-chain attacks like SolarWinds, Codecov, and the XZ backdoor didn’t break the perimeter — they tampered with how the artifact was produced, in the gap between “this build passed” and “this is the honest, unmodified output of source I trust.” Three controls close that gap, each answering a different question. SLSA provenance answers how it was built: a signed attestation binding the output digest to a source revision and builder, where the L2→L3 jump — running the build in an isolated, ephemeral environment with platform-generated provenance — is the boundary that stops a malicious build step from forging a clean record about itself (and a reused self-hosted runner silently drops you below it). Signing answers whether it’s that exact artifact, with keyless Sigstore signing removing the long-lived key as a theft target and Rekor’s transparency log making backdated signatures detectable — but a signature proves origin and integrity, never that the code is benign. An SBOM (SPDX or CycloneDX, generated from the built artifact and signed as an attestation) answers what’s inside, collapsing “are we affected by this new CVE?” from a days-long grep into a minutes-long query. Verify all three at the admission gate, and the next time a build comes back green your first question is no longer “did it pass?” but “can I prove this is the artifact my pipeline honestly built from source I reviewed — and do I know what’s in it?”
Practice
Start at the top. Tasks go easiest → hardest: recall a fact, apply it to a case, then a senior-level stretch. Open one, attempt it, then reveal.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.