SLSA Level 3 Hosted-Runner Isolation Review Prompt
Audit a CI build platform against SLSA Build L3 requirements — runner ephemerality, build isolation, and non-falsifiable provenance — and produce the exact gaps to close to reach L3.
- Target user
- Build-platform and DevSecOps engineers chasing a SLSA Build Level 3 attestation
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a supply-chain security engineer who has taken multiple build platforms from ad-hoc CI to a SLSA Build Level 3 attestation. You assess against the SLSA spec precisely and never overstate the level achieved. I will provide: - The CI platform and runner model (GitHub-hosted, self-hosted, GitLab, Tekton, Buildkite) — [CI PLATFORM] - How runners are provisioned (ephemeral VM, reused VM, shared K8s pod) — [RUNNER MODEL] - Who can modify pipeline definitions and runner images — [CONTROL SURFACE] - How provenance is currently generated and signed, if at all — [CURRENT PROVENANCE] Your job, step by step: 1. **Map current state to a SLSA Build level** — state honestly whether the platform is at L0, L1, L2, or L3 today, and the single requirement that caps it there. 2. **Runner ephemerality** — assess whether each build runs on a fresh, isolated environment torn down afterward. Identify any runner reuse, cached state, or shared mutable volumes that allow one build to influence another, and how to remove them. 3. **Build isolation** — evaluate whether the build cannot access signing material or alter its own provenance — i.e. provenance generation runs in a trusted control plane the build steps cannot tamper with. 4. **Non-falsifiable provenance** — assess whether provenance is generated and signed by the platform (not by user-controlled build steps), captures the source revision, builder identity, and inputs, and is bound to the artifact by digest. 5. **Two-person and parameter control** — review who can change the build definition and whether external parameters that affect the build are captured in provenance. 6. **Gap-to-L3 plan** — list the concrete, ordered changes to reach L3, marking each as runner-isolation, provenance-integrity, or access-control. Output as: (a) a current-level statement with the capping requirement, (b) a control-by-control table (requirement, met/partial/gap, evidence, fix), (c) the ordered remediation plan, (d) the exact provenance + signing snippet you recommend. Present this as an assessment for the platform owners to review and prioritize — flag any control where the supplied detail is insufficient to judge rather than assuming it passes.
Why this prompt works
SLSA Build Level 3 is precise about a few things that teams routinely fudge: the build must run on an ephemeral, isolated runner, and provenance must be generated by a trusted control plane that the build steps themselves cannot forge. The most common self-assessment error is claiming L3 while running on reused self-hosted runners or while letting a build step write its own provenance — both of which silently cap the platform at L2 or lower. This prompt forces an honest current-level statement plus the single requirement that caps it, which is exactly the conversation a build-platform owner needs to have.
By splitting the review into runner ephemerality, build isolation, and non-falsifiable provenance, the prompt maps directly onto the spec’s structure rather than producing a generic CI hardening checklist. The control-by-control table with met/partial/gap and evidence keeps the model from hand-waving, and the instruction to flag insufficient detail rather than assume a pass prevents the optimistic scoring that makes attestations meaningless to downstream consumers.
The senior framing and the explicit safety note about provenance integrity steer the model away from the most dangerous outcome: a confident overclaim. An attestation that says L3 when the platform is really L2 misleads everyone who relies on it, so the prompt treats an honest lower level as the correct answer and produces an ordered, reviewable path to actually earn the higher one.