sdlc.dev

CI/CD and DevOps path · Trust the artifact · Topic 6 of 13

Supply chain: SBOMs, provenance, SLSA and signing

Not started

Your artifact is assembled from hundreds of other people's packages, built by a CI system, and shipped through a registry. Each step is a place where something can be swapped. Supply-chain security answers three questions about an artifact: **what is in it** (an SBOM), **how and where it was built** (provenance), and **who vouches for it** (a signature). SLSA is a framework for how much you can trust those answers.

Why it matters: Attackers increasingly go after the build rather than the app: a poisoned dependency, a compromised CI job, a swapped package. SBOMs, provenance and signatures let consumers check what they are about to run.

  1. 1An SBOM lists the ingredients

    A software bill of materials records every component and version in an artifact, in a standard format such as SPDX or CycloneDX.

  2. 2Provenance says how it was made

    A signed statement of which source commit, which build platform and which workflow produced an artifact with a given digest.

  3. 3SLSA grades the build

    The SLSA Build track runs from L0 (no guarantees) to L3 (hardened build platform, provenance that is hard to forge).

  4. 4Keyless signing

    Sigstore signs with a short-lived certificate tied to an identity, such as a CI workflow, and records it in a public transparency log.

1

How it works

The explanation, with examples you can run.

SBOM: the list of ingredients

A software bill of materials lists every component in an artifact, with versions and usually licences and package URLs. The two common formats are SPDX and CycloneDX; tools such as Syft, Trivy or your build tool's plugin generate them. Store an SBOM next to every release. When the next big vulnerability lands, you search SBOMs instead of guessing which images use the affected library.

Provenance and SLSA

Provenance is a signed statement: "the artifact with digest sha256:abc… was built from commit 123… of my-org/my-app by this workflow on this platform". SLSA (Supply-chain Levels for Software Artifacts) defines levels for it. In the current spec (v1.2) the Build track has four:

  • L0: no guarantees.
  • L1: provenance exists. Good for catching mistakes, but easy to forge.
  • L2: provenance is signed and generated by a hosted build platform, so forging it takes a deliberate attack.
  • L3: a hardened platform that isolates builds from each other and keeps signing keys away from user-defined steps, so forging provenance needs an exploit most attackers don't have.

v1.2 also adds a Source track for how the source itself is protected (reviews, branch protection, history).

Signing with Sigstore

Traditional signing means guarding a private key for years. Sigstore's keyless approach replaces it with identity. The signer (a person, or a CI job through OIDC) gets a certificate valid for about ten minutes from Fulcio, signs, and the signature is recorded in Rekor, a public append-only transparency log. Verifiers check that the certificate names the identity they expect, for example "the release workflow of my-org/my-app on main", and that the entry is in the log. cosign is the usual client for container images.

In GitHub Actions

GitHub's artifact attestations generate SLSA provenance and sign it with Sigstore:

jobs:  build:    runs-on: ubuntu-latest    permissions:      contents: read      id-token: write          # to get a signing certificate      attestations: write      # to store the attestation      artifact-metadata: write    steps:      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1      - run: make dist         # produces dist/app.tgz      - uses: actions/attest@1e69f48acb82d1966a394da916b4c1698aa569d6 # v4.2.2        with:          subject-path: dist/app.tgz

Consumers then check it before deploying:

gh attestation verify dist/app.tgz --repo my-org/my-app

Passing sbom-path instead attests an SBOM. The real value comes from verifying at deploy time: an admission policy that rejects images without valid provenance from your build workflow turns all of this from paperwork into a gate.

2

Check yourself

3 questions. Get them all right to finish this topic.

  1. 1.A new critical vulnerability is announced in a logging library. Which artifact helps you answer "which of our images contain it?" fastest?
  2. 2.What does SLSA Build L1 give you?
  3. 3.In Sigstore's keyless flow, why does verification check the transparency log (Rekor)?

0 of 3 right so far. Get all three to finish this topic.

Go deeper