The Supply Chain Verification Problem SLSA Addresses

A container image arrives in your registry. You run it in production. But can you actually prove it came from the right source code, built by authorized infrastructure, with no tampering? Most organizations cannot. SLSA (pronounced "salsa") is a framework that answers: "How do I know this artifact is genuinely what it claims to be, built securely, from the right code?" SLSA provides a graded progression (Levels 0-4) from "no supply chain controls" to "cryptographically verified, auditable build provenance." Created by Google and now adopted by major cloud providers and Linux distributions, SLSA gives you a standard way to establish trust in your software artifacts.

SLSA is a framework that defines how to make software artifacts trustworthy by verifying their provenance, build process, and integrity. It progresses through levels, from basic documentation to cryptographically verified supply chain security.

SLSA Levels: A Progression of Trust

The following diagram illustrates the progression through SLSA levels, showing what capabilities and controls increase at each level:

graph LR    L0["Level 0<br/>Uncontrolled<br/>Build<br/>~<br/>No Controls"]:::level0    L1["Level 1<br/>Documentation<br/>Source Control<br/>~<br/>Basic Traceability"]:::level1    L2["Level 2<br/>Controlled Build<br/>Platform<br/>Provenance<br/>~<br/>Cryptographic Proof"]:::level2    L3["Level 3<br/>Hardened<br/>Build Isolation<br/>Access Controls<br/>~<br/>Audit Trail"]:::level3    L4["Level 4<br/>Hermetic<br/>Reproducible<br/>Verifiable<br/>~<br/>Perfect Integrity"]:::level4     L0 -->|"Add"| L1    L1 -->|"Add"| L2    L2 -->|"Add"| L3    L3 -->|"Add"| L4     Caps0["No provenance<br/>No verification<br/>No audit"]    Caps1["Know source<br/>Know version<br/>Basic trace"]    Caps2["Signed provenance<br/>Cryptographic proof<br/>Specific builder"]    Caps3["Isolated env<br/>Audit logs<br/>Pinned deps"]    Caps4["Bit-for-bit<br/>reproducible<br/>Self-verifiable"]     L0 -.-> Caps0    L1 -.-> Caps1    L2 -.-> Caps2    L3 -.-> Caps3    L4 -.-> Caps4     style L0 fill:#FF6347,stroke:#8B0000,stroke-width:2px    style L1 fill:#FFD700,stroke:#8B4513,stroke-width:2px    style L2 fill:#90EE90,stroke:#228B22,stroke-width:2px    style L3 fill:#87CEEB,stroke:#00008B,stroke-width:2px    style L4 fill:#DDA0DD,stroke:#8B008B,stroke-width:2px

Level 0: Uncontrolled Process

What you have: Nothing formal about your build process.

At Level 0, builds run on developers' personal laptops with no documentation of how artifacts were created. Artifact sources are unknown or poorly tracked, making it impossible to reconstruct where a given artifact came from. Anyone can modify artifacts after creation, and no verification mechanism exists to detect such tampering. The fundamental risk at Level 0 is that you have no way to prove where your software comes from or verify that it has not been tampered with.

Level 1: Documentation and Source Control

What you have: Basic build information and source control.

At Level 1, source code is maintained in a version control system such as Git, the build process is formally documented so anyone can understand how artifacts are created, builds are recorded as happening from specific, recorded commits so there is traceability, and artifacts are tracked with version information so they can be related back to source commits.

Verification: You can prove "this artifact came from this commit"

How to achieve it:

# Document your buildecho "Build: from commit abc123" > build_metadata.txtgit log --oneline | head -1  # Record exact source commit

Real-world example: You publish a GitHub Release tied to a Git tag

Level 2: Build Platform and Provenance

What you have: Builds run on a controlled platform that produces a provenance statement (attestation).

At Level 2, builds run on a restricted, isolated platform (not on developers' machines), ensuring the build environment is not compromised by developer activities. The build environment is ephemeral, created fresh for each build and destroyed afterward, preventing persistent state that could affect subsequent builds. The build platform produces a provenance statement in in-toto format, a standardized format for documenting what happened during a build. Both the provenance and the artifact are cryptographically signed, providing proof of their authenticity.

Verification: You can cryptographically verify where the build happened, what code was built, when the build occurred, and who triggered the build.

How to achieve it:

# Cloud Build automatically generates provenancegcloud builds submit --source . # Output: signed provenance statement# Example from Google Cloud Build:{  "builderVersion": "cloud-builds/v1",  "buildOptions": {...},  "sourceProvenance": {    "resolvedRepoSource": {      "commitSha": "abc123..."    }  },  "buildSteps": [...]}

Real-world examples: GitHub Actions, GitLab CI, Google Cloud Build, Cloud Native Build Service

Level 3: Hardened Build Environment

What you have: Level 2 plus hardened build platform with stronger access controls and isolation.

Additional requirements include the build platform only allowing artifacts to be signed with a single, rotated signing key. The build platform maintains an audit log of all builds. The build platform runs in an isolated network with no external connections during build. Build scripts are version controlled and reviewed. All dependencies are pinned (no floating "latest" versions).

Verification: You can prove the build environment is officially controlled, builds are auditable, and the supply chain is protected from tampering.

How to achieve it:

# Use a hermetic build system with isolationbazel build --noenable_bzlmod  # Hermetic Bazel build# All inputs are explicit and pinned # Pin all dependenciesgo.sum  # Go automatically locks dependency versions

Level 4: Hermetic, Reproducible, Verifiable Build System

What you have: Level 3 plus hermetic builds that are reproducible and bit-for-bit identical.

Additional requirements include builds that are fully hermetic (no external network access, all inputs explicit), reproducible (bit-for-bit identical output with same inputs), and verifiable (anyone can rebuild and check output matches). The build platform is open-source and community-reviewed. All build dependencies are pinned to specific versions.

Verification: You can rebuild the artifact yourself and verify it matches, detect if the artifact was modified or tampered with, and prove artifact integrity independent of the build platform.

How to achieve it:

# Hermetic build systembazel build //path:target # Reproducible: same source + same Bazel version = identical outputbazel cleanbazel build //path:target# Output hash matches previous build # Verifiable: anyone can reproducegit clone <repo>bazel build //path:target# Output matches published artifact hash

SLSA Components: Build Integrity

SLSA focuses on build integrity through three key components. Source integrity means source code comes from a controlled repository, commits are verified (signed), code review process is enforced, and access to repository is controlled.

Build process integrity means builds happen in an isolated, controlled environment, build inputs are explicitly declared (no implicit dependencies), build outputs are signed, and the build process is auditable.

Artifact integrity means artifacts are cryptographically signed, artifact signatures are verifiable, artifact provenance is available, and artifact modifications are detectable.

Why SLSA Matters for Containers

SLSA is especially important for container security for several reasons. Container images are complex artifacts including OS packages, runtime libraries, and application code—each with their own supply chain. Implicit trust is dangerous since teams often pull images without verifying origin. Compromises have massive impact; a backdoored container affects every deployment. Compliance requirements mean regulations require proof of artifact authenticity.

SLSA for Container Images: When a container image is published to a registry, it includes a provenance attestation containing the source (the repository and commit), the builder used (such as cloud.google.com/cloud-build at a specific SLSA level), the build timestamp, the image digest, and a cryptographic signature signed with the build key. Any user can download this provenance, verify the signature, and confirm the image is legitimate.

In-Toto: The Foundation of SLSA Provenance

SLSA's provenance format is based on in-toto, an open-source framework for supply chain security. An in-toto provenance statement includes:

{  "_type": "https://in-toto.io/Statement/v0.1",  "subject": [    {      "name": "myapp",      "digest": {        "sha256": "deadbeef..."      }    }  ],  "predicateType": "https://slsa.dev/provenance/v1",  "predicate": {    "buildDefinition": {      "buildType": "https://cloud.google.com/cloud-build",      "externalParameters": {        "source": "github.com/myorg/myapp@abc123",        "entrypoint": "Dockerfile"      },      "internalParameters": {...}    },    "runDetails": {      "builder": {        "id": "https://cloud.google.com/projects/myproject/builds"      },      "metadata": {        "invocationId": "build-12345",        "startedOn": "2024-03-15T10:00:00Z",        "finishedOn": "2024-03-15T10:15:00Z"      }    }  }}

This statement proves what was built (subject), where it came from (source), how it was built (build type), and by whom and when (builder + timestamps).

Implementing SLSA for Your Project

Minimum Viable SLSA (Level 2)

For most organizations, starting with Level 2 is practical:

# GitHub Actions example (achieves SLSA Level 3)name: Build and Publishon: [push] jobs:  build:    runs-on: ubuntu-latest    permissions:      contents: read      id-token: write  # Required for Sigstore keyless signing     steps:      - uses: actions/checkout@v3        with:          fetch-depth: 0       - name: Build container image        run: docker build -t myapp:latest .       - name: Generate provenance (Dockerfile-based)        uses: actions/attest-build-provenance@v1        with:          subject-name: myapp          subject-digest: ${{ steps.build.outputs.digest }}       - name: Publish to registry        run: docker push myapp:latest

This automatically records the source commit, captures the build environment, signs provenance with GitHub's key, and stores provenance in artifact registry.

Path to Level 4

For maximum security, use a hermetic build system (Bazel, Nix), pin all dependencies explicitly, make builds reproducible (no timestamps, no randomness), publish provenance alongside artifacts, and verify provenance before deployment.

CleanStart and SLSA

CleanStart Source Intelligence Core captures SLSA provenance from all build systems, verifies provenance signatures using Sigstore, analyzes build integrity based on SLSA level, enforces SLSA requirements through policy controls, maintains provenance history for audit and compliance, and correlates provenance with SBOMs for complete supply chain visibility.

SLSA Best Practices

Start with Level 2, achievable with Cloud Build, GitHub Actions, or GitLab CI. Automate provenance generation—do not manually create provenance statements. Publish provenance alongside artifacts. Use admission controllers to verify SLSA provenance before deploying. Use Sigstore to leverage keyless signing for provenance (Cosign/Fulcio). Track SLSA level achievement over time. Enforce image signing as a deployment policy.

Related Concepts

Understand build provenance as cryptographic evidence of build process. Study in-toto as the framework for provenance statements. Learn about container signing with Cosign and Sigstore for image signatures. Explore supply chain security as the broader domain for SLSA verification. Review SBOM as often included in SLSA provenance for complete component tracking.

Further Reading

Visit the SLSA Framework Official Documentation for complete framework specification. Explore the In-Toto Project for the provenance framework. Read Google Cloud Build Provenance for implementation guide. Study GitHub Actions Attestation for GitHub's SLSA implementation.