SLSA-LEVEL-4

SLSA L4 hermetic + reproducible + multi-party.

Definition

SLSA L4 (SLSA 1.0 status: L4 removed from spec, SLSA 1.1 reintroduces as proposal) requirements proposal: (1) Hermetic build: all dependencies (source code, runtime libraries, build tools) declared upfront and fetched into build environment BEFORE build start, NO network access during 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.

Origin

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.

Example in context

Stagex Linux distribution (cybersecurity hardened minimal) built 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.

Related terms

• Reproducible Builds Debian — L4 requirement.