17.6 The SLSA Framework¶

After the SolarWinds attack demonstrated how vulnerable software supply chains could be, the industry needed a common language to discuss and measure supply chain security. Google open-sourced their internal build security framework, which became SLSA (Supply-chain Levels for Software Artifacts, pronounced "salsa"). SLSA provides a checklist of standards and controls to prevent tampering, improve integrity, and secure packages and infrastructure. More than a technical specification, SLSA serves as a communication tool—a way to set expectations between software producers and consumers about the security properties of artifacts.

This section provides a comprehensive guide to the SLSA framework, including its levels, requirements, implementation strategies, and practical adoption approaches.

Understanding SLSA¶

SLSA is a security framework that defines incrementally adoptable levels of supply chain security. Rather than requiring perfect security immediately, SLSA provides a maturity model where organizations can progressively improve.

Core SLSA Concepts:

What SLSA Addresses:

┌─────────────────────────────────────────────────────────────────┐
│                 SUPPLY CHAIN THREATS AND SLSA                    │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  Source Threats:                                                 │
│  • Unauthorized source changes    → Source track (future)       │
│  • Compromised source repository  → Source track (future)       │
│                                                                  │
│  Build Threats:                                                  │
│  • Compromised build process      → Build track (L1-L3)        │
│  • Modified build outputs         → Build track (L1-L3)        │
│  • Compromised dependencies       → Dependencies track (future) │
│                                                                  │
│  Distribution Threats:                                           │
│  • Tampering after build          → Build track + signing       │
│  • Registry compromise            → Build track + verification  │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

SLSA Version History:

• SLSA v0.1 (2021): Initial release with levels 1-4
• SLSA v1.0 (2023): Major revision, levels 0-3, track separation
• Current: v1.0 specification with Build track as primary focus

The SLSA framework emphasizes incremental progress over perfection, providing organizations with a roadmap for continuous improvement in supply chain security rather than demanding immediate perfect compliance.

SLSA Tracks¶

SLSA v1.0 separates requirements into tracks, each addressing different aspects of supply chain security.

Current Tracks:

Build Track (Primary Focus):

The Build track is the most mature and widely implemented. It addresses: - Build platform integrity - Provenance generation - Isolation between builds - Tamper resistance

Source Track (Draft):

The Source track will address: - Source repository integrity - Code review requirements - Two-person review - Verified source history

Dependencies Track (Future):

The Dependencies track will address: - Dependency verification - Transitive dependency tracking - Dependency provenance

SLSA Levels and Requirements¶

SLSA defines four levels (L0-L3), each building on the previous.

Level Summary Table:

Detailed Requirements:

Level 0: No Guarantees

No SLSA requirements met. This is the baseline—most software today.

L0: "I built this on my laptop"

Characteristics:
• No provenance
• No verification possible
• Full trust in producer

Level 1: Build Provenance Exists

Provenance automatically generated by the build process.

// L1 Provenance example
{
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {
      "buildType": "...",
      "externalParameters": {
        "source": {"uri": "git+https://github.com/org/repo", "digest": {"sha1": "..."}}
      }
    },
    "runDetails": {
      "builder": {"id": "https://example.com/builder"},
      "metadata": {"startedOn": "2024-01-15T10:00:00Z"}
    }
  }
}

Level 2: Hosted Build Platform

Provenance is signed and generated by a hosted build service.

L2 Properties:
┌─────────────────────────────────────────────────────────────────┐
│                                                                  │
│  ┌─────────────────┐        ┌─────────────────┐                │
│  │  Source Repo    │───────►│  Hosted Build   │                │
│  └─────────────────┘        │  Service        │                │
│                             │  (GitHub Actions,│                │
│                             │   Cloud Build)   │                │
│                             └────────┬────────┘                │
│                                      │                          │
│                                      ▼                          │
│                             ┌─────────────────┐                │
│                             │ Signed          │                │
│                             │ Provenance      │                │
│                             │ (verifiable)    │                │
│                             └─────────────────┘                │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

Level 3: Hardened Builds

Build platform provides strong isolation and tamper resistance.

L3 Properties:
• Hermetic builds (no arbitrary network access)
• Ephemeral runners (clean environment each build)
• Non-falsifiable provenance (generated by platform, not build)
• Isolated build jobs (no cross-job interference)

Requirements Matrix:

Practical Steps to Achieve Each Level¶

Achieving SLSA Level 1:

Level 1 requires that provenance exists. This is achievable with minimal changes.

Step-by-Step for L1:

1. Generate provenance during build

# GitHub Actions: Basic provenance generation
name: Build with Provenance

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build
        run: |
          make build
          # Generate basic provenance
          cat > provenance.json << EOF
          {
            "_type": "https://in-toto.io/Statement/v1",
            "subject": [{"name": "artifact.tar.gz", "digest": {"sha256": "$(sha256sum artifact.tar.gz | cut -d' ' -f1)"}}],
            "predicateType": "https://slsa.dev/provenance/v1",
            "predicate": {
              "buildDefinition": {
                "buildType": "https://example.com/basic-build",
                "externalParameters": {"source": "${{ github.repository }}@${{ github.sha }}"}
              },
              "runDetails": {
                "builder": {"id": "https://github.com/actions/runner"}
              }
            }
          }
          EOF

      - uses: actions/upload-artifact@v4
        with:
          name: release
          path: |
            artifact.tar.gz
            provenance.json

1. Document provenance location
2. Make provenance discoverable

Achieving SLSA Level 2:

Level 2 requires hosted builds with signed provenance. Use established tools.

Step-by-Step for L2:

1. Use SLSA GitHub generators

# GitHub Actions: L2 with slsa-github-generator
name: Release with SLSA L2

on:
  push:
    tags:
      - 'v*'

permissions:
  contents: write
  id-token: write

jobs:
  build:
    runs-on: ubuntu-latest
    outputs:
      digest: ${{ steps.build.outputs.digest }}
    steps:
      - uses: actions/checkout@v4
      - id: build
        run: |
          make release
          echo "digest=$(sha256sum dist/release.tar.gz | base64 -w0)" >> $GITHUB_OUTPUT
      - uses: actions/upload-artifact@v4
        with:
          name: release
          path: dist/release.tar.gz

  provenance:
    needs: build
    permissions:
      actions: read
      id-token: write
      contents: write
    uses: slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@v1.9.0
    with:
      base64-subjects: ${{ needs.build.outputs.digest }}
      upload-assets: true

1. Verify provenance is generated and signed

# Verify the provenance
slsa-verifier verify-artifact release.tar.gz \
    --provenance-path release.tar.gz.intoto.jsonl \
    --source-uri github.com/myorg/myrepo

1. Document builder identity in security documentation

Achieving SLSA Level 3:

Level 3 requires hardened build platforms. GitHub Actions, Google Cloud Build, and GitLab all offer L3-capable configurations.

Step-by-Step for L3:

1. Use L3-capable generators

# The slsa-github-generator already meets L3 requirements
# when used correctly
name: Release with SLSA L3

on:
  release:
    types: [created]

permissions:
  contents: write
  id-token: write
  actions: read

jobs:
  build:
    runs-on: ubuntu-latest
    outputs:
      artifacts: ${{ steps.build.outputs.artifacts }}
      digests: ${{ steps.hash.outputs.digests }}
    steps:
      - uses: actions/checkout@v4

      # Build in isolated, ephemeral environment
      - name: Build
        id: build
        run: |
          # Build commands - no network access to external resources
          make release
          echo "artifacts=dist/release.tar.gz" >> $GITHUB_OUTPUT

      - name: Generate hash
        id: hash
        run: |
          DIGEST=$(sha256sum dist/release.tar.gz | base64 -w0)
          echo "digests=$DIGEST" >> $GITHUB_OUTPUT

      - uses: actions/upload-artifact@v4
        with:
          name: release-artifacts
          path: dist/

  # Use L3 generator (isolated provenance generation)
  provenance:
    needs: build
    permissions:
      actions: read
      id-token: write
      contents: write
    uses: slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@v1.9.0
    with:
      base64-subjects: ${{ needs.build.outputs.digests }}
      upload-assets: true
      # Provenance generated in isolated environment
      # Cannot be influenced by build job

1. Ensure build isolation

# Container build with L3 provenance
jobs:
  build-container:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
      id-token: write
    steps:
      - uses: actions/checkout@v4

      - uses: docker/build-push-action@v5
        id: build
        with:
          push: true
          tags: ghcr.io/myorg/myapp:${{ github.sha }}
          provenance: true  # BuildKit generates L3 provenance
          sbom: true

1. Verify L3 requirements met

# Verify L3 provenance
slsa-verifier verify-image ghcr.io/myorg/myapp@sha256:... \
    --source-uri github.com/myorg/myapp \
    --print-provenance | jq '.predicate.runDetails.builder.id'
# Should show L3-capable builder

Ecosystem Support¶

SLSA adoption varies across package ecosystems.

Ecosystem Support Matrix:

npm SLSA Support:

# Publish with provenance
npm publish --provenance

# Verify package provenance
npm audit signatures

# Output:
# 247 packages have verified registry signatures
# 89 packages have verified attestations

PyPI SLSA Support:

# Using Trusted Publishers for PyPI
name: Publish to PyPI

on:
  release:
    types: [published]

jobs:
  publish:
    runs-on: ubuntu-latest
    environment: pypi
    permissions:
      id-token: write  # Required for Trusted Publishing
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
      - run: pip install build
      - run: python -m build
      - uses: pypa/gh-action-pypi-publish@release/v1
        # No password needed - uses OIDC

Container SLSA Support:

# Build with provenance using Docker BuildKit
docker buildx build \
    --provenance=true \
    --sbom=true \
    --push \
    -t ghcr.io/myorg/myapp:v1.0.0 .

# Verify
cosign verify-attestation \
    --type slsaprovenance \
    --certificate-identity-regexp 'https://github.com/myorg/*' \
    --certificate-oidc-issuer https://token.actions.githubusercontent.com \
    ghcr.io/myorg/myapp:v1.0.0

SLSA as a Communication Tool¶

SLSA provides shared vocabulary for procurement and vendor requirements.

Using SLSA in Procurement:

# Vendor Security Requirements

### Software Supply Chain

All software provided to [Organization] must meet the following SLSA requirements:

**Minimum Requirements (All Software):**
- SLSA Build Level 2 or higher
- Signed provenance available for verification
- Source repository disclosed

**Critical Software Requirements:**
- SLSA Build Level 3
- Reproducible builds preferred
- Independent verification capability

**Verification:**
- Vendor must provide provenance attestations
- Attestations must be verifiable using slsa-verifier or equivalent
- Verification results must be documented before deployment

Vendor Questionnaire:

Contract Language:

Vendor shall provide software artifacts that meet SLSA Build 
Level 2 requirements as defined by slsa.dev/spec/v1.0. 
Specifically:

(a) All artifacts shall include signed provenance attestations
    in SLSA provenance v1.0 format.

(b) Provenance shall be generated by an authenticated build 
    platform and signed using Sigstore or equivalent PKI.

(c) Buyer shall be able to verify provenance using publicly 
    available tools (slsa-verifier or equivalent).

(d) Vendor shall notify Buyer within 24 hours if provenance 
    generation is compromised or unavailable.

Limitations and Criticisms¶

SLSA addresses specific threats but has known limitations.

What SLSA Doesn't Cover:

SLSA Scope:
┌─────────────────────────────────────────────────────────────────┐
│                                                                  │
│  ✓ SLSA Addresses              ✗ SLSA Doesn't Address          │
│  ─────────────────             ───────────────────────          │
│  • Build integrity             • Code quality                   │
│  • Provenance generation       • Vulnerability presence         │
│  • Build platform security     • Malicious code in source      │
│  • Tamper detection            • Runtime security               │
│  • Artifact authenticity       • Operational security          │
│                                • Social engineering            │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

Common Criticisms:

1. "SLSA L3 doesn't prevent supply chain attacks"

Response: Correct. SLSA makes certain attacks harder and detectable, not impossible. A malicious maintainer can still insert backdoors at L3. SLSA's value is raising the bar and enabling verification—not perfect prevention.

2. "The levels are too complex"

Response: SLSA v1.0 simplified significantly from v0.1. Three meaningful levels (L1-L3) with clear requirements is more manageable than many compliance frameworks.

3. "No one verifies provenance"

Response: Adoption is growing. npm verification is built-in. Kubernetes admission controllers can enforce provenance. As tooling improves, verification becomes automatic.

4. "SLSA focuses too much on build"

Response: Valid criticism. The Source and Dependencies tracks are still developing. Build was prioritized because build compromise (SolarWinds) was the most impactful recent attack.

5. "Small projects can't achieve L3"

Response: Using GitHub Actions with SLSA generators, L3 is achievable by any project on GitHub. The tooling abstracts complexity. The challenge is awareness, not capability.

SLSA represents progress toward better security rather than perfect security—an approach that favors incremental improvement over unattainable ideals.

SLSA Verification Tooling¶

Several tools verify SLSA provenance.

slsa-verifier:

The official SLSA verification tool.

# Install
go install github.com/slsa-framework/slsa-verifier/v2/cli/slsa-verifier@latest

# Verify generic artifact
slsa-verifier verify-artifact artifact.tar.gz \
    --provenance-path artifact.tar.gz.intoto.jsonl \
    --source-uri github.com/myorg/myrepo \
    --builder-id https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml

# Verify npm package
slsa-verifier verify-npm-package @myorg/package \
    --package-version 1.0.0 \
    --source-uri github.com/myorg/package

# Verify container image
slsa-verifier verify-image ghcr.io/myorg/image@sha256:abc... \
    --source-uri github.com/myorg/repo

# Print provenance details
slsa-verifier verify-artifact artifact.tar.gz \
    --provenance-path provenance.jsonl \
    --source-uri github.com/myorg/repo \
    --print-provenance

Sigstore cosign:

For container image verification with SLSA provenance.

# Verify SLSA provenance attestation
cosign verify-attestation \
    --type slsaprovenance \
    --certificate-identity-regexp 'https://github.com/slsa-framework/slsa-github-generator/' \
    --certificate-oidc-issuer https://token.actions.githubusercontent.com \
    ghcr.io/myorg/myapp:v1.0.0

# Download and inspect provenance
cosign download attestation ghcr.io/myorg/myapp:v1.0.0 | jq '.payload' | base64 -d | jq '.'

Kubernetes Admission Control:

# Kyverno: Require SLSA L2+
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-slsa-provenance
spec:
  validationFailureAction: Enforce
  rules:
    - name: verify-slsa
      match:
        resources:
          kinds:
            - Pod
      verifyImages:
        - imageReferences:
            - "ghcr.io/myorg/*"
          attestations:
            - type: https://slsa.dev/provenance/v1
              conditions:
                - all:
                    - key: "{{ runDetails.builder.id }}"
                      operator: AnyIn
                      value:
                        - "https://github.com/slsa-framework/slsa-github-generator/*"
                        - "https://cloudbuild.googleapis.com/GoogleHostedWorker@*"

Adoption Roadmap¶

A practical path to SLSA adoption.

Phase 1: Assessment (Week 1-2)

## SLSA Readiness Assessment

### Current State
- [ ] Inventory build systems
- [ ] Identify artifact types (containers, packages, binaries)
- [ ] Document current provenance (if any)
- [ ] List target ecosystems (npm, PyPI, containers)

### Gap Analysis
- [ ] Which artifacts have no provenance? (Target L1)
- [ ] Which use hosted CI but no signing? (Target L2)
- [ ] Which are security-critical? (Target L3)

Phase 2: L1 Implementation (Week 3-4)

## L1 Implementation

### Actions
- [ ] Add provenance generation to all build pipelines
- [ ] Use SLSA provenance schema
- [ ] Store provenance alongside artifacts
- [ ] Document provenance location

### Validation
- [ ] Provenance exists for all artifacts
- [ ] Provenance follows SLSA format
- [ ] Provenance is discoverable

Phase 3: L2 Implementation (Week 5-8)

## L2 Implementation

### Actions
- [ ] Migrate to hosted CI (if not already)
- [ ] Implement SLSA generators or native provenance
- [ ] Enable provenance signing (Sigstore/OIDC)
- [ ] Publish provenance to transparency log

### Validation
- [ ] All provenance is signed
- [ ] Builder identity is verifiable
- [ ] slsa-verifier succeeds

Phase 4: L3 Implementation (Week 9-12)

## L3 Implementation

### Actions
- [ ] Use L3-capable generators/builders
- [ ] Ensure build isolation
- [ ] Verify ephemeral environments
- [ ] Confirm non-falsifiable provenance

### Validation
- [ ] Provenance generated by hardened platform
- [ ] Build isolation verified
- [ ] Independent verification succeeds

Phase 5: Operationalization (Ongoing)

## Operational Excellence

### Monitoring
- [ ] Alert on provenance generation failures
- [ ] Track SLSA level per artifact
- [ ] Monitor verification success rates

### Governance
- [ ] Define SLSA requirements per artifact type
- [ ] Include in vendor requirements
- [ ] Document exceptions and remediation plans

Recommendations¶

For Developers:

1. Start with L1 today. Generate provenance for every build. Even unsigned provenance is better than none. Use SLSA generators to automate.

2. Target L2 as baseline. With GitHub Actions or similar platforms, L2 is achievable with minimal configuration. Make it the default.

3. Verify your own artifacts. Run slsa-verifier on your releases. Catch provenance issues before users do.

For Security Practitioners:

1. Use SLSA in risk assessment. Classify software by SLSA level. Require higher levels for critical components.

2. Implement verification in deployment. Use admission controllers to require SLSA provenance. Make verification automatic.

3. Include SLSA in vendor requirements. Add SLSA level requirements to procurement. Use it as common language with suppliers.

For Organizations:

1. Set SLSA targets by artifact type. Internal tools might be L1. Production services should be L2+. Security-critical infrastructure should be L3.

2. Invest in tooling. Deploy verification tools. Train teams on provenance generation. Make SLSA part of the CI/CD platform.

3. Communicate SLSA levels. Publish your SLSA levels. Let consumers know what they can verify. Build trust through transparency.

SLSA transforms supply chain security from vague assurances to verifiable properties. It won't prevent all attacks, but it makes attacks harder, tampering detectable, and trust measurable. As adoption grows across ecosystems, SLSA provenance will become as fundamental as code signing—table stakes for professional software delivery.