Leadership thinks SLSA Build L3 covers insider risk in source. How do you answer them?

## Why this conversation happens A build level is a satisfying thing to report upward. It has a number, it is externally defined, and reaching it took real work. The failure mode is that the number gets quoted as though it summarised supply chain security as a whole, and the next contract or board slide says "L3, therefore protected against malicious code". Your job in that room is to keep the claim exactly as wide as the evidence. ## What the build track proves, stated as a boundary SLSA v1.0 was deliberately organised into tracks, and only the build track was specified: source review and hermeticity were left outside it. Within the build track, the top rung means the artifact came out of a hardened, isolated builder running the build definition the provenance names, and that the build itself could not forge that claim. Every one of those guarantees is about **fidelity**: the builder did what it said it did. Fidelity is orthogonal to whether the thing being built deserved to be built. An insider with commit rights merging an exfiltration path through the ordinary review flow is not attacking the build at all - they are supplying it with malicious input through the front door. The build then does its job perfectly, and the provenance records, accurately and non-repudiably, that you built the backdoor. ## The provenance is not useless here - it is forensic Do not swing to "so the level is pointless". In exactly this scenario the attestation is what makes the investigation tractable: it binds a running artifact to a specific source revision, build definition and build run, so responders move from "this deployment is exfiltrating" to the commit and the author without archaeology. That shortens response, supports accountability, and makes it possible to answer "which other releases contain this" with certainty rather than inference. But confusing non-repudiation with prevention is a real interview red flag. Provenance told you afterwards. It did not stop the merge. ## The control map you put in front of leadership Answer with three columns, not with a level: | Threat | Control | Evidence | | --- | --- | --- | | Forged claim about how an artifact was built | Hardened, isolated build platform; signing material out of the build's reach | Verifiable provenance from a pinned builder identity | | Artifact substituted after the build | Verification at the consuming boundary against the subject digest | Blocking check with alerting on mismatch | | Malicious change merged by an authorised committer | Enforced multi-party review; no self-approval; no admin bypass; ownership rules on sensitive paths | Branch protection settings and review records | | Release shipped without the intended approval | Separation between who can merge and who can release | Release approval trail | | Exfiltration by code that shipped legitimately | Runtime egress restriction and detection | Network policy plus alerting on unexpected destinations | Two things fall out of that table. The build level occupies one row, which is the honest picture. And each row carries its own evidence, which is what an auditor or a customer actually needs - a level number is not evidence of a control you have not implemented. ## What you tell a customer, and what you refuse to say When a contract asks for SLSA L3 **and** protection against malicious code, answer the two halves separately: show verifiable provenance for the artifacts they consume, and describe the source-side controls as their own claim with their own evidence. What you do not do is let a build level be quoted as a code-safety guarantee, because the first incident will be measured against the claim you made, not the one you meant. ## Where the next spend goes The useful principal-level move is to rank the uncovered rows by asset exposure rather than by how attainable each control is: - If the dominant threat is insider or account takeover on the source side, invest in review enforcement and release separation, not in build-platform hardening you already have. - If you ship large amounts of third-party code, invest in inventory and advisory handling, which the build level does not touch at all. - If nothing today verifies the attestations you already produce, that is the cheapest large win available: you are paying for the signing and collecting none of the benefit. The last one is worth calling out explicitly in a leadership setting, because it is the most common shape of wasted supply-chain spend - a producer-side programme with no consumer-side check. ## Answering the question well Open with the boundary in one sentence: the build track guarantees fidelity of the build, not integrity of the source. Give the concrete case of the authorised merge. Concede honestly what provenance does buy in that case, which is speed of investigation. Then move to the control map and the spending argument, and finish on the communication discipline - the claim in the contract must be exactly the claim you can evidence.