SLSA-LEVEL-4

SLSA L4 hermetic + reproducible + multi-party.

Définition

SLSA L4 (status SLSA 1.0 : L4 removed from spec, SLSA 1.1 reintroduces as proposal) requirements proposal : (1) Hermetic build : tous dependencies (source code, runtime libraries, build tools) declared upfront and fetched into build environment BEFORE build start, NO network access pendant build (preventing build-time injection from external repos), reproducible package manager pins. (2) Reproducible build : same inputs -> bit-identical outputs (deterministic), enabling third-party verification via independent rebuilds. (3) Two-party review code (release branches require minimum 2 approvers, not just 1 like L3). (4) Strong code review : reviewers see actual changes (not auto-generated). Implementations : Bazel native hermetic builds (Google open-source build tool), NixOS reproducible Nix derivation, Debian Reproducible Builds project (~95% packages reproducible 2024), Stagex bootstrappable + hermetic + reproducible OSS distro. Use case : security-critical software (security audits, kernel, crypto libraries), governmental Reproducible Builds requirements emerging.

Origine

SLSA L4 proposed 2021 Google SSCS ; SLSA 1.0 OpenSSF 2023 removes L4 from spec (too aspirational), reintroduces L4 as proposal SLSA 1.1 draft 2024 ; <1% projects L4 2024.

Exemple en contexte

Stagex Linux distribution (cybersecurity hardened minimal) construit via Stagex Build System hermetic + reproducible : all packages bootstrappable from trusted seed, hermetic dependency resolution, bit-identical reproducibility, multi-party review releases ; potential SLSA L4 reference implementation.

Termes liés

• Reproducible Builds Debian — L4 requirement.