Why does SLSA v1.0's build track have no rung for source review, and where should that requirement land?

## What changed at v1.0 Early SLSA was a single ladder of levels 1 to 4, and its top level was a grab bag: build hardening, plus two-person review of the source, plus hermetic and reproducible builds. Two problems followed. First, almost nobody could claim it, because the requirements belonged to different teams with different timelines — a build-platform investment and a source-governance change had to land together to move one number. Second, the number was ambiguous to a reader: "level 4" bundled claims about three different parts of the supply chain, so a consumer could not tell which property they were being sold. v1.0 responded by **splitting the specification into tracks**. A track covers one aspect of the supply chain and has its own levels, and a producer claims a level *within a track*. At v1.0 the **build track** is the one that is defined, with levels **L0 through L3**. Source-side requirements were pulled out to be addressed by a separate track rather than kept as build rungs, and hermeticity and reproducibility were likewise not carried into the v1.0 build ladder. ## What the build track's subject actually is The build track answers a single question: **can a consumer believe a statement about how this artifact was produced?** Its rungs escalate the strength of the evidence — from no provenance, to provenance that exists, to provenance an independent build platform generated and signed, to provenance produced by a platform hardened against the build interfering with it. Notice what that scope does and does not include. Provenance identifies the source revision that went into the build, and a high build level means you can believe that identification. It says nothing whatsoever about whether that revision was reviewed by a second person, whether the change was benign, or whether anyone looked at the diff. A build track claim is a claim about a **process and its record**, not about the quality of the input. This is the confusion the split was designed to prevent, and it still shows up constantly: a vendor answering "how do you prevent a single engineer pushing malicious code?" with "we're at the top of the build track". Those are different tracks and different controls. The correct reading of a high build-track claim is: if a malicious commit did land, the provenance would faithfully name it, and you could believe the naming. ## Where the auditor's requirement lands An auditor asking for two-person review of every change is asking a source-control question. The evidence lives there: - **Branch protection and merge rules** that make an unreviewed change to the release branch impossible rather than discouraged. - **Review records** tied to the specific revisions that were released, retained for the audit period. - **Identity**, so that "two people" means two distinct humans and not one person with two accounts or a shared service account. The build track's contribution to that audit is narrower but genuinely useful: it links the **released artifact** back to the **source revision**, by digest, with an attestation a third party made. Without that link, review records prove that a commit was reviewed but not that the commit is what shipped. With it, the auditor can follow artifact to revision to review. So the two controls compose — but they are recorded and claimed separately, and a build level never substitutes for a review control. ## Talking about levels after the split Three practical consequences: 1. **Always name the track.** "SLSA L3" is incomplete post-v1.0; "SLSA Build L3" is a claim. If someone quotes a bare number, ask which track they mean and which artifacts it covers. 2. **Do not answer source questions with build claims**, and be suspicious of vendors who do — it usually indicates the spec was skimmed, not read. 3. **Expect the track list to grow.** The structure exists so that additional aspects of the supply chain can get their own ladders without renumbering the build one, which is precisely the flexibility the single-ladder design lacked. ## The design lesson underneath The split is worth understanding as a general pattern for security maturity ladders: **a level is only useful if it corresponds to a coherent set of controls with one owner.** When a rung mixes properties owned by the platform team, the source-governance process and the build's own configuration, it becomes both unreachable and uninformative. Factoring it into tracks makes each claim narrow enough to be true, cheap enough to be attempted, and specific enough for a consumer to act on. That is why the answer to "where's source review?" is not "SLSA dropped it" but "SLSA stopped pretending it was a build property".