Supply Chain Security Slsa

Production engineering guide for supply chain security slsa covering patterns, implementation strategies, and operational best practices.

Orientation

SLSA (Supply Chain Levels for Software Artifacts) is a publicly documented framework that codifies software supply chain integrity into five levels, from zero (no protections) to five (fully audited, immutable build). It matters when your organization needs to prove that delivered artifacts were built from verified source, with immutable dependencies and attested provenance—particularly in regulated industries such as finance, healthcare, or any system where a compromised build chain represents a critical risk. The framework centers on three core artifacts: a build-provenance document (an OCI‑compatible JSON blob describing who built what, from which source, and with which tools), a Software Bill of Materials (SBOM) listing every dependency, and a verified execution trace. The following sections show how to generate, store, and verify those artifacts, organized by the typical actions a reader needs to take.

Generating SLSA Provenance for a Build

The most common entry point is attaching provenance to a container image or artifact after a CI run. The industry‑standard tool for this is cosign, a shipping, open‑source utility from Sigstore that handles signing, provenance, and verification against a public key infrastructure.

To generate provenance alongside an image push, the typical pipeline step looks like this:


cosign sign --provenance \
  --key sigstore \
  myregistry/myimage:tag

The --provenance flag tells cosign to produce a provenance document and store it as an OCI artifact alongside the image in the registry. If you need to control the provenance format or embed a custom SBOM, first generate the SBOM with syft and then feed it into the signing step:

# Produce an SBOM for the built image
syft docker:myregistry/myimage:tag -o json > sbom.json

# Sign the image, explicitly referencing the SBOM
cosign sign --provenance --sbom sbom.json \
  --key sigstore \
  myregistry/myimage:tag

Provenance documents conform to the in‑toto spec and contain fields such as builder, invocation, materials (source references), and digest. They are stored in the same registry layer as the image, tagged with the provenance.media.type annotation (application/vnd.in-toto.provenance.json+json). This means any consumer that pulls the image can also pull the accompanying provenance blob without additional configuration.

Verifying Provenance Before Deployment

Before promoting an image to production, a deployment pipeline should reject any artifact that lacks valid SLSA provenance—or whose provenance cannot be traced to an accepted build identity. Verification is the inverse of signing:

# Verify that the image has attested SLSA provenance
cosign verify --provenance myregistry/myimage:tag

If the image was signed with a cosign key held in a private keyring, the command succeeds only when the provenance verifies against that key’s public counterpart. In a typical organizational workflow, the pipeline maintains a trusted public key file (e.g., cosign.keys) containing the fingerprints of approved build identities:

# Verify against a set of approved keys
cosign verify --provenance --key cosign.keys myregistry/myimage:tag

A non‑zero exit code indicates verification failure—either the provenance is missing, the signature is invalid, or the key is not in the trusted set. Pipelines can set -e on this command to halt deployment automatically.

For environments that use external identity providers (e.g., GitHub Actions OIDC tokens, HashiCorp Vault, or cloud IAM), the provenance attestation binds the build identity to the artifact. The verification step does not need to know *how* the key was generated; it only needs the public key material in a format cosign accepts (--key flag, KMS URI, or OIDC audience). This separation of “who signed” from “how the key was provisioned” is the pattern that makes SLSA portable across CI systems.

Enforcing SLSA Levels in CI/CD

Enforcing a minimum SLSA level is a matter of pipeline guardrails rather than a single flag. The general pattern is:

  1. Produce provenance at the end of the build step (using the cosign sign --provenance pattern shown above).
  2. Verify provenance in the subsequent promotion step, exiting with failure if the attested level is below the required threshold.
  3. Reject untagged or unsigned images at the registry level, if your registry supports policy rules (many do via OCI annotations or webhook‑driven admission).

A concrete CI snippet (shell‑agnostic in intent) might look like:

# Promotion gate: require at least SLSA Level‑2 attestation
cosign verify --provenance --level 2 myregistry/myimage:tag

The --level flag is not a universal cosign option; level enforcement is typically expressed by checking provenance fields within the pipeline script. A portable check extracts the builder and materials sections and validates them against organizational policies (e.g., “source must be a protected branch”, “build image must be from an approved registry”). Because provenance is just JSON, any language’s JSON parser can extract and evaluate these fields:

import json, sys
prov = json.load(open("provenance.json"))
# Example policy: reject if builder identity is not a known service account
if prov["builder"]["identity"] not in ALLOWED_IDENTITIES:
    sys.exit("Provenance builder identity not approved")

The key takeaway: provenance is data you can script against. Enforcement logic lives in your pipeline, not in the tool itself.

Sharp Edges – What Silently Fails or Surprises

Going Further

SLSA levels above 1 add requirements such as reproducible builds (Level 2), fully immutable build environments (Level 3), and cryptographic verification of every dependency hash (Level 4‑5). The mechanics scale the same way: generate more detailed provenance, sign with stronger attestation, and verify against stricter policy checks. The pattern never changes—provenance generation, storage, and verification—but the granularity of the fields you inspect and the strictness of the pipeline guards increase with each level.

If your organization is just starting down the supply‑chain hardening path, begin at Level 1: ensure every produced image has attested provenance and that your deployment pipeline refuses anything without it. From there, layer SBOM generation, key‑rotation policies, and provenance‑level checks to climb the ladder. The tools are the same; only the policy thresholds shift.

This page was rewritten on 17 October 2026. It replaced a templated version that was not specific to its own title. How these pages are written and checked. If anything here is wrong, tell us at [email protected] and we will correct it.