SLSA

SLSA
Name	SLSA
Abbreviation	SLSA
Type	Security Framework
Developer	Google
Released	2021

SLSA is a security framework and provenance standard for software supply chains designed to ensure integrity, provenance, and tamper resistance of build artifacts. It defines a threat model, a set of levels, and recommended controls intended to reduce risks observed in incidents such as those affecting SolarWinds, Log4Shell, npm typosquatting, and PyPI incidents. The framework is promoted by organizations including Google, OpenSSF, GitHub, Microsoft, and CNCF and is used as a guiding model alongside standards such as in-toto and Supply-chain Levels for Software Artifacts (SLSA)-adjacent initiatives.

Overview

SLSA defines a graduated set of protections that span provenance, build service attestation, and artifact immutability. It complements provenance formats like in-toto and Software Bill of Materials efforts such as CycloneDX and SPDX, fitting into ecosystems that include GitHub Actions, GitLab CI/CD, Jenkins, Tekton, and Argo CD. The model addresses threats exemplified by incidents involving Colonial Pipeline, SolarWinds Orion, NotPetya, and supply chain compromises observed in ecosystems like npm and PyPI by specifying requirements for authenticated source control such as GitHub, Bitbucket, and GitLab and for artifact registries like Docker Hub, Artifact Registry, and npm registry.

History and Development

SLSA originated from internal practices at Google and was publicized in coordination with projects and organizations including OpenSSF, GitHub, Microsoft, and CNCF. Early motivations drew on supply chain attacks such as SolarWinds (2020) and historical concerns raised by incidents like Stuxnet and Operation Aurora. The framework evolved through community discussion in venues including DEF CON, Black Hat USA, RSA Conference, and KubeCon workshops, and contributions from vendors like Red Hat, IBM, AWS, and Google Cloud Platform. Specifications and advisories were discussed alongside standards work in OWASP and interoperability projects with in-toto and Sigstore.

Architecture and Levels

SLSA defines a set of ascending assurance levels that prescribe controls for source control, build systems, and artifact provenance. Level 1 emphasizes basic build processes used by tools like Maven, Gradle, npm, and pip, while Level 2 requires tamper-evident provenance often produced by CI systems such as GitHub Actions, GitLab CI/CD, Jenkins, and Azure Pipelines. Level 3 mandates reproducible builds and isolated build environments exemplified by Bazel, Nix, and Guix, and Level 4 prescribes hermetic builds, non-falsifiable build attestations, and verifiable build delegation similar to architectures promoted by Distroless and Google Cloud Build. The architecture relies on cryptographic attestations analogous to standards in The Update Framework and signing mechanisms used by Sigstore, GPG, and X.509-based systems.

Use Cases and Adoption

Adopters include cloud providers and platform vendors such as Google Cloud Platform, Amazon Web Services, Microsoft Azure, and corporations like Red Hat and VMware integrating SLSA-aligned practices into CI/CD pipelines. Package ecosystems—including npm, PyPI, and Maven Central—and container registries like Docker Hub and OCI registries use provenance and attestation to varying degrees. Enterprises engaged in regulated sectors including FINRA, FedRAMP, and NIST-aligned programs map SLSA levels to compliance objectives, and open source projects such as Kubernetes, TensorFlow, and Istio reference SLSA concepts when formalizing release processes.

Security Considerations

SLSA addresses supply chain threats by prescribing mitigations against source compromise, build system compromise, and artifact tampering. Threat actors exemplified by incidents attributed to groups linked with Cozy Bear, Fancy Bear, and criminal campaigns exploiting npm and PyPI illustrate adversaries SLSA seeks to deter. Controls include authenticated commits via platforms like GitHub and Bitbucket, cryptographic signing via Sigstore and GPG, and build isolation using systems such as Bazel and NixOS. SLSA also emphasizes provenance storage and verification often performed with tools such as in-toto and registries adhering to OCI specifications. However, SLSA is complementary to runtime protections provided by projects such as Kubernetes and Istio rather than a replacement.

Implementation and Tooling

Tooling for SLSA includes attestations and signing solutions like Sigstore (Rekor, Fulcio, and Cosign), provenance frameworks like in-toto, CI integrations across GitHub Actions, GitLab CI/CD, Jenkins, and Tekton, and reproducible build tools like Bazel, Nix, and Guix. Artifact registries and scanning platforms from Sonatype, JFrog, Snyk, and Anchore integrate with provenance data. Major vendors such as Google Cloud Build, AWS CodeBuild, and Azure DevOps provide capabilities to produce SLSA-aligned attestations and integrate with verification services used by OpenSSF initiatives.

Criticisms and Limitations

Critics note that achieving higher SLSA levels can be resource-intensive for projects like Debian, Ubuntu, Fedora, and small npm or PyPI maintainers, and that tooling gaps remain for ecosystems such as legacy Maven Central and bespoke build systems. Others argue that provenance alone cannot prevent insider threats as seen in cases involving SolarWinds and that dependence on centralized services like GitHub or Docker Hub introduces concentration risk. Interoperability issues persist between attestation formats like in-toto and emerging registries despite work by CNCF and OpenSSF to harmonize approaches.

Category:Software supply chain