SBOM & provenance attestations

Prove what shipped and how it was built.

Signing proves who built an artifact; an SBOM and provenance prove what is in it and how it was made. A Software Bill of Materials is a machine-readable inventory of every component and version in your build; provenance (a signed statement, in the in-toto/SLSA format) records the build’s facts — the source commit, the builder, the steps. Together they turn an opaque image into something you can interrogate and trust, which is the whole point of supply-chain security.

sbom:
  stage: sign
  image: anchore/syft
  script:
    - syft "$IMAGE@$DIGEST" -o spdx-json > sbom.spdx.json
  artifacts:
    paths: [sbom.spdx.json]
    reports:
      cyclonedx: sbom.spdx.json    # GitLab surfaces the dependency list
# then attach it to the image as a signed attestation:
#   cosign attest --predicate sbom.spdx.json --type spdxjson "$IMAGE@$DIGEST"

An SBOM you can query is the zero-day answer

The concrete payoff of an SBOM is the next Log4Shell. When a critical CVE drops, "which of our images contain the vulnerable version?" becomes a query across your stored SBOMs instead of a frantic manual audit — minutes instead of days. Generate an SBOM per build, store it (attached to the image as an attestation, or in your artifact system), and you have a searchable inventory of everything you run.

Provenance and SLSA

Provenance is the artifact’s birth certificate: a signed attestation stating what source it was built from, by which pipeline, with what parameters — so a consumer can verify the image really came from your reviewed main branch and not a developer’s laptop. SLSA is the framework of levels that formalizes how tamper-resistant that build process is. This lesson is the CI-side introduction; the advanced supply-chain course goes deep on SLSA levels, attestation formats, and verifying them at admission.