As of SLSA v1.0, what do Build levels 1, 2 and 3 require, and how would you decide how far to push a large organisation up that ladder?

## What the ladder says, as of SLSA v1.0 SLSA (Supply-chain Levels for Software Artifacts) v1.0 restructured the earlier draft into *tracks*. Only the **Build track** is specified at v1.0, with levels 1 to 3; the earlier v0.1 draft's level 4 was deferred rather than carried over, and source and dependency tracks were left for future work. Getting this right matters in an interview, because a candidate quoting "SLSA level 4" is quoting a draft that no longer defines it. - **Build L1 — provenance exists.** The build process produces a provenance document describing how the artifact was made, and makes it available to consumers. It defends against nothing adversarial by itself; its real value is forcing a repeatable, scripted build rather than a laptop and a shell history. - **Build L2 — signed provenance from a hosted build platform.** The provenance is authenticated and generated by a build service rather than asserted by the publisher. A consumer can now tell that an artifact came from that platform, which defeats the publisher who simply claims a build happened. - **Build L3 — hardened builds.** The platform runs builds in isolated environments and keeps provenance-signing material inaccessible to user-defined build steps, so one project's build cannot forge provenance for another and a compromised build step cannot lie about itself. This is the level at which provenance becomes evidence rather than testimony. Two properties of the model are easy to miss and change every decision below: levels apply **per artifact**, not per organisation — "we are L3" is a category error — and a level delivers value only when a **verifier** enforces it. An unverified attestation is a file. ## The decision framework **Start from the artifacts, not the levels.** Inventory what you actually ship and rank by blast radius: what runs in production, what customers install, what other teams build on top of. A ladder applied uniformly across every internal tool is expensive and mostly protects nothing. **Buy L1 with consolidation.** For most organisations the cheapest large win is that hand-built and laptop-built release artifacts stop existing. Moving every release onto a shared pipeline gets provenance as a by-product and eliminates the genuinely worst case — an artifact nobody can trace to a commit. **Spend on L2 where trust crosses a boundary.** Anything consumed outside the producing team benefits from an authenticated builder identity, because that is the point at which "trust the publisher" stops being sufficient. **Ration L3.** L3 requires a build platform whose signing identity your build steps cannot reach, which in practice means constrained, isolated, often ephemeral builds — and that conflicts directly with the flexibility teams like: privileged self-hosted workers with persistent state, interactive re-runs, hand-patched releases. Pay that cost for artifacts where forged provenance would be catastrophic, not across the estate. ## Where these programmes actually fail **No verifier.** Producing attestations is a pipeline change; refusing to deploy artifacts that fail policy is an organisational change that will, on the first day, block a legitimate release. Fund the enforcement point and its exception path before generating a single attestation, or you get compliance theatre. **Level confused with security.** SLSA is an *integrity* track. It says the artifact came from the build you think it did. It says nothing about whether the source was reviewed, the dependencies were vetted, or the code was any good. A perfectly L3 artifact can be built from a poisoned dependency — the provenance will faithfully record that. Presenting SLSA to leadership as "supply-chain security solved" sets up a predictable, credibility-destroying incident. **Ignoring the inputs.** Because the Build track constrains the build, teams under-invest in what goes *into* it — pinned inputs, protected pipeline definitions, credential-free handling of untrusted contributions. Those controls are cheaper than L3 and prevent attacks L3 does not address. **Uniform mandates.** A blanket "all repositories reach L3 by Q4" collides with real constraints and gets bypassed with exemptions that never expire. A tiered policy — every release artifact at L1, customer-facing artifacts at L2, a named short list at L3 — survives contact with the organisation. ## The answer to give "I would classify artifacts by blast radius, get L1 everywhere by consolidating builds, require L2 where trust crosses a team or customer boundary, and reserve L3 for a short list — and I would build the verifier and its exception path first, because a level nobody checks is a label. I would also be explicit with leadership that this is an integrity track, not a substitute for reviewing what goes into the build."