SLSA (provenance)

SLSA (provenance)
Name	SLSA (provenance)
Developer	Google
Released	2021
Latest release version	1.0
Programming language	Bazel (software), Tekton (software), GitHub Actions
License	Apache License

SLSA (provenance) is a framework for securing software supply chains through attestations, controls, and provenance metadata developed by Google and contributors from GitHub, Open Source Security Foundation, Cloud Native Computing Foundation, and other organizations. It defines a threat model, a layered set of integrity levels, and a provenance schema intended to interoperate with systems such as Sigstore, In-toto, Spiffe, Knative, and Kubernetes to harden build and release pipelines. The project influenced policy discussions at National Institute of Standards and Technology and informed practices adopted by vendors like Amazon Web Services, Microsoft, and Red Hat.

Overview

SLSA emerged as a response to high-profile supply-chain incidents such as the SolarWinds cyberattack, the Event-Stream (npm) compromise, and compromises affecting PyPI and npm (software), aiming to provide an auditable chain of custody for artifacts produced by build systems like Jenkins, Travis CI, CircleCI, and GitLab. It prescribes progressively stronger guarantees for provenance, reproducible builds, and attestation that integrate with identity providers like Okta and Google Workspace and with artifact registries such as Docker Hub, GitHub Packages, and Artifactory. The model is intended to be machine-verifiable across ecosystems including Debian, Fedora Project, Homebrew, and npm, Inc..

Goals and Threat Model

SLSA’s primary goals include preventing unauthorized modification of source and build inputs, ensuring authenticated build execution, and enabling verifiable provenance linking sources to binaries for incident response used by teams at CISA, European Union Agency for Cybersecurity, and corporate security groups at Tesla, Inc. and Intel Corporation. Its threat model targets attacker tactics demonstrated in the NotPetya and Stuxnet campaigns as well as contemporary supply-chain tactics attributed to actors associated with state-level operations like those described in Operation Aurora. The framework explicitly considers insider threats at organizations such as Sony Pictures Entertainment and external compromises to continuous integration providers like CircleCI and Travis CI.

Architecture and Levels

SLSA specifies a layered architecture with defined levels (0–4) that map to controls implementable in systems such as Bazel (software), Gradle, Maven (software), and Make (software). Level 0 accepts unauthenticated artifacts typical of early Linux Foundation projects; Level 1 introduces minimal provenance suitable for projects on GitHub and GitLab; Level 2 requires isolated, scripted build systems used by organizations like Google and Microsoft; Level 3 mandates two-person review workflows similar to practices advocated after the Apple iCloud hack and employed at Mozilla and Canonical (company). Level 4 adds hermetic builds, reproducibility, and quorum-based build signing comparable to measures in Intel's and ARM Holdings secure development programs.

Provenance Model and Metadata

The provenance model encodes metadata about source commits, build invocation, builder identity, and materials using schema that can be represented with in-toto statements or OCI artifact metadata. Fields commonly include references to Git (software) commit SHAs, OpenID Connect subject tokens, and signatures produced by systems like Sigstore’s Cosign. Provenance supports linking to pull requests from GitHub, merge proposals from Gerrit, and change control tickets in JIRA (software), enabling auditors from institutions such as MIT and Stanford University to trace artifact lineage. The model facilitates queries by security teams at Facebook and Twitter for forensic reconstruction.

Implementation and Tooling

Tooling for SLSA ranges from integrations in Google Cloud Build and Azure DevOps to open-source projects like Tekton (software), BuildKit, and distroless images. Popular implementations include attestation generation via Cosign and enforcement via Binary Authorization in Kubernetes clusters managed by Red Hat OpenShift. Continuous integration systems such as Jenkins, GitHub Actions, and GitLab CI/CD can emit SLSA-compatible metadata; binary verification is performed with tools used by NPM, Inc., PyPI, and package maintainers at Debian Project. Compliance and policy-as-code enforcement are implemented with platforms like Open Policy Agent and governance frameworks used by World Wide Web Consortium member organizations.

Adoption and Use Cases

Enterprises including Google, Amazon Web Services, Microsoft, Arm, and VMware have publicized moves toward SLSA-aligned controls for internal build farms and public distributions. Use cases span from securing container supply chains for Kubernetes deployments at Shopify and Netflix, Inc. to protecting firmware and embedded builds in Siemens and Boeing supply chains. Open-source ecosystems such as Apache Software Foundation projects and Linux Foundation initiatives have adopted or recommended SLSA practices to mitigate risks encountered by projects like OpenSSL and curl. Governments and standards bodies including NIST and CISA reference provenance concepts similar to SLSA in procurement and critical infrastructure guidance.

Criticisms and Limitations

Critics note that SLSA’s prescriptive levels may be challenging for small teams and solo maintainers at projects hosted on GitHub and GitLab due to costs and operational complexity, with comparisons drawn to hurdles faced by Free Software Foundation contributors. Some researchers at University of Cambridge and Harvard University argue that provenance alone cannot prevent social-engineering compromises that affected Sony Pictures Entertainment and Target Corporation; attackers can still exploit compromised credentials in Okta or CI providers. Others point to integration gaps between SLSA metadata and legacy package ecosystems like npm (software) and PyPI where language-specific tooling and cultural practices present adoption friction. Finally, legal and policy concerns raised by agencies such as the European Commission about artifact attestation, identity, and cross-jurisdictional evidence collection highlight nontechnical limitations.

Category:Software supply chain security