Verifying Build Provenance with SLSA and Sigstore

Overview

Build-provenance verification answers a question that defeats many supply-chain attacks: was this artifact actually built from the source I think it was, by the builder I trust, without tampering? Attackers who compromise a build system, swap a compiled release, or inject a malicious step (as in the SolarWinds and 3CX incidents) produce artifacts that look legitimate but lack verifiable provenance. SLSA (Supply-chain Levels for Software Artifacts, https://slsa.dev) defines Build levels (L1–L3) describing increasing provenance integrity, and Sigstore (https://www.sigstore.dev) provides the signing and transparency infrastructure: cosign for signing/verifying artifacts and attestations, Fulcio for short-lived keyless certificates bound to an OIDC identity, and Rekor as a tamper-evident transparency log.

This skill covers verifying signatures and SLSA provenance with cosign (cosign verify, cosign verify-attestation, cosign verify-blob-attestation) and slsa-verifier (slsa-verifier verify-artifact), enforcing the builder identity (the GitHub Actions workflow that produced the artifact) and the expected source repository. Keyless verification ties trust to an OIDC issuer (e.g., https://token.actions.githubusercontent.com) and a certificate identity rather than a long-lived private key.

This maps to MITRE ATT&CK T1195 — Supply Chain Compromise (provenance verification detects/blocks tampered artifacts) and NIST CSF PR.DS-01 (the confidentiality, integrity, and availability of data-at-rest are protected; CSF 2.0 absorbed the retired 1.1 PR.DS-06 integrity-checking outcome here).

When to Use

• In CI/CD before deploying or promoting any container image or release binary.
• When consuming third-party artifacts (base images, Go/npm releases) that publish attestations.
• When establishing a SLSA Build L3 producer pipeline and enforcing it at the consumer side.
• During incident response to confirm whether a deployed artifact's provenance is intact.
• In admission control (e.g., Kubernetes via policy-controller / Kyverno) to admit only verified images.

Prerequisites

• cosign (Sigstore CLI):

  go install github.com/sigstore/cosign/v2/cmd/cosign@latest
  # or download a release binary from https://github.com/sigstore/cosign/releases
  

• slsa-verifier:

  go install github.com/slsa-framework/slsa-verifier/v2/cli/slsa-verifier@latest
  # or:
  curl -sSL https://github.com/slsa-framework/slsa-verifier/releases/latest/download/slsa-verifier-linux-amd64 \
    -o /usr/local/bin/slsa-verifier && chmod +x /usr/local/bin/slsa-verifier
  

• Network access to Rekor (https://rekor.sigstore.dev) and Fulcio for transparency-log verification.
• The artifact plus its provenance/attestation bundle (.sigstore, .intoto.jsonl, or attached OCI attestation).

Objectives

• Verify a keyless cosign signature on a container image, pinning OIDC issuer and certificate identity.
• Verify a SLSA provenance attestation on an image with cosign verify-attestation --type slsaprovenance.
• Verify a release binary's provenance with slsa-verifier verify-artifact, pinning source repo and tag.
• Verify GitHub artifact attestations / blob bundles with cosign verify-blob-attestation.
• Gate CI and admission control on successful verification; understand SLSA Build L1–L3.

MITRE ATT&CK Mapping

Workflow

Step 1: Verify a keyless cosign signature on an image

Pin both the OIDC issuer and the certificate identity (the exact workflow that signed). A bare cosign verify without identity pinning is meaningless — anyone can sign.

cosign verify \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  --certificate-identity-regexp "^https://github.com/myorg/myrepo/.github/workflows/.*@refs/tags/v.*" \
  ghcr.io/myorg/myrepo:v1.2.3

A non-zero exit or empty result means verification failed — do not deploy.

Step 2: Verify the SLSA provenance attestation on the image

…