SLSA Framework Introduction: Securing Supply Chain Integrity

A Graduated Path to Supply Chain Integrity

After SolarWinds demonstrated that build systems are a critical attack vector, the industry needed a framework for measuring and improving build integrity. In June 2021, Google introduced SLSA (pronounced "salsa") — Supply-chain Levels for Software Artifacts.

SLSA doesn't try to solve everything at once. It defines four levels of increasing assurance, allowing organizations to start where they are and progress incrementally. Each level adds specific controls that address known supply chain attack vectors.

The framework grew out of Google's internal binary authorization system, which has been used for over a decade to verify that deployed code was built from reviewed source code by authorized build systems. SLSA distills these principles into an industry-applicable framework.

The Threat Model

SLSA addresses specific supply chain threats, each corresponding to a real-world attack:

• Source code tampering — An attacker modifies source code without proper review (cf. PHP git server compromise)
• Build system compromise — An attacker modifies the build process to inject malicious code (cf. SolarWinds SUNBURST)
• Dependency manipulation — An attacker introduces a compromised dependency (cf. dependency confusion, ua-parser-js)
• Upload of unauthorized artifacts — An attacker uploads a modified artifact that bypasses the build system entirely
• Registry compromise — An attacker compromises the artifact distribution channel (cf. Codecov)

Each SLSA level provides increasing protection against these threats.

The Four Levels

SLSA 1: Documentation

Requirements:

• The build process is documented
• Provenance is generated (metadata about how the artifact was built)
• Provenance is available to consumers

What it means in practice: You know what your build process does and can produce metadata describing how each artifact was built. The provenance doesn't need to be tamper-resistant at this level — it just needs to exist.

Threat mitigation: SLSA 1 prevents the most basic attacks where an artifact is uploaded without going through any build process. It also supports vulnerability management by connecting artifacts to their source and build configuration.

How to achieve it: Most CI/CD systems can generate basic provenance. GitHub Actions can produce attestations. Document your build process and attach metadata to your artifacts.

SLSA 2: Tamper Resistance

Requirements:

• Everything from SLSA 1
• Build service generates provenance (not the developer or a user-controlled script)
• Provenance is tamper-resistant (authenticated by the build service)
• Version control and build service are hosted services

What it means in practice: Provenance is generated by the build service itself, not by a script the developer controls. This prevents developers from forging provenance for artifacts they built locally or modified after the build.

Threat mitigation: An attacker who can modify code in the repository still can't forge provenance for artifacts that weren't built by the authorized build service.

How to achieve it: Use a hosted CI/CD service (GitHub Actions, Cloud Build, etc.) that generates signed provenance as part of the build process. SLSA has published a provenance specification and GitHub Actions already supports SLSA 2 provenance generation.

SLSA 3: Hardened Builds

Requirements:

• Everything from SLSA 2
• Source and build platforms meet specific security standards
• Provenance is non-falsifiable (the build service is hardened against attempts to forge provenance)
• Build runs in an isolated, ephemeral environment

What it means in practice: The build environment is hardened to prevent even privileged users from influencing the build output outside of the defined build process. Builds run in isolated environments that are created fresh for each build and destroyed afterward.

Threat mitigation: This level addresses the SolarWinds-type attack — where an attacker compromises the build infrastructure. Even if an attacker gains some access to the build system, the isolation and hardening controls prevent them from tampering with individual builds.

How to achieve it: Requires a build platform with strong isolation guarantees. Google Cloud Build and some configurations of GitHub Actions approach this level. The key technical requirements are ephemeral build environments, multi-tenancy isolation, and tamper-evident logging.

SLSA 4: Maximum Assurance

Requirements:

• Everything from SLSA 3
• Two-party review of all source changes
• Hermetic builds (all inputs are fully declared; no network access during build)
• Reproducible builds (building the same source produces identical output)

What it means in practice: Maximum confidence that the artifact matches the source code. Two-party review ensures no individual can unilaterally inject malicious code. Hermetic builds ensure the build doesn't pull in undeclared inputs. Reproducibility allows independent verification.

Threat mitigation: This is the gold standard. Even a compromised build system would be detected because the build output could be independently reproduced and compared. Two-party review prevents insider threats.

How to achieve it: This is hard. Reproducible builds require careful control of all build inputs — compiler versions, timestamps, filesystem ordering, and more. Very few open-source projects achieve full reproducibility today. It's a long-term goal for most organizations.

Where Most Organizations Are Today

Realistically, most organizations don't meet SLSA 1. They build software without generating provenance metadata. They can't tell you what build system produced a given artifact, what source revision it was built from, or what dependencies were resolved at build time.

The gap between current state and even SLSA 1 is primarily about tooling and process, not technology. The tools exist. The CI/CD platforms support provenance generation. What's missing is the organizational commitment to use them.

Practical Steps to Get Started

1. Document your build process — What systems build your software? What inputs do they consume? What outputs do they produce? This alone moves you toward SLSA 1.

2. Generate provenance — Use your CI/CD platform's provenance features. GitHub Actions supports SLSA provenance generation through the slsa-framework/slsa-github-generator project.

3. Use hosted build services — Move builds off developer laptops and onto hosted CI/CD systems. This is a prerequisite for SLSA 2.

4. Isolate build environments — Configure builds to run in ephemeral containers. Don't share build agents across projects or security boundaries.

5. Require code review — Two-party review is a SLSA 4 requirement but a good practice at any level. Enforce it through branch protection rules.

6. Lock dependencies — Use lockfiles and checksum verification. Pin exact versions of all dependencies, including build tools.

How Safeguard.sh Helps

Safeguard.sh aligns with the SLSA framework by providing software composition transparency at every level. The platform generates SBOMs that serve as a critical complement to build provenance — while SLSA tracks how software was built, Safeguard.sh tracks what it contains. Together, they provide complete supply chain visibility.

For organizations working toward SLSA compliance, Safeguard.sh captures dependency snapshots at build time, creating a verifiable record of every component in each artifact. This build-time SBOM serves as both a security tool and a provenance artifact, documenting the exact dependency tree that was resolved during the build.

The platform also helps validate SLSA properties by checking that declared dependencies match actual build contents, flagging discrepancies that might indicate tampering or undeclared inputs. This verification capability supports the integrity assurance that SLSA is designed to provide.