Supply-Chain Security

Secrets Management was about protecting the credentials you hold. This page is about a trust problem you can’t solve by being careful with your own keys: the code you didn’t write, running in your production. A modern service is mostly other people’s code — hundreds of transitive dependencies, a base image full of OS packages, build tools, plugins — and every one of them executes with your application’s privileges. The supply chain is everyone whose code or artifacts end up in your running system, and an attacker who compromises any link gets in for free.

Artifacts & Registries established that you should build once and promote the same bytes, addressed by an immutable digest. That guarantees the bytes don’t accidentally change between staging and prod. Supply-chain security asks a sharper question: how do you know those bytes are the ones your pipeline actually produced — and not something an attacker substituted? Digests prove immutability; this page is about proving provenance and integrity.

The threat: a link you don’t control

The attack doesn’t need to touch your code at all. It can land at any upstream link.

   YOUR CODE  ─┐
   deps ───────┤
   base image ─┼──► build ──► artifact ──► registry ──► deploy ──► PROD
   build tools ┘                                ▲
                                                │
   an attacker who poisons ANY link here ──────┘  runs in prod with your privileges

• A popular library publishes a malicious update (a real and recurring category of attack — covered again in Supply-Chain Attacks).
• A base image carries a vulnerable or backdoored OS package.
• Your build system is compromised, so the artifact in the registry isn’t the one your source would produce — it has an extra payload.

That last one is the nastiest, because your source code review, your tests, and your digest pinning all pass — the malicious bytes are exactly what got built, just not from the code you think. Defending against it requires answering three questions for every artifact: What’s inside it? Where did it come from? Has it been tampered with? Three tools answer those, in order.

What’s inside it: the SBOM

A Software Bill of Materials (SBOM) is a complete, machine-readable inventory of every component in an artifact — every dependency, every version, every license. It’s the “ingredients label” for your software. Standard formats are SPDX and CycloneDX, and tools generate one automatically from a built image or a lockfile.

# Generate an SBOM for a built image (CycloneDX JSON).
syft ghcr.io/acme/app@sha256:9f86d0... -o cyclonedx-json > sbom.json

Why it matters: when the next widely-used vulnerability is announced, the question “are we affected?” becomes a query against your SBOMs instead of a frantic, days-long manual audit of every service. An SBOM is what makes the dependency scanning in the next page possible at all — you can’t check components you haven’t enumerated.

An SBOM describes; it doesn’t defend

An SBOM by itself catches nothing — it’s an inventory, not a scanner or a gate. Its value is that it makes everything downstream possible: scanning against vulnerability feeds, answering “are we affected?”, and proving to an auditor what you actually shipped. Generate it as a build output, store it next to the artifact.

Where it came from: provenance and attestation

Provenance is verifiable metadata about how an artifact was built: which source commit, which builder, on which workflow, at what time. An attestation is a signed statement asserting that provenance — “this artifact, identified by this digest, was built by this trusted pipeline from that commit.” Because it’s signed, you can verify it wasn’t forged.

This is the defense against the nasty case above. If you require that every artifact carry an attestation proving it came from your trusted build system, then an attacker who substitutes their own bytes can’t also produce a valid attestation (they don’t have the builder’s identity) — so verification fails and the deploy is blocked.

SLSA (Supply-chain Levels for Software Artifacts, pronounced “salsa”) is a framework that organizes these defenses into progressively stronger levels. The idea — not the exact thresholds, which you should check against the current spec — is a ladder:

• At the bottom, you simply have provenance: the build emits metadata about what it did.
• In the middle, that provenance is generated by the build platform itself and signed, so it can’t be faked by the code being built.
• Near the top, builds are hardened and isolated — tamper-resistant, reproducible, with no way for one build to influence another.

The point of the ladder isn’t a score to brag about; it’s a roadmap. Each rung closes a specific class of tampering, and you climb it as the artifact’s importance justifies the cost.

Has it been tampered with: signing and verification

The final link is integrity: cryptographically signing the artifact so a consumer can verify it’s the genuine one and was published by someone you trust. Sigstore is the modern, widely-adopted toolchain for this; its CLI is cosign.

# Sign an image by digest (keyless signing ties the signature to an OIDC identity).
cosign sign ghcr.io/acme/app@sha256:9f86d0...

# At deploy time, verify the signature came from your trusted CI identity.
cosign verify ghcr.io/acme/app@sha256:9f86d0... \
  --certificate-identity-regexp '^https://github.com/acme/.*' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

Sigstore’s notable trick is keyless signing: instead of a long-lived private key you must protect (itself a secret-management nightmare), it ties the signature to a short-lived OIDC identity — “this was signed by the GitHub Actions workflow in this repo” — and records it in a public transparency log. The signature you trust is bound to who and what, not to a key file someone could steal.

Signing only helps if you verify before deploy

A signature nobody checks is decoration. The control is the verification gate: your deploy step (or a Kubernetes admission controller) must refuse to run any image that isn’t signed by an identity you trust. “Generate signatures” is the easy half; “block unsigned artifacts” is the half that actually stops an attack.

   build ──► sign (cosign) ──► push ──► [REGISTRY]
                                            │
   deploy ── verify signature ─────────────┘
        │
        ├─ valid sig from trusted identity? ──► admit, run it
        └─ missing / wrong identity?        ──► REJECT, never runs

Under the hood — how “keyless” signing actually works

“Keyless” doesn’t mean no cryptography — it means no long-lived key for you to guard. Sigstore splits the job across two services. Fulcio is a certificate authority that, when cosign hands it a short-lived OIDC token (“I am the GitHub Actions workflow in this repo”), issues an ephemeral signing certificate — valid only for a few minutes — binding a freshly generated key pair to that verified identity. You sign within those minutes and then discard the private key; there is nothing left to steal or rotate.

Rekor is the other half: an append-only, tamper-evident transparency log that records the signature and certificate. Because the record is public and immutable, an attacker can’t quietly backdate or forge a signature without the mismatch being detectable. When you run cosign verify, it checks three things — the certificate chains back to Fulcio, the identity inside it matches the policy you specified (the --certificate-identity-regexp from the example above), and the signing event is logged in Rekor. The trust you place is in an identity plus a public log, not in a key file on someone’s laptop — which is what makes keyless signing practical to actually adopt.

The thread: what manual step disappears

The manual, error-prone step supply-chain security removes is trusting upstream code and artifacts on faith — pulling a dependency or a base image and assuming it is what it claims to be, with no way to inventory it, trace its origin, or detect tampering. SBOMs make the contents knowable, provenance makes the origin verifiable, and signing makes substitution detectable. Together they convert “trust me” into “verify me.”

Production gets safer because the trust boundary moves from hope to cryptography. A poisoned dependency shows up in an SBOM-driven scan; a tampered artifact fails attestation; an unsigned image is rejected at the admission gate before it ever runs. The cost is new pipeline machinery — generating and storing SBOMs, wiring up signing identities, enforcing verification — and the discipline to actually block on failures rather than just collecting metadata. The next page makes one of these defenses concrete and operational: finding the known vulnerabilities your SBOM just enumerated — Image & Dependency Scanning.

The architect’s lens

Five questions for securing the supply chain:

• Why does it exist? Because most of what runs in prod is code you didn’t write, and an attacker who poisons any upstream link — a dependency, a base image, your build system — runs with your app’s privileges for free.
• What problem does it solve? Trusting upstream on faith: SBOMs make contents knowable, provenance and attestation (SLSA) make origin verifiable, and signing (Sigstore/cosign, keyless via Fulcio + Rekor) makes substitution detectable — so even bytes that pass source review and tests fail attestation.
• What are the trade-offs? New pipeline machinery — generating and storing SBOMs, wiring signing identities, climbing the SLSA ladder — and an SBOM only describes; it defends nothing without the downstream scan and the verification gate.
• When should I avoid it? You climb the SLSA ladder only as far as an artifact’s importance warrants — full build isolation is overkill for a low-stakes internal tool.
• What breaks if I remove it? A digest still proves immutability but not provenance — so a tampered artifact from a compromised builder, or an unsigned image, runs unchallenged because nothing verifies it before deploy.

Check your understanding

1. Artifacts & Registries already pins images by digest. What extra guarantee does supply-chain security add that a digest alone does not provide?
2. What is an SBOM, and why is it described as a prerequisite for scanning rather than a defense by itself?
3. Explain provenance and attestation. How does requiring a signed attestation defend against an attacker who compromises your build system (where source review and tests still pass)?
4. SLSA is described as a ladder of levels. Without quoting exact numbers, what does climbing the ladder buy you, and why is each rung framed as closing a class of tampering?
5. Why is “we sign all our images” insufficient on its own? Name the control that actually stops a tampered artifact, and using the book’s thread, the manual step the whole chain removes.

Show answers

1. A digest guarantees immutability — the bytes can’t change silently between environments — but it says nothing about where those bytes came from. Supply-chain security adds provenance and integrity: proof that the artifact was built by your trusted pipeline from a known commit and hasn’t been substituted by an attacker.
2. An SBOM is a complete machine-readable inventory of every component (dependencies, versions, licenses) in an artifact — its ingredients label. It defends nothing by itself; its value is enabling everything downstream: scanning components against vulnerability feeds, answering “are we affected?” when a new CVE drops, and proving what you shipped.
3. Provenance is verifiable metadata about how an artifact was built (source commit, builder, workflow); an attestation is a signed assertion of that provenance. Requiring it defends the compromised-build case because the attacker can produce malicious bytes but cannot forge a valid attestation from the trusted builder’s identity — so verification fails and the deploy is blocked, even though source review and tests passed.
4. Each rung hardens a different stage: at the bottom you merely have provenance; in the middle it’s generated by the build platform and signed (so the built code can’t fake it); near the top builds are isolated and tamper-resistant. Climbing buys progressively stronger guarantees against tampering, and you climb only as far as an artifact’s importance justifies the cost.
5. A signature nobody checks is decoration. The control that stops a tampered artifact is the verification gate — the deploy step or admission controller must reject any image not signed by a trusted identity. The manual step removed across the whole chain is trusting upstream code and artifacts on faith, replaced by knowable contents, verifiable origin, and detectable tampering.