Introducing SLSA: An End‑to‑End Framework for Software Supply Chain Integrity

1. Background

Software supply‑chain attacks have risen sharply in the past two years, targeting every stage from source code to build and release. Incidents such as SolarWinds and Codecov demonstrate the need for an end‑to‑end framework that can mitigate these threats.

2. Purpose of SLSA

Google proposes SLSA (Supply chain Levels for Software Artifacts) as a comprehensive, industry‑accepted framework that provides provenance metadata to help users make risk‑based decisions about software components.

3. Typical Supply‑Chain Threats

The following table lists common threat types, real‑world examples, and how SLSA can defend against them.

Threat Type

Example

SLSA Defense

Malicious code submitted to source repo

Linux patch with intentional vulnerability

Two‑person code review catches most issues

Compromised source‑code hosting platform

PHP official git server breach

Hardening the platform raises attacker cost

Build uses mismatched source

Webmin workflow alteration

SLSA‑compliant build server detects mismatches

Compromised build platform

SolarWinds build platform injection

Higher SLSA levels require strong build‑platform controls

Malicious dependency

Event‑flow attack via transitive deps

Provenance across all deps can block such attacks

Upload of non‑CI/CD generated middleware

CodeCov malicious middleware upload

Provenance shows unexpected origin

Malicious software repository

Compromised software mirror sites

Provenance reveals unexpected source

Package name squatting

Malicious package with similar name

SLSA alone cannot stop it; combined with source‑link controls

4. SLSA Levels

SLSA defines four incremental levels. Level 1 requires fully scripted builds with provenance metadata. Level 2 adds version control and authenticated provenance from a hosted build service. Level 3 further mandates auditable source and build platform standards. Level 4, the ideal, demands two‑person change review, a closed reproducible build process, and strong isolation.

5. Implementation Example

Google released an SLSA 1 provenance generator for GitHub Actions. Adding the following snippet to a workflow generates the required provenance:

- name: Generate provenance
  uses: slsa-framework/[email protected]
  with:
    artifact_path: <path-to-artifact/directory>

6. Future Work

Plans include tighter integration with popular source, build, and packaging platforms to automate provenance generation and propagate it across package registries, aiming to make higher SLSA levels the default security posture.

7. Conclusion

SLSA offers a practical, scalable model for end‑to‑end software supply‑chain integrity. While achieving the highest level may be challenging, incremental adoption of lower levels substantially improves the security of the open‑source ecosystem.