SLSA-SOURCE-TRACKS

SLSA Source Tracks v1.1 draft separate Build + Source.

Definition

SLSA Source Tracks levels proposal v1.1 draft: (1) Source L1: source code version-controlled (Git, Mercurial, SVN, etc.), commit history preserved, source identifier (e.g., Git commit SHA) tracked + included in provenance. (2) Source L2: two-person review required (minimum 1 reviewer approval) for changes merged to release branches (e.g., main), protected branch rules, no direct push by single individual to release branches. (3) Source L3: tamper-resistant source repository (no force-pushes allowed + tag protection + signed commits/tags optional but recommended), audit trail accessible + retention >18 months minimum, source repository hosted on trusted hosting platform with integrity guarantees (GitHub + GitLab + Bitbucket Enterprise level integrity controls). (4) Source provenance attestation: separate from Build provenance, includes source identifier + reviewers (if L2+) + commit signers (if L3 signed) + branch protection rules state. Use cases: separately verify Source vs Build properties (e.g., project has Build L3 but Source L1 only = build process tamper-resistant but source code anyone can push, less ideal). Status: draft 2024, expected stabilize SLSA v1.1 2025+.

Origin

SLSA Source Tracks proposal SLSA Working Group OpenSSF 2024 ; SLSA v1.1 draft 2024 ; expected stabilize 2025+.

Example in context

Open-source project achieves Build L3 (GitHub Actions hardened build) + Source L2 (GitHub branch protection requiring 1 reviewer approval main branch): separately verifiable Build vs Source compliance, allows incremental improvement (Source L3 future via signed commits + tag protection).

Related terms

• SLSA L3 — parent Build Track.