Don't Panic: SLSA Framework

SLSA is a framework for asking whether a software artifact came from the source and build process it claims to have used. That sounds like a bureaucratic question until a package, binary, or container image arrives through a familiar channel wearing a convincing name badge. Familiar channels are very good at names. Digests and provenance are better at evidence.

The important shape is a path: source revision, build platform, artifact, distribution, consumer. Provenance records how an artifact moved through the useful middle of that path. It can name the builder, the process, inputs, and the artifact digest. It is not a verdict. A signature can establish that some recognized identity made the statement. It cannot decide whether that identity was the right one for this release, which is where the small print becomes the actual security boundary.

SLSA separates the work into Build and Source tracks. Build asks how trustworthy the evidence about producing an artifact is. Source asks how trustworthy the creation of a source revision was. Their levels are independent, so “SLSA 3” is a vague answer dressed as a concise one. Name the track, level, and specification version instead.

The surprise is that generating provenance is only the beginning. A verifier must match the subject digest, authenticate the evidence, recognize the builder, and compare the source, build type, and external parameters with policy. An unknown parameter is not harmless decoration. It can change a build while leaving a careless verifier pleased with itself.

Start with one release path and one artifact class. The Intro explains the tracks and their limits. Slides give the path and the decision points in a compact map. The Cheatsheet is for the exact checks and level anchors. Field Notes covers the operational edges that turn “we have provenance” into a release boundary that can actually reject something.

Don't Panic: SLSA Framework

Relevant careers