BlogCI/CD

Attesting builds with SLSA provenance in CI

Generate an SBOM and signed SLSA provenance for every build, attach them with cosign, and prove exactly where an artifact came from when auditors ask.

Jun 3, 2025·4 min readAdvanced·By the SecOpsLog team · command-tested

After log4shell the question every team could not answer fast was simply: where do we run this library? An SBOM (software bill of materials) inventories every component in an artifact; SLSA provenance is a signed statement of how that artifact was built. Together they turn incident response from grepping Dockerfiles into querying a catalog — and they give admission controllers something verifiable to enforce before a pod schedules.

You will generate a CycloneDX SBOM with Syft, gate on CVEs with Grype, attach the SBOM and build provenance as Cosign attestations using CI OIDC (no long-lived signing key in settings), and verify attestations at deploy time. GitLab and GitHub both support the same toolchain — the full chain from builder trust to cluster policy is in Software supply chain security.

From build to verifiable artifact

Sign with the CI identity your cloud already trusts. Keyless Cosign binds the signature to the workflow that produced the image.

Generate the SBOM in CI

Run Syft against the built image tag — not only the Dockerfile — so OS packages, language deps, and binaries inside layers all appear. Store the SBOM as a pipeline artifact and attach it to the registry record. Scan the SBOM with Grype before push so a known-critical CVE blocks promotion instead of surfacing in production.

.gitlab-ci.yml

sbom:
  stage: test
  image: anchore/syft:latest
  script:
    - syft "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA" -o cyclonedx-json > sbom.json
    - grype sbom:sbom.json --fail-on high
  artifacts:
    paths: [sbom.json]

Attach signed provenance and SBOM

Cosign can sign the image digest and attach attestations — separate signatures that carry predicates like CycloneDX JSON or SLSA provenance v1. Keyless mode uses Fulcio to bind the signature to your CI OIDC identity; verify with policy that checks issuer, repository, and workflow ref.

bash

# after docker push — identity from CI OIDC
cosign sign --yes "$IMAGE"
 
cosign attest --yes \
  --predicate sbom.json \
  --type cyclonedx \
  "$IMAGE"
 
cosign attest --yes \
  --predicate provenance.json \
  --type slsaprovenance \
  "$IMAGE"

bash — verify at deploylive

cosign verify "$IMAGE"
Verified OK — issuer matches github.com/acme/repo
cosign verify-attestation --type cyclonedx "$IMAGE"
SBOM attestation verified
reject deploy if either check fails

Archive SBOMs for the next CVE

Keep one SBOM per immutable digest, not just per semver tag — tags can move. When the next critical CVE drops, search your SBOM archive for the affected package version across every image you have ever shipped — minutes instead of a week of repo archaeology. Retention policy should match compliance requirements; SBOMs are evidence, not debug noise. Store them beside the digest they describe so auditors can correlate signature, provenance, and inventory without chasing pipeline IDs.

Signature vs attestation

cosign sign

Proves who signed digest

Does not list contents

Blocks tampered images

Necessary not sufficient

cosign attest

Staples SBOM or provenance

Verifiable predicate type

Feeds admission policy

Answers what and how built

An unsigned SBOM in S3 is not enforcement

Generating sbom.json without signing and verifying at deploy is paperwork. Attackers who can push to your registry can push unsigned images too unless admission checks Cosign signatures and required attestation types. Treat verify as a deploy gate, not a compliance PDF.

Where this goes next

Attestations become powerful when Kyverno, Gatekeeper, or registry policy rejects images missing SLSA provenance or failing vulnerability thresholds on the attached SBOM. Wire Syft, Grype, and Cosign into one reusable workflow template so every repo inherits the same bar. Software supply chain security covers builders, signing, and admission verification hands-on.

Go deeper in a courseSoftware supply chain securitySBOMs, SLSA provenance, Cosign signing, and admission verification.View course

Trivy vs Grype: choosing a container image scannerJul 11, 2026 · field note Multi-stage Docker builds that cut image size by 80%Jun 24, 2026 · field note Scanning container images with Trivy in GitLab CIMay 26, 2026 · field note