Today, we are excited to announce the important milestone of a release candidate (RC) SLSA Specification. This is the first major update to SLSA since its v0.1 release in June 2021, and the RC finalizes multiple revisions to the SLSA specifications and requirements. We’re grateful for the huge community engagement that went into shaping this work.
We’re requesting community feedback on the SLSA v1.0 RC1 Specification by March 24, 2023, with a view towards releasing a 1.0 Stable revision at the end of March.
What’s changed
We reworked the SLSA specification in response to ongoing feedback, filed issues, suggestions for course corrections, and other input from the SLSA community and early adopters. The most significant changes are:
- the division of SLSA into multiple SLSA tracks, which are separate sets of levels that measure a particular aspect of software supply chain security
- many simplifications and clarifications throughout the specification
- new guidance on provenance verification
- clarification of the build model and provenance schema, with an accompanying v1 provenance format
Tracks
A significant conceptual change is the division of SLSA’s level requirements into multiple tracks. Previously, each SLSA level encompassed requirements across multiple software supply chain aspects: there were source, build, provenance, and common requirements. To reach a particular level, adopters needed to meet all requirements in each of the four areas. Organizing the specification in that way made adoption cumbersome, since requirements were split across unrelated domains—improvements in one area were not recognized until improvements were made in all areas.
Now, the requirements are divided into SLSA tracks that each focus on one area of the software supply chain. We anticipate this division will make SLSA adoption easier for users. Division into tracks also benefits the SLSA community: developers contributing to SLSA can parallelize work on multiple tracks without blocking each other, and members of the community can contribute specifically to their areas of expertise.
SLSA v1.0 RC defines the SLSA Build Track to begin this separation of requirements, with other tracks to come in future versions. The new SLSA Build Track Levels 1-3 roughly correspond to Levels 1-3 of v0.1, minus the Source requirements. We anticipate future versions of the specification to continue building on requirements without changing the existing requirements defined in v1.0. The specification will likely expand to incorporate both new tracks and additional levels for existing tracks. We currently have plans for Build Level 4 and a Source Track.
The v1.0 RC also defines the principles behind SLSA track requirements, which will guide future track additions. For more information about the rationale for tracks, see the proposal.
Simplifications and clarifications
We’ve organized the Build track requirements to be more user friendly by better reflecting the division of labor across the software supply chain: producing artifacts, verifying build systems, and verifying artifacts.
Producing artifacts explains requirements for the software producer and the build system. It corresponds to v0.1’s Build and Provenance requirements. We’ve renamed some requirements to be more intuitive and have merged others, but the content is largely the same. The only substantive difference is that we’ve removed the requirements that were part of v0.1 L4 and the “build as code” requirement.
Verifying build systems provides a list of prompts for evaluating a build system’s SLSA conformance. Some content comes from v0.1’s Common requirements; the rest is new to v1.0.
Verifying artifacts provides guidance to package ecosystems and consumers for how to verify provenance and compare it to expectations. It is discussed more in the following section.
Verification
Another significant change in the v1.0 RC is documenting the need for provenance verification.
SLSA v0.1 specified guidance for how to produce provenance but not how to verify it. This left a large gap—most threats targeted by SLSA are only mitigated by verifying provenance and comparing it to expectations.
SLSA v1.0 RC addresses this gap by providing more explicit guidance on how to verify provenance. This is split between establishing trust in build systems themselves versus establishing trust in artifacts produced by those build systems. Build systems implement the requirements around isolation and provenance generation, and consumers choose whether to trust those build systems. Once that trust is established, consumers or package managers can verify artifacts by comparing the provenance to expectations for the package in question.
Ecosystems are already creating verification tooling, such as npm’s forthcoming SLSA support. Tooling for organizations that need to protect first-party software is also available, such as slsa-verifier.
Provenance format
The SLSA v1.0 RC simplifies SLSA’s build model and makes corresponding changes to the specification and provenance format.
A major source of confusion for SLSA v0.1 was how to model a build and represent it in provenance. The v0.1 spec and v0.x provenance formats were overly rigid about a build’s inputs, differentiating between “source”, “build config”, “entry point”, and so on. Many implementers found that their build systems did not clearly fit into this model, and the intent of each field was not clear. Furthermore, provenance requirements were described both abstractly in the SLSA specification and concretely in the provenance format, using different language. Implementers needed to jump back and forth and mentally map one concept to another.
SLSA v1.0 and the accompanying provenance v1 format attempt to address this confusion by simplifying the model and aligning terminology between the two. The main change is to represent all “external parameters” that are exposed to the build system’s users, instead of differentiating between various inputs. Now, you can represent arbitrary parameters, as long as it is possible to compare these parameters to expectations. Other parts of the provenance format were renamed, though conceptually most concepts translate from the old format to the new format. For a detailed list of changes, see provenance change history.
Request for feedback
Please open an issue to discuss feedback on the RC by March 24, 2023. We particularly welcome comments in response to the following questions:
- Does the new specification clarify SLSA’s benefits for supply chain security?
- Is the specification unambiguous on how to carry out requirements?
- Is there feedback on the provenance verification guidance?
- Are there suggestions to improve the division into multiple tracks?
- Are the updated build model and provenance format easily understood?
- Is there any remaining feedback on what may be missing?
We appreciate everyone who has contributed to the project and all the early adopters who have provided valuable feedback. Thank you to the SLSA community!