FOSSA Logo

SLSA (Supply-chain Levels for Software Artifacts)

A security framework that defines graduated levels of software supply chain security, helping organizations incrementally improve their security posture.

What is SLSA?

SLSA (Supply-chain Levels for Software Artifacts), pronounced "salsa," is a framework for ensuring the integrity of software artifacts throughout the software supply chain. Developed by Google and inspired by their internal "Binary Authorization for Borg" system, SLSA defines a set of incrementally adoptable security guidelines that help prevent tampering, improve integrity, and secure software packages and infrastructure.

The framework provides a common language and measurable security levels that allow both software producers and consumers to communicate about and evaluate supply chain security practices.

SLSA Levels

SLSA defines four security levels, with each higher level providing increased supply chain integrity guarantees:

SLSA 1: Documentation of the Build Process

  • Basic provenance generated: The build process is documented and provides basic information about how the artifact was created
  • Requires: Automated build process that generates provenance

SLSA 2: Tamper Resistance of the Build Service

  • Prevents tampering with the build process: The build service is tamper-resistant and prevents unauthorized changes
  • Requires: Using version control and a hosted build service, with generated provenance authenticated and protected from tampering

SLSA 3: Extra Resistance to Specific Threats

  • Adds protections against specific threats: Addresses threats like compromised dependencies and build system
  • Requires: Source code version control, two-person reviews, provenance authenticated by service identity, and isolated/ephemeral build environments

SLSA 4: Highest Confidence in Build Integrity

  • Provides the highest level of confidence: Ensures maximum build integrity through more stringent controls
  • Requires: Two-party review and approval of changes, hermetic builds, reproducible builds, and provenance available to consumers

Key SLSA Concepts

Provenance

Provenance is metadata about how an artifact was built, including the builder, source, dependencies, and build process. SLSA standardizes provenance format and content, making it machine-readable and verifiable.

Build Requirements

SLSA defines specific requirements for build systems at each level, including:

  • Source integrity protections
  • Build service security
  • Build as code (defining builds in a declarative, versionable format)
  • Ephemeral build environments
  • Isolated builds
  • Parameterless builds
  • Hermetic builds
  • Reproducible builds

Threats Addressed

SLSA helps mitigate various supply chain attacks, including:

  • Compromise of source repository
  • Use of improper build tools or services
  • Injection of malicious code during build
  • Upload of unauthorized artifacts
  • Use of compromised dependencies

Implementing SLSA

Organizations can implement SLSA incrementally:

  1. Start with SLSA 1: Generate basic provenance for all builds
  2. Assess Current State: Evaluate existing practices against SLSA requirements
  3. Incremental Improvement: Implement controls to move up SLSA levels
  4. Tool Integration: Use tools that support SLSA provenance and verification
  5. Producer-Consumer Model: As a software producer, provide SLSA guarantees; as a consumer, verify SLSA compliance of dependencies

SLSA Ecosystem and Tools

Several tools and platforms support SLSA implementation:

  • Sigstore/Cosign: Digital signature and verification tools for software artifacts
  • in-toto: Framework to secure the software supply chain
  • Tekton Chains: Kubernetes-native CI/CD system with supply chain security features
  • SLSA GitHub Generators: Tools for generating SLSA provenance in GitHub Actions
  • Binary Authorization: Platform-specific deployment-time enforcement of SLSA provenance

Benefits of SLSA

  • Standardized Approach: Common framework for evaluating and discussing supply chain security
  • Incremental Adoption: Allows gradual improvement rather than all-or-nothing security
  • Risk Reduction: Systematically addresses supply chain attack vectors
  • Trust Establishment: Provides artifacts with verifiable guarantees
  • Ecosystem Strengthening: Improves the security posture of the entire software ecosystem