Overview
The SLSA framework was originally introduced by Google in 2021 and is now maintained under the Open Source Security Foundation (OpenSSF). It defines a set of incremental security properties for build systems - a maturity model with levels that describe increasing degrees of assurance.
Key concepts
- A Provenance is a machine- and human-readable file describing where, when, and how a software artifact was produced - typically including the source code repository and revision, the build definition, and information about the build system.
- An Attestation is a digitally signed provenance.
- A Verification Summary Attestation (VSA) confirms that an artifact was built compliant with the attested SLSA build level. It omits technical details about the build process and can therefore be more easily shared and validated.
Build Levels
SLSA defines three incremental levels for build security:
Build L1 - Provenance exists
A provenance document exists, though its contents are not yet considered fully trustworthy or complete.
Build L2 - Hosted build platform
The build ran on a hosted build system (not a developer’s local machine), the provenance was generated by a trusted system (such as SignPath), and it is signed - making it a proper attestation.
Build L3 - Hardened builds
The build ran in an isolated, ephemeral environment - free from caches, remote sessions, and interference from other builds. A fresh environment is provisioned for every build.
SLSA attestations by SignPath
SignPath creates SLSA attestation in three distinct steps:
- SignPath Pipeline Integrity gathers and verifies relevant information from a supported origin CI/CD system
- SignPath DeepSign creates SLSA provenance build based on that information (along with other code signing operations)
- SignPath Attest signs the provenance
For details see the respective artifact configuration directives.
Attestation trust explained
In order to be able to trust an attestation issued by SignPath, clients need to:
- Verify the signature on the attestation: it must be signed by an official SignPath certificate
- Trust SignPath to evaluate the attested properties
- SignPath evaluates and continuously monitors the services and APIs it uses from supported CI/CD systems. We do extensive research based on official vendor documentation and perform our own tests to ensure that attested properties reflect the actual configuration and build execution.
- Trust all hosted CI/CD system supported by SignPath or verify that the origin system is one that you trust.
- SignPath cannot guarantee that the CI/CD system is actually operated in a safe way and safe from manipulation.
Clients do not need to trust the publisher for these security properties, as they are evaluated on the control plane without relying on the provider’s configuration. However, SignPath can only make technical evaluations and enforce technical policies. The quality of the source code (including build scripts) and code reviews is still up to the publisher.
SignPath cannot attest builds from customer-operated CI/CD systems. However, SignPath provides features for customers to self-attest builds from centrally operated CI/CD systems for individual teams.
A step-by-step guide on how to validate a Verification Summary Attestation is provided here.
Specific information about each supported build system and the underlying guarantees can be found in the SLSA Attestation definitions.