Skip to main content
RunBook Academy

Git, CI/CD & GitOpsLXX · ProvenanceSourceTrack

SLSA source track — source control integrity and the producer side of provenance

Advanced⏱ ~24 mingit

What you'll learn

  • Describe the four SLSA source levels and the incremental guarantee each adds
  • Identify the source-control controls that satisfy L2 (signed commits, branch protection) and L3 (two-party review, hardened platform)
  • Distinguish the source track from the build track and explain why both must be operated
  • Diagnose the production failure modes of an unsigned source branch that is "obviously" protected

Prerequisites

Verified against Git 2.55.x teaching target; 2.40+ minimum · GitHub Actions continuous service; Aug 2026 documentation baseline · Argo CD v3.5.x teaching target; v3.0+ minimum · Flux v2.9.x · Sigstore Cosign v3.1.x · SLSA v1.2 · OCI Distribution Specification v1.1 · Git LFS v3.7.1 · Kubernetes (cross-course target) 1.36.x

Not yet marked complete on this device.

The SLSA source track grades the source control system that produced the artifact. The build track (Part LXX-02) grades the build platform; the source track grades the source platform. The two tracks are independent: a team can operate at SLSA build L3 on a source platform that is L0, and the result is a supply chain that defends the artifact against build-side tampering but does not defend the source from which the artifact was built.

The four source levels

  • L0 — No source integrity. The source is whatever the developer pushed from whatever device. There is no binding between the artifact and a specific commit.
  • L1 — Source commit recorded. The source control system records the commit that produced the artifact; the provenance names the commit; the consumer can look it up.
  • L2 — Signed commits and branch protection. The source commits are signed; the source branch is protected from force-push and direct push; the consumer can verify the commit signature.
  • L3 — Two-party review and hardened source platform. The source branch requires two-party review before merge; the source platform is hardened against tampering; the source history is retained. L3 is the level that resists a determined insider.
flowchart LR
    A["L0: no integrity"] --> B["L1: commit recorded"]
    B --> C["L2: signed + protected"]
    C --> D["L3: two-party + hardened"]
    A -.-> A1["Auditor cannot trust commit"]
    B -.-> B1["Auditor can read commit"]
    C -.-> C1["Auditor can verify signer"]
    D -.-> D1["Auditor can defend against insider"]

The controls that satisfy L2

L2 is the production default for most Git repositories. The controls are signed commits (every commit on the protected branch is signed with GPG, SSH, or Sigstore), branch protection (the protected branch rejects direct pushes and force-pushes; every change enters via a pull request), and commit identity (the commit author is bound to a developer identity the provenance can name). L2 does not require two-party review; L3 requires the second approval.

The controls that satisfy L3

L3 adds three controls on top of L2: two-party review (the pull request must be approved by a reviewer who is not the author, enforced by CODEOWNERS and the branch protection rule), a hardened source platform (audit logs, MFA on administrative access, restricted admin keys, retained history that cannot be rewritten without detection), and a source provenance attestation that names the source platform. L3 is the level designed to resist a determined insider with access to the source platform. The cost is the review friction and the platform investment.

The source track and the build track compose

The two tracks are independent grades that compose. The overall SLSA level is the lower of the two tracks. A team that operates at build L3 on a source L0 platform is at SLSA L0; the build attestation is the strongest claim available, but the consumer cannot trust the source from which the artifact was built. The audit team reports the lower of the two.

The production failure modes

Three failure modes the production team must own on the source track: unsigned commits on the protected branch (the consumer rejects the artifact because the commit signature is missing — the fix is to add the verification to the CI as a required check), direct push to the protected branch by an admin (the fix is to enforce the branch protection even for admins and alert on the bypass), and force-push after a release (the commits named in earlier provenance are gone — the fix is to disable force-push on the protected branch and alert on the configuration change).

Production discipline

  1. Sign every commit on the protected branch. An unsigned commit is a commit the verifier cannot trust.
  2. Enforce branch protection on every protected branch. A direct push is a push that bypasses the review.
  3. Operate the source track at L2 or above. L2 is the production default; L3 is the regulated-industry target.
  4. Report the lower of the two tracks to the audit team. The overall SLSA level is the lower of build and source.

Cross-course references

  • Git, CI/CD & GitOps — Part LXX-02 (SLSA Build Levels) is the build track; LXX-04 is the source track.
  • Git, CI/CD & GitOps — Part XX (Branches and Protection) is the branch control discipline that L2 requires.
  • Git, CI/CD & GitOps — Part XXXV-04 (Keyless Commits with Sigstore) is the signing mechanism that L2 enforces.

Quiz

Knowledge check · 4 questions

  1. Q1. A team operates at SLSA build L3 but pushes unsigned commits to the protected branch of the source repository. What is the overall SLSA level the audit team should report?

  2. Q2. Branch protection that requires pull-request reviews is not sufficient on its own to satisfy SLSA source L2.

  3. Q3. Name the three controls that satisfy SLSA source L3 on top of the L2 baseline.

  4. Q4. Diagnose why the source track is at L0 despite the team believing they are at L2, and recommend the fix.

    Team T's protected branch is configured with pull-request review and required status checks. The team tells the auditors they are at SLSA source L2. The auditors inspect the git history and find that the lead engineer commits directly to the protected branch with a force-push after each release to clean up the history. The lead engineer is a repository admin; the branch protection does not enforce the rules for admins.

Passing score: 75%. Answers are checked in this browser.