On SLSA's build track, where does a shared-account, script-driven gem release sit, and what one change moves it up?

## Place the pipeline by asking about roles, not steps The useful skill on the build track is not reciting rungs; it is looking at a real release path and saying where it sits and what the cheapest honest move up is. Five questions do it: 1. **Where does the build execute** — on a build service, or on somebody's machine? 2. **Is the build defined**, or partly a human running commands? 3. **Is provenance produced at all**, and does it reach the consumer? 4. **Who authors the provenance** — the build's own steps, or the platform around them? 5. **Who signs it, and can a build step reach that identity?** Everything else — how rich the document is, which fields are populated, whether it is stored beautifully — moves you between good and bad implementations of the same rung, not between rungs. ## The worked case An internal Ruby gem is consumed by a payroll batch service. It is built by an in-house orchestrator. Releases are cut by a hand-maintained script that runs under a shared build account several engineers can use, and that script publishes to the internal repository. Running the five questions: - The build executes on a service, not a laptop. Good — that part is not the blocker. - The build is scripted, so it is defined. - If the script emits provenance and publishes it beside the gem, provenance exists and is distributed: **Build L1**. If it does not, the release is **L0**, and "it's internal" is not an exemption — the consumer is another team, and the asset at stake is payroll money. - The provenance is authored by the release script — that is, by the build itself. - Any signing key is one the script reads. So: L1, and the reason it is stuck there has nothing to do with the document. ## Why the shared account is the crux The threat here is not an anonymous internet attacker. It is somebody with legitimate access to the build account: an engineer on the team, or anyone who has taken over their session. That person can alter what the gem contains and, in the same breath, alter the provenance that says what it contains and where it came from. Non-repudiation collapses because both sides of the story are written by the same hand. In a payroll path, where a small change to a batch job moves money, that is the risk that matters — and it is exactly the risk L1 does not touch. Second-order problem: a shared account means the provenance cannot even record a meaningful actor. Every release looks the same in the audit trail. ## The one change **Move provenance generation and signing out of the release script and into the orchestrator, using a signing identity the job cannot use.** That is the L1-to-L2 move and it is a platform configuration change, not a re-platforming: the orchestrator already knows the build definition, the source revision, the parameters and the resulting digests — it is better placed to describe the build than the build is. What that changes on day one: the description of the build is now made by a different principal from the one that produced it, so an insider with the build account can still publish a bad gem but can no longer make the record agree with them. The lie becomes detectable. Note the shape of this: "hosted build platform" does not mean a vendor's build service. An orchestrator you operate yourself qualifies. The requirement is about the platform having its own identity and doing the attesting, not about who owns the hardware. ## What you deliberately do not do first - **Do not chase the top of the ladder.** The rung above L2 is about hardening the platform itself — run isolation, keeping signing material away from user-defined steps. That is a platform roadmap item owned by whoever runs the orchestrator, and it does not land this quarter. Sequencing matters: take the rung that changes who can lie, then the rung that reduces who can forge. - **Do not enrich the document.** Adding fields to a self-authored statement is motion, not progress. - **Do not tighten source review instead.** It is a worthwhile control and a completely different track; it does not move you on this one. ## Levels are per-artifact and per-build path One last trap when placing a pipeline: the level describes a specific artifact produced by a specific path, not an organisation. If the gem has a documented release job and an emergency hand-publish route, you have to grade the route that produced the artifact you are holding. Teams routinely report the level of the pipeline they wish were used. ## And the claim is worthless unverified Signing without verification changes nothing. If the payroll team installs the gem without checking the signature against the expected builder identity, and without checking the source repository named in the provenance, you have added a step to a release job and nothing else. The change lands when the consumer's install path rejects an artifact whose provenance does not verify — that is the point at which the rung starts paying.