SLSA gives everyone the same words for supply chain integrity

From source to service, in levels you can name

SLSA is described as a security framework from source to service, giving anyone working with software a common language for increasing levels of software security and supply chain integrity. The framing is the important part, that it is how you get from safe enough to being as resilient as possible, at any link in the chain. A common language is worth more than it sounds, because supply chain work usually fails at the vocabulary stage, where one team says a build is trusted and another means something different by the word artifact. The name is deliberately pronounceable, SLSA is pronounced salsa, and the logo in the README is the OpenSSF mascot as a goose in armour wearing a red salsa dress, which tells you the project takes the name seriously enough to make a joke about it. The audience is broad, anyone who produces, consumes or signs software.

The repository is a specification and a website

The question of what is in this repo is answered in one sentence. The primary content is the spec/ directory, which contains the core SLSA specification, and the www/ directory, which contains the sources of the slsa.dev website, with a README in that directory for the instructions on how to build the site. The version arrangement matters if you are citing the framework. The spec/ folder on the main branch contains the current Draft specification, while the released versions are found in the same folder but on the corresponding release branch, such as releases/v1.0 and releases/v1.2. That is a deliberate choice, since it means there is exactly one draft moving and the released versions are frozen, and it also means the thing you should read depends on what you need, a released version for a policy you are signing off and the draft for what is coming.

The workstreams are where the gaps are

The README publishes the active workstreams with the people shepherding them, and the shepherd concept is defined in the contribution guide. The Build Level 4 workstream is shepherded by Andrew McNamara, the Attested Build Environments Track by Marcela Melara and Pavel Iakovenko, the Dependency Ingestion Track by Mike Lieberman, and SLSA Tooling Modernization by Adolfo García Veytia. Each links to the relevant issue, label or pull request, which means the list is a map of what the project does not yet have. The Attested Build Environments Track and the Dependency Ingestion Track are the two that matter most for an adopter, because an attested build environment is what a higher level rests on, and dependency ingestion is where the chain usually breaks, since the artifacts you build are not the artifacts you ship. The Tooling Modernization workstream points at an issue in the OpenSSF technical advisory committee repository, which is a hint that the tooling ecosystem is still catching up with the spec.

Governance, and two licences for one document

SLSA is an OpenSSF project, and the governance information, including the current steering committee members, is in a separate governance repository. There is a mechanism for involving the committee on GitHub, by mentioning @slsa-framework/slsa-steering-committee, and the project also hosts the main issue tracker, which covers the website, the specification and overall project management, while other repositories in the slsa-framework organisation have repo-specific trackers. The licensing is the part that needs care, and it is a two-layer arrangement. All SLSA specification content contributed after the adoption of the Community Specification governance model is provided under the Community Specification License 1.0, while pre-existing portions of the specification from contributors who did not subsequently contribute under that model are provided under the Apache License 2.0. For a legal review that is the sentence to start from, because a document that changed licence mid-life has two regimes in it.

The site has aliases, and the notes are published

The team keeps slsa.dev usable with a set of redirects configured in the www/ directory, and the README lists the ones that matter for convenience. The short path slsa.dev/gh points at the GitHub repository, with sub-paths for the issues and the pull requests, and slsa.dev/notes points at the meeting notes, with paths for the community notes, the positioning notes, the specification notes and the tooling notes. Publishing the meeting notes is unusual and it is the most useful thing on the list, because the notes directory shows what the project is thinking about rather than what it has decided, and the positioning notes in particular are where you would look to find out how SLSA intends to relate to the other frameworks. The community page on slsa.dev is the entry point for getting involved, and the repository has a CONTRIBUTING.md with the workstream lifecycle described in it.

What a framework is, and what it is not

The honest boundary is that SLSA is a specification, and a specification changes what people must do rather than doing it. There is no binary in this repository that makes your build trustworthy, and there is no configuration file that raises your level. The evidence has to come from somewhere else, from a build system that produces a provenance attestation and a signing story that a consumer can verify, and that is exactly why the workstream list is what it is, with the tooling modernization workstream pointing at a tracking issue in the OpenSSF technical advisory committee. The second boundary is that levels are not a security guarantee, they are a description of what a producer has committed to, and a consumer still has to decide what level to require. The third is that the draft is a draft, and the released branches are the versions you can cite. What the framework does give you is the vocabulary, the levels and the model, which is the thing a team cannot invent for itself and end up with four different words for the same guarantee.

The repository is mostly text, and the tooling proves it

The mechanical side of the repository matches its nature. The package.json has two scripts, a lint that runs markdownlint and a format that runs markdownlint with a fix flag, and the only dependency is markdownlint-cli pinned at 0.49.1, which is a good signal that this is a documentation project with one job. Alongside that there is a .markdownlint.yaml and a .markdownlintignore for the prose rules, a netlify.toml for the site deployment, a renovate.json for dependency updates, a .devcontainer/ for a consistent local environment, a .vscode/ directory, and a MAINTAINERS.md, a CONTRIBUTING.md, a code-of-conduct.md and a relatedwork.md. The tools/ directory sits next to spec/ and www/ as the third piece of the repository, and the README does not describe it, which is itself a small piece of information about where the project's own tooling work sits.

Editorial conclusion

SLSA is the right framework to plan a supply chain hardening programme against, because it gives you levels you can argue about with a team, and because the specification and the explanatory site are maintained by the same people in one place, so the terms you read about are the terms the spec uses. It is the wrong thing to install, since the repository contains a specification and a website rather than an enforcement tool, and adopting a level means finding or building the tooling that produces the evidence. Before you commit to a level, read the current draft on the main branch rather than a blog post about an earlier version, and check the workstreams list, because what the project is actively trying to solve is where the practical gaps are.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. slsa-framework/slsa on GitHub