SLSA provenance — attesting the build process

SLSA (Supply-chain Levels for Software Artifacts) is a framework for supply chain security with four levels. SLSA Level 3 (the highest practical level) requires a hermetic, reproducible build with signed provenance that attests to the build process. This lesson covers the SLSA levels, the provenance attestation, the integration with build systems, and the verification at admission.

The SLSA levels

SLSA defines four levels (Build L0 through L3):

L3 is the production target for high-trust workloads. L2 is the minimum for production. L0 and L1 are acceptable for development but not production.

flowchart LR
    L0[L0: No provenance] --> L1[L1: Unsigned provenance]
    L1 --> L2[L2: Signed provenance]
    L2 --> L3[L3: Hermetic, signed]

The provenance attestation

SLSA provenance is a structured document that describes how the artifact was built:

{
  "_type": "https://in-toto.io/Statement/v0.1",
  "predicateType": "https://slsa.dev/provenance/v0.2",
  "subject": [
    {
      "name": "myapp",
      "digest": {"sha256": "abc..."}
    }
  ],
  "predicate": {
    "builder": {"id": "https://tekton.example.com"},
    "buildType": "https://tekton.example.com/buildTypes/myapp",
    "invocation": {
      "configSource": {
        "uri": "git+https://github.com/myorg/myapp",
        "digest": {"sha1": "..."},
        "entryPoint": "ci/build.sh"
      }
    },
    "materials": [
      {
        "uri": "git+https://github.com/myorg/myapp",
        "digest": {"sha1": "..."}
      },
      {
        "uri": "https://registry.example.com/base",
        "digest": {"sha256": "..."}
      }
    ]
  }
}

The attestation includes:

• Subject — the artifact (image) and its digest.
• Builder — who built it (the CI system).
• Build type — the build process (Tekton pipeline, GitHub Actions workflow).
• Invocation — how the build was triggered (the Git commit, the entry point).
• Materials — the inputs (source code, base images).

flowchart LR
    A[Build] --> B[Provenance]
    B --> C[Sign with Cosign]
    C --> D[Attach to image]
    E[Verifier] --> F[Fetch provenance]
    F --> G[Verify signature]
    G --> H[Validate build integrity]

Generating provenance

The build system generates the provenance:

# Tekton Chains (Kubernetes-native CI)
# Automatically generates SLSA provenance for Tekton builds
kubectl apply -f tekton-chains.yaml

# BuildKit (Docker build)
BUILDKIT_PROVENANCE=true docker buildx build \
  --output type=image,name=myapp:v1.0,push=true .

# GitHub Actions with slsa-github-generator
# (third-party action; generates provenance)

The provenance is written to the registry as an OCI artifact.

Signing and verifying

The provenance is signed with Cosign or Notation:

# Sign with Cosign
cosign sign-blob --key cosign.key provenance.json > provenance.sig
cosign attach attestation --attestation provenance.json \
  --signature provenance.sig myapp:v1.0

# Verify with slsa-verifier
slsa-verifier verify-image myapp:v1.0 \
  --provenance-path provenance.json \
  --source-uri git+https://github.com/myorg/myapp

The verifier checks:

• The provenance is signed by a trusted signer.
• The source URI matches the expected repository.
• The build inputs match the expected digests.

Production patterns

1. SLSA L3 for production workloads. High-trust workloads have hermetic builds with signed provenance.
2. SLSA L2 for development workloads. Development builds have signed provenance but may not be hermetic.
3. Verify at admission. Kyverno or Ratify verifies the provenance before the workload runs.
4. Audit provenance quarterly. The provenance should reflect the actual build process; drift is a finding.

Production failure modes

1. No provenance. The image is built without provenance generation. The fix is to enable provenance in the build system.
2. Provenance is unsigned. The provenance can be tampered with. The fix is to sign with Cosign or Notation.
3. Provenance is outdated. The image was updated but the provenance is stale. The fix is to regenerate provenance on every build.
4. No verification. Pods without verified provenance are admitted. The fix is to enforce verification at admission.

Cross-course references

• The Linux course covers reproducible builds and hermetic environments.
• The Observability course covers the audit log entries for SLSA verification.

Quiz

Production discipline

SLSA is the right framework for supply chain attestation. A defensible SLSA programme targets L3 for high-trust workloads (hermetic, signed provenance) and L2 for development workloads (signed provenance, non-hermetic acceptable). The provenance is generated by the build system, signed with Cosign or Notation, and verified at admission with Kyverno or Ratify. A cluster whose images all have SLSA L3 provenance has a supply chain that is auditable; a cluster whose images have no provenance has a supply chain that is not.