SLSA Supply Chain Levels for Software Artifacts

Overview

SLSA (Supply Chain Levels for Software Artifacts) is a security framework designed to protect the integrity of software supply chains by defining progressive levels of assurance for software artifacts. It addresses risks related to tampering, unauthorized changes, and provenance in software development and distribution processes.

Primary Objectives

• Enable consistent assurance of software artifact integrity and provenance across development pipelines
• Benefit software engineers, security teams, auditors, and executives by providing clear security benchmarks
• Support decision-making on supply chain risk management and establish accountability for software build and release processes

Scope & Applicability

• Applicable to organizations of all sizes and industries involved in software development, particularly those distributing software artifacts
• Covers software supply chain security domains including build integrity, provenance, and artifact authenticity; excludes runtime security and endpoint protection
• Requires foundational governance such as defined software development lifecycle (SDLC) processes and asset inventories of software components

Core Structure

• Defines four incremental levels (SLSA 1 to SLSA 4) representing increasing rigor in supply chain security controls
• Organized around key principles: provenance generation, build integrity, and infrastructure security, progressing through policies, controls, and verification tests
• Uses standardized terminology such as provenance statements, build metadata, and control requirements mapped to each SLSA level

How It Is Used

• Typically adopted in phases, starting with establishing baseline provenance (SLSA 1) and advancing towards fully automated, hermetic builds (SLSA 4)
• Assessment workflows include gap analyses against SLSA levels, internal audits of build pipelines, and third-party attestations of compliance
• Integrated into engineering workflows via SDLC gates requiring provenance artifacts, build environment reviews, and backlog mapping of supply chain risks

Implementation Artifacts

• Derived policies include build environment hardening, artifact signing standards, and provenance documentation procedures
• Control libraries align with supply chain security best practices and can be mapped to broader frameworks such as NIST SP 800-161 or ISO/IEC 27001 controls
• Evidence artifacts comprise build logs, signed provenance files, configuration snapshots, and audit reports demonstrating control adherence

Measurement & Maturity

• Key metrics include percentage of builds producing verifiable provenance, frequency of build environment audits, and control coverage across pipelines
• Maturity is scored by achieving incremental SLSA levels, each representing enhanced capabilities and reduced risk exposure
• Common baselines start at SLSA 1 for basic provenance capture, with advanced organizations targeting SLSA 3 or 4 for automated and tamper-resistant builds

Common Pitfalls

• Focusing on checklist completion without aligning controls to actual supply chain risks
• Overextending scope leading to complex implementations that are difficult to maintain (“framework sprawl”)
• Unassigned ownership of controls, insufficient evidence collection, and outdated documentation undermining assurance

Integration & Mapping

• Maps to related frameworks such as NIST Cyber Supply Chain Risk Management (C-SCRM), ISO/IEC 27001, and Software Bill of Materials (SBOM) standards
• Integrates with governance, risk, and compliance (GRC) platforms, security operations centers (SOC), incident response (IR) processes, and software development lifecycle (SDLC) tools
• Tooling considerations include automation of provenance generation, continuous control testing, and integration with artifact repositories

When Not to Use It

• May be unsuitable for organizations with minimal software development or those requiring lightweight supply chain risk approaches
• Alternatives or staged approaches may be preferable when resources or maturity levels do not support full SLSA adoption

Standards & References

• Official SLSA documentation and specifications published by the OpenSSF (Open Source Security Foundation)
• Companion materials including implementation guides, control mappings, and example provenance formats available from the SLSA project repository