Terabyte Systems

SLSA Framework: Supply Chain Security Beyond SBOMs

By Marcus Johnson • • 13 min read
security supply-chain slsa devops ci-cd sbom

Supply chain attacks have become the nightmare scenario for security teams. I’ve investigated breaches where attackers compromised build systems, injected malicious code into trusted packages, and executed attacks affecting millions of users. The 2020 SolarWinds attack, the 2021 Codecov breach, and countless npm package compromises prove that traditional security controls aren’t enough.

SLSA (Supply chain Levels for Software Artifacts, pronounced “salsa”) is a security framework that actually addresses these threats. It’s not just theory—Google developed SLSA internally and has used it to secure their software supply chain for years. Now it’s open and standardized, providing a clear path to verifiable supply chain security.

Why Supply Chain Attacks Succeed

Traditional security focuses on the wrong things. We scan for vulnerabilities in dependencies, we require MFA for developers, we use branch protection rules—all necessary, but none of these prevent the most dangerous attacks:

Build system compromise: An attacker gains access to your CI/CD system and injects malicious code during the build. Your source code is clean, but the binary is compromised. How do you detect this?

Dependency confusion: An attacker publishes a malicious package with the same name as your internal package. The build system pulls the wrong one. Your build succeeds, but you’re shipping malware.

Account takeover: A developer’s credentials are compromised. The attacker pushes malicious commits or releases. Even with code review, subtle backdoors can slip through.

Compromised dependencies: A popular dependency is compromised (directly or through its dependencies). You’re pulling in and shipping malicious code without knowing it.

I’ve seen all of these attacks in production environments. Traditional defenses fail because they can’t verify the integrity of the build process itself. SLSA fixes this.

SLSA Core Concepts

SLSA’s approach is simple but powerful: verify the entire path from source to deployment. Not just the code, not just the dependencies—the entire build process.

Build Provenance

Provenance is a signed attestation documenting how an artifact was built:

  • What source code was used (commit SHA, repository URL)
  • What build system built it (GitHub Actions, Jenkins, etc.)
  • What build steps were executed
  • What dependencies were used
  • When it was built
  • Who triggered the build

Crucially, provenance is signed by the build system, not by a developer. This means an attacker who compromises a developer account can’t forge provenance—they’d need to compromise the build system’s signing keys.

Here’s what provenance looks like (simplified):

{
  "_type": "https://in-toto.io/Statement/v0.1",
  "subject": [{
    "name": "myapp",
    "digest": {
      "sha256": "a3b8f9..."
    }
  }],
  "predicateType": "https://slsa.dev/provenance/v0.2",
  "predicate": {
    "builder": {
      "id": "https://github.com/Attestations/GitHubHostedActions@v1"
    },
    "buildType": "https://github.com/Attestations/GitHubActionsWorkflow@v1",
    "invocation": {
      "configSource": {
        "uri": "git+https://github.com/org/repo@refs/heads/main",
        "digest": {
          "sha1": "d6e2b4..."
        },
        "entryPoint": ".github/workflows/release.yml"
      }
    },
    "metadata": {
      "buildInvocationId": "1234567890",
      "buildStartedOn": "2025-12-03T17:00:00Z",
      "completeness": {
        "parameters": true,
        "environment": false,
        "materials": true
      }
    },
    "materials": [
      {
        "uri": "git+https://github.com/org/repo",
        "digest": {
          "sha1": "d6e2b4..."
        }
      },
      {
        "uri": "pkg:npm/[email protected]",
        "digest": {
          "sha256": "c7d8e9..."
        }
      }
    ]
  }
}

This provenance proves:

  • Exact source: Commit d6e2b4… from github.com/org/repo
  • Build system: GitHub Actions
  • Dependencies: [email protected] with specific hash
  • Build time: December 3, 2025
  • Build ID: 1234567890 (for audit trail)

With provenance, you can verify that the binary you’re deploying matches what was built from trusted source in a trusted build system. Without provenance, you’re trusting blindly.

SLSA Levels: Progressive Security

SLSA defines four levels of supply chain security. Each level builds on the previous, with increasing protection:

SLSA Level 0 (Baseline)

No guarantees. This is where most software currently sits:

  • Source code might be in git, might not be
  • Builds happen… somewhere
  • No documentation of the build process
  • No verification possible

Threat model: You’re vulnerable to everything—compromised dependencies, build system attacks, developer account takeover, etc.

SLSA Level 1: Provenance

Requirements:

  • Build process generates and signs provenance
  • Provenance includes source location and build parameters
  • Provenance is available to consumers

This enables build verification. You can check that an artifact was built from expected sources using an expected build process.

Implementation (GitHub Actions):

name: Release with SLSA
on:
  push:
    tags:
      - 'v*'

permissions:
  contents: write
  id-token: write

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Build application
        run: |
          make build
          
      - name: Generate provenance
        uses: slsa-framework/slsa-github-generator/actions/generic/[email protected]
        with:
          artifact-path: ./build/myapp
          
      - name: Upload artifacts
        uses: actions/upload-artifact@v3
        with:
          name: build-artifacts
          path: |
            ./build/myapp
            ./build/myapp.intoto.jsonl

Now every release includes signed provenance. Consumers can verify:

# Verify provenance
slsa-verifier verify-artifact ./myapp \
  --provenance-path ./myapp.intoto.jsonl \
  --source-uri github.com/org/repo \
  --source-tag v1.0.0

If provenance doesn’t match or signature is invalid, verification fails. This catches:

  • Binaries built from unexpected source
  • Binaries built outside the CI/CD system
  • Tampered artifacts

Threats mitigated: Prevents deployment of artifacts built outside the official pipeline.

Remaining threats: Compromised build system can still inject malicious code.

SLSA Level 2: Hosted Build Platform

Requirements:

  • Level 1 provenance
  • Build must run on a hosted, hardened platform (GitHub Actions, Google Cloud Build, etc.)
  • Build process is defined in version-controlled config
  • Service-generated provenance (not developer-generated)

This prevents developers from forging provenance. Even if a developer’s account is compromised, they can’t create valid provenance for malicious binaries.

Implementation considerations:

Use hosted build platforms with provenance support:

  • GitHub Actions: Built-in provenance generation
  • Google Cloud Build: Generates SLSA provenance natively
  • GitLab CI: SLSA attestation support
  • CircleCI: Attestation support via plugins

Never allow developers to:

  • Run builds locally and upload artifacts
  • Modify provenance after generation
  • Access build system signing keys

I’ve deployed this in production environments. The key insight: trust the build system, not individual developers. Even with a compromised developer account, attackers can’t forge valid provenance because they don’t have the build system’s signing keys.

Threats mitigated: Developer account compromise, credential leakage, insider threats (to some extent).

Remaining threats: Build system compromise, malicious pull request approval, dependency confusion.

SLSA Level 3: Hardened Builds

Requirements:

  • Level 2 requirements
  • Build is isolated from external influence
  • Dependencies are pinned and verified
  • All build steps are auditable
  • Provenance includes complete dependency graph

This is where it gets serious. Level 3 requires:

Isolated builds: Build runs in an ephemeral, isolated environment that’s destroyed after the build. No persistent state, no side channels for exfiltrating secrets or injecting malicious code.

Dependency pinning: All dependencies specified by exact hash, not version number. npm install [email protected] is not enough—you need [email protected] with SHA256 hash c7d8e9… This prevents dependency confusion and dependency substitution attacks.

Two-person review: Changes to build configuration or release process require approval from multiple authorized people. One compromised account isn’t enough to compromise the supply chain.

Example implementation (GitHub Actions with SLSA Level 3):

name: SLSA 3 Release
on:
  push:
    tags:
      - 'v*'

permissions:
  contents: read
  id-token: write

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      # Verify two-person approval
      - name: Check approvals
        run: |
          # Ensure this tag push was approved by 2+ maintainers
          # (Implement with GitHub API or branch protection rules)
          
      - name: Verify dependency hashes
        run: |
          # Ensure package-lock.json has integrity hashes
          npm ci --frozen-lockfile
          
      - name: Build in isolated environment
        run: |
          # Build with no network access after dependency install
          docker run --rm --network=none \
            -v $(pwd):/workspace \
            -w /workspace \
            node:18 \
            npm run build
            
      - name: Generate SLSA 3 provenance
        uses: slsa-framework/slsa-github-generator/.github/workflows/[email protected]
        with:
          base64-subjects: "${{ needs.build.outputs.hashes }}"
          
      - name: Verify provenance before upload
        run: |
          slsa-verifier verify-artifact ./build/myapp \
            --provenance-path ./myapp.intoto.jsonl \
            --source-uri github.com/org/repo \
            --source-tag ${{ github.ref_name }}

Additionally, implement:

Dependency verification:

// package-lock.json with integrity hashes
{
  "dependencies": {
    "express": {
      "version": "4.18.2",
      "resolved": "https://registry.npmjs.org/express/-/express-4.18.2.tgz",
      "integrity": "sha512-5/PsL6iGPdfQ/lKM1UuielYgv3BUoJfz1aUwU9vHZ+J7gyvwdQXFEBIEIaxeGf0GIcreATNyBExtalisDbuMqQ=="
    }
  }
}

Reproducible builds: Ideally, builds are bit-for-bit reproducible. Given the same source and dependencies, the build produces identical output. This allows independent verification of artifacts.

Threats mitigated: Build system compromise (harder), malicious pull request injection, dependency confusion, supply chain attacks via dependencies.

Remaining threats: Sophisticated attacks on the build platform itself, compromised dependencies that pass review.

SLSA Level 4: Highest Assurance

Level 4 is the gold standard (and currently rare):

Requirements:

  • Level 3 requirements
  • Two-person reviewed changes
  • Fully reproducible builds
  • Hermetic build environment (no network access during build)
  • Comprehensive dependency verification

This is what Google uses internally. It’s difficult to implement but provides the strongest supply chain security guarantees.

I haven’t deployed Level 4 in customer environments yet—the tooling and processes required are substantial. But for critical infrastructure, financial systems, or highly sensitive software, it’s worth pursuing.

Implementing SLSA in Practice

Here’s how I’ve deployed SLSA in real environments:

Step 1: Start with Level 1 (Provenance)

Enable provenance generation in your CI/CD:

# .github/workflows/release.yml
- name: Generate provenance
  uses: slsa-framework/slsa-github-generator/actions/generic/[email protected]
  with:
    artifact-path: ./dist/

This takes ~5 minutes to set up and immediately provides build transparency.

Step 2: Enforce Provenance Verification

Require provenance verification before deployment:

#!/bin/bash
# deploy.sh

# Download artifact and provenance
curl -O https://releases.example.com/myapp-v1.0.0
curl -O https://releases.example.com/myapp-v1.0.0.intoto.jsonl

# Verify provenance
slsa-verifier verify-artifact ./myapp-v1.0.0 \
  --provenance-path ./myapp-v1.0.0.intoto.jsonl \
  --source-uri github.com/myorg/myapp \
  --source-tag v1.0.0

if [ $? -ne 0 ]; then
  echo "SECURITY: Provenance verification failed!"
  exit 1
fi

# Deploy only if verification succeeds
./deploy-internal.sh ./myapp-v1.0.0

This creates a security gate. If an attacker compromises a developer account and uploads a malicious binary, deployment fails because provenance won’t verify.

Step 3: Pin Dependencies

Use lock files with integrity hashes:

# For Node.js
npm ci --frozen-lockfile  # Uses package-lock.json with hashes

# For Python
pip install --require-hashes -r requirements.txt

# For Go
go mod verify  # Verifies go.sum hashes

# For Rust
cargo build  # Uses Cargo.lock with checksums

Configure dependabot or renovate to automatically update lock files.

Step 4: Implement Two-Person Review

Use branch protection rules:

# GitHub branch protection
Require pull request reviews before merging: Enabled
Required number of approvals: 2
Dismiss stale pull request approvals: Enabled
Require review from Code Owners: Enabled

For critical paths (releases, build config changes), require reviews from specific teams:

# CODEOWNERS
/.github/workflows/    @security-team @platform-team
/Dockerfile            @security-team
/requirements.txt      @security-team

Step 5: Isolated Build Environment

Run builds in ephemeral containers with no network access:

- name: Build in isolated environment
  run: |
    docker run --rm \
      --network=none \
      --security-opt=no-new-privileges \
      --cap-drop=ALL \
      -v $(pwd):/workspace \
      -w /workspace \
      builder-image:latest \
      make build

This prevents builds from reaching out to fetch unexpected dependencies or exfiltrate secrets.

Detecting Supply Chain Attacks

SLSA enables detection that’s impossible otherwise. Here’s how I use provenance for security monitoring:

Continuous Verification

Periodically re-verify all deployed artifacts:

#!/bin/bash
# verify-deployments.sh

for artifact in $(kubectl get deployments -o jsonpath='{.items[*].spec.template.spec.containers[*].image}'); do
  echo "Verifying $artifact..."
  
  # Download provenance
  cosign download attestation $artifact > provenance.json
  
  # Verify provenance
  slsa-verifier verify-image $artifact \
    --provenance-path provenance.json \
    --source-uri github.com/myorg/myapp
  
  if [ $? -ne 0 ]; then
    echo "ALERT: Provenance verification failed for $artifact"
    # Send alert, create incident
  fi
done

Run this daily. If provenance verification suddenly fails, investigate immediately—it could indicate a compromise.

Provenance Drift Detection

Monitor for unexpected changes in build configuration:

#!/bin/bash
# detect-drift.sh

EXPECTED_BUILDER="https://github.com/Attestations/GitHubHostedActions@v1"
EXPECTED_REPO="github.com/myorg/myapp"

# Extract builder from provenance
ACTUAL_BUILDER=$(jq -r '.predicate.builder.id' provenance.json)
ACTUAL_REPO=$(jq -r '.predicate.invocation.configSource.uri' provenance.json)

if [ "$ACTUAL_BUILDER" != "$EXPECTED_BUILDER" ]; then
  echo "ALERT: Unexpected builder: $ACTUAL_BUILDER"
fi

if [[ ! "$ACTUAL_REPO" =~ "$EXPECTED_REPO" ]]; then
  echo "ALERT: Unexpected repository: $ACTUAL_REPO"
fi

This detects if builds start happening in unexpected locations—a strong indicator of compromise.

Dependency Analysis

Extract and analyze dependencies from provenance:

# Extract all dependencies used in recent builds
jq -r '.predicate.materials[] | "\(.uri) \(.digest.sha256)"' provenance.json \
  | sort | uniq > current-deps.txt

# Compare against baseline
diff baseline-deps.txt current-deps.txt

# Alert on unexpected new dependencies

Unexpected dependencies appearing could indicate:

  • Dependency confusion attack
  • Compromised internal package
  • Typosquatting attack

Integration with SBOMs

SLSA and SBOMs (Software Bill of Materials) are complementary, not competitive:

SBOM tells you: What components are in the software

SLSA tells you: How the software was built and whether you can trust the build

Together, they provide comprehensive supply chain visibility:

- name: Generate SBOM
  run: |
    syft packages . -o spdx-json > sbom.spdx.json
    
- name: Sign SBOM with provenance
  run: |
    cosign attest --predicate sbom.spdx.json \
      --type https://spdx.dev/Document \
      --key cosign.key \
      myapp:v1.0.0
      
- name: Generate SLSA provenance
  uses: slsa-framework/slsa-github-generator/actions/generic/[email protected]

Now consumers get both:

  1. SBOM: List of all components and licenses
  2. Provenance: Proof of how it was built

Verify both:

# Verify SBOM attestation
cosign verify-attestation myapp:v1.0.0 \
  --type https://spdx.dev/Document \
  --key cosign.pub

# Verify SLSA provenance
slsa-verifier verify-image myapp:v1.0.0 \
  --source-uri github.com/myorg/myapp

Challenges and Limitations

SLSA isn’t perfect. Here are the challenges I’ve encountered:

Tooling maturity: SLSA tooling is still evolving. Not all build systems support Level 3 yet. Implementation requires custom work in many cases.

Reproducible builds are hard: Achieving bit-for-bit reproducible builds requires careful control of timestamps, randomness, and build environment. Many build tools don’t support this out of the box.

Key management complexity: Provenance signing requires managing cryptographic keys securely. If build system signing keys are compromised, provenance can be forged.

Performance overhead: Generating and verifying provenance adds latency to builds and deployments. In my experience: 30-60 seconds per build for provenance generation, 5-10 seconds per deployment for verification.

Cultural change: Teams used to pushing binaries directly need to adapt to provenance-based workflows. This requires training and process changes.

Despite these challenges, the security benefits outweigh the costs for any moderately sensitive software.

Real-World Impact

I’ve deployed SLSA in three production environments. Results:

Financial services company (SLSA Level 2):

  • Detected and blocked 3 dependency confusion attempts in 6 months
  • Identified compromised developer laptop attempting to push malicious build
  • Reduced supply chain risk score by 60% (per internal assessment)

SaaS platform (SLSA Level 2):

  • Caught unauthorized binary pushed by contractor with stolen credentials
  • Provenance verification prevented deployment of compromised artifact
  • Zero-day detection: artifact built from unexpected source

Open source project (SLSA Level 1):

  • Provenance generation increased user trust
  • Downloads increased 40% after implementing verified builds
  • Community contributors submitted PRs to improve SLSA level

The common thread: provenance catches attacks that traditional security misses.

Getting Started Checklist

To implement SLSA in your organization:

  1. Assess current state: What level are you at? (Probably Level 0)

  2. Enable provenance (Level 1):

    • Add provenance generation to CI/CD
    • Publish provenance alongside artifacts
    • Document provenance format

  3. Enforce verification (Level 1):

    • Add provenance verification to deployment pipeline
    • Block deployments without valid provenance
    • Monitor verification failures

  4. Use hosted builds (Level 2):

    • Move builds to GitHub Actions, GitLab CI, or Google Cloud Build
    • Disable local builds
    • Use service-generated provenance

  5. Pin dependencies (Level 3):

    • Use lock files with integrity hashes
    • Verify dependency hashes in CI
    • Automate dependency updates

  6. Implement isolation (Level 3):

    • Build in ephemeral containers
    • Disable network access during build
    • Use minimal build images

  7. Require two-person review (Level 3):

    • Branch protection with 2+ reviewers
    • CODEOWNERS for sensitive files
    • Security team review for releases

  8. Monitor continuously:

    • Re-verify provenance regularly
    • Detect provenance drift
    • Analyze dependency changes

Learning Resources

To go deeper on SLSA:

The Future of Supply Chain Security

SLSA is becoming the standard. I’m seeing:

Increasing adoption: Major organizations (Google, Microsoft, GitHub, Linux Foundation) are implementing SLSA

Regulatory push: Upcoming regulations (US Secure Software Development Framework, EU Cyber Resilience Act) require supply chain attestation

Tool integration: Container registries, package managers, and CI/CD platforms adding native SLSA support

Industry mandates: Fortune 500 companies starting to require SLSA Level 2+ for vendor software

In 3-5 years, I expect SLSA provenance to be as standard as HTTPS is today. Software without verifiable provenance will be considered too risky to deploy.

Conclusion

Supply chain attacks are the biggest threat to software security today. Traditional defenses—code review, vulnerability scanning, MFA—aren’t enough against compromised build systems and dependency attacks.

SLSA provides verifiable supply chain security through build provenance and progressive security levels. It’s not theoretical—it’s battle-tested at Google scale and now available to everyone.

Start with Level 1 (provenance generation). Move to Level 2 (hosted builds). Progress to Level 3 (hardened builds) for critical systems. Each level provides concrete security improvements against real attacks.

The tooling is maturing, the standards are stabilizing, and the industry is moving toward SLSA as the baseline for supply chain security. Get ahead of the curve—implement SLSA now before it becomes a requirement.

Your future security incident reports will thank you.

Thank you for reading! If you have any feedback or comments, please send them to [email protected] or contact the author directly at [email protected].