SLSA Framework
Supply chain Levels for Software Artifacts (SLSA) is a security framework for tampering prevention, integrity improvement, and securing packages and infrastructure of a project. For more information about the SLSA framework, see the offical website https://slsa.dev.
SLSA Terminology
Immutable reference: An identifier, guaranteed to always point to the same, immutable artifact.
Provenance: Metadata about how an artifact was produced.
Revision: An immutable, coherent state of a source.
Levels of Assurance
One of the requirements for the solution is to reach SLSA Level 4 and even go beyond that. This requires a lot of process changes as well as technical work.
The SLSA model consists of 4 levels, offering an incremental level of anti-tampering protection. Levels 1-3 represent milestones with certain integrity guarantees, whereas level 4 is an ideal end state.
Level 0 means no SLSA compliance and no guarantees are given.
Level 1 demands a fully scripted / automated build process and provenance generation. It offers basic confidence in the origin of the software but doesn’t provide any tamper resistance.
Level 2 Introduces authenticated provenance generated by a hosted build at the same time demanding version control system usage. Provenance prevents tampering and offers trust in the build service.
Level 3 offers auditability of the source and the integrity of the provenance. Much stronger tampering protection is provided by preventing specific classes of threats such as cross-build contamination.
Level 4 requires two-peer source code review and a hermetic, reproducible build process. Overall Level 4 offers a high degree of confidence in the anti-tampering protection of the software.
SLSA level is not transitive, thus level of the artifact is not dependent on the level of dependencies, which are expected to have their own SLSA levels. This makes it possible to build a Level 4 artifact from Level 0 dependencies.
Requirements
| Requirements | Level 1 | Level 2 | Level 3 | Level 4 |
|---|---|---|---|---|
| Source — Version controlled | ✓ | ✓ | ✓ | |
| Source — Verified history | ✓ | ✓ | ||
| Source — Retained indefinitely | ✓ | ✓ | ||
| Source — Two-person reviewed | ✓ | |||
| Build — Scripted build | ✓ | ✓ | ✓ | ✓ |
| Build — Build service | ✓ | ✓ | ✓ | |
| Build — Build as code | ✓ | ✓ | ||
| Build — Ephemeral environment | ✓ | ✓ | ||
| Build — Isolated | ✓ | ✓ | ||
| Build — Parameterless | ✓ | |||
| Build — Hermetic | ✓ | |||
| Build — Reproducible | ○ | |||
| Provenance — Available | ✓ | ✓ | ✓ | ✓ |
| Provenance — Authenticated | ✓ | ✓ | ✓ | |
| Provenance — Service generated | ✓ | ✓ | ✓ | |
| Provenance — Non-falsifiable | ✓ | ✓ | ||
| Provenance — Dependencies complete | ✓ | |||
| Common — Security | ✓ | |||
| Common — Access | ✓ | |||
| Common — Superusers | ✓ |
✓ — required
○ — required unless justified otherwise
empty cell — not required