SLSA Framework Explained: Achieving Supply Chain Security Compliance

Supply chain attacks have become an acute risk for software organizations as attackers increasingly target the dependencies and pipelines that build and deliver applications. From the SolarWinds compromise to the Codecov breach, third-party and pipeline vulnerabilities have highlighted the urgent need for robust software supply chain security. Among the solutions emerging to address these risks, the SLSA (Supply-chain Levels for Software Artifacts) framework offers a comprehensive, tiered approach to securing every stage of the software production lifecycle. In this post, we’ll provide a detailed explanation of the SLSA framework, how it helps achieve supply chain security compliance, and actionable steps for implementation.

What Is the SLSA Framework?

SLSA (pronounced “salsa”) is an industry specification created by Google and the OpenSSF community to provide guidelines for securing software supply chains. SLSA defines four incremental levels of assurance, enabling organizations to progressively mature their security posture. SLSA is designed to help organizations:

• Detect and prevent tampering in their build and release pipelines
• Ensure provenance and integrity of software artifacts
• Achieve compliance with regulations and standards (e.g., SSDF, NIST, CIS Controls)
• Build trust with downstream consumers and partners

SLSA’s tiered model makes adoption practical for teams at different stages of maturity, and is quickly being referenced by security professionals, DevOps teams, and compliance auditors seeking concrete measures for CI/CD and software supply chain security.

Why Supply Chain Security Matters

The 2024 Secure Software Supply Chain Survey found that over 70% of organizations experienced significant supply chain security incidents in the last 12 months, with dependency-based vulnerabilities and compromised CI/CD pipelines as leading causes. As regulatory and customer demands for transparency and assurance increase (such as Executive Order 14028, NIST SSDF, and SBOM requirements), frameworks like SLSA provide actionable roadmaps for compliance and risk reduction.

SLSA Levels: An Overview

SLSA is structured around four ascending levels, each with specific technical requirements.

SLSA Level 1: Basic Build Integrity

• Requires that the build process is fully scripted and automated.
• Scripts should be versioned and stored in version control.
• Aim: Reduces manual intervention, minimizing human error and opportunity for tampering.

SLSA Level 2: Provenance and Build Service Security

• Builds must be run on a hosted build service.
• Requires verifiable provenance—metadata documenting how and where artifacts were built.
• This includes details like source repository, build commands, and cryptographic signatures.
• Aim: Detecting unauthorized changes and providing evidence for compliance audits.

SLSA Level 3: Hardened Build Pipelines

• The build service should be isolated and protected against unauthorized access.
• Provenance must be signed by the build service, not by individuals.
• Build environments should prevent privilege escalation and lateral movement.
• Aim: Prevent insider threats, supply chain attacks, and establish strong trust boundaries.

SLSA Level 4: Defense Against Advanced Threats

• Enforce two-person review for all code changes.
• Require hermetic builds (all inputs, dependencies, and configurations specified).
• Builds and provenance data must be reproducible—anyone should be able to independently verify the result.
• Aim: Achieve maximum assurance and compliance with the most stringent security standards.

More information and the full specifications for each level can be found at the official SLSA documentation.

Implementing SLSA: Practical Steps

1. Baseline Your Current State

• Audit existing build and deployment pipelines.
• Identify manual steps and undocumented dependencies.
• Map components against SLSA requirements, especially concerning CI/CD automation, version control, and provenance capture.

2. Automate Build Processes

• Migrate manual builds to fully scripted, repeatable processes.
• Use tools like GitHub Actions, GitLab CI, Jenkins, or cloud-native build services with auditable logs.

3. Capture Provenance Data

• Configure build services to generate machine-readable metadata for every artifact.
• Adopt standards like in-toto or Provenance to record source hash, build environment, and build steps.
• Store provenance files securely and associate them with published artifacts.

4. Harden the Build Environment

• Use ephemeral, isolated build runners in cloud or containerized environments.
• Implement access controls via IAM policies; restrict admin access and enforce least privilege.
• Monitor build infrastructure with security tools and enable audit logging.

5. Enable Defense in Depth

• Enforce peer review workflows before merging code.
• Use dependency scanning and SBOM generation tools (e.g., Syft, Trivy, CycloneDX, SPDX).
• Regularly conduct pipeline vulnerability assessments and align with SLSA Level 3 or 4.

6. Track Compliance Progress

• Maintain dashboards or CI/CD reports to visualize your SLSA adoption level.
• Link compliance evidence to internal audits and external attestations for customers or regulators.

Integrating SLSA with Other Standards

SLSA is designed to complement widely adopted frameworks:

• NIST SSDF: SLSA’s requirements align closely with the Secure Software Development Framework’s calls for build integrity, automation, and provenance.
• CIS Controls: SLSA implementation helps meet CIS Control 2 (Inventory and Control of Software Assets) and Control 16 (Account Monitoring).
• SBOM Initiatives: Generating and associating SBOMs with provenance data strengthens compliance with upcoming SBOM mandates.

Organizations often combine SLSA implementation with vulnerability management programs, container security, and zero trust policies for holistic supply chain risk reduction.

Real-World Example: CI/CD Secured with SLSA

Let’s look at an example using GitHub Actions to implement SLSA Level 2.

name: Build Artifact

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '18'
      - name: Install Dependencies
        run: npm ci
      - name: Build
        run: npm run build
      - name: Save Provenance
        run: |
          git rev-parse HEAD > provenance.txt
          echo "Built on $(date)" >> provenance.txt
      - name: Upload Provenance
        uses: actions/upload-artifact@v3
        with:
          name: provenance
          path: provenance.txt

This workflow captures code version, build time, and associates these with the build artifact—all requirements for SLSA Level 2. Scaling up, consider signing artifacts and automating SBOM uploads for SLSA Level 3 or 4 adoption.

Conclusion: SLSA as a Compliance and Risk Mitigation Engine

Adopting SLSA moves organizations beyond basic DevOps automation into measurable supply chain security compliance. By leveraging SLSA’s tiered model, security professionals and engineering leaders gain a proven blueprint for defending against attacks, meeting regulatory requirements, and creating a culture of security.

Start by mapping your current maturity against SLSA, incrementally automating builds, hardening pipelines, and generating provenance—these investments not only reduce risk but unlock new opportunities for transparency and trusted delivery.

Ready to assess or upgrade your supply chain security posture? Explore tools and consulting services that accelerate SLSA adoption and ensure compliance with the highest industry standards.

For further reading, visit slsa.dev, the OpenSSF Best Practices, or learn about Quaerens’s maturity assessments and solutions designed to bring SLSA and robust supply chain security to your enterprise.