Why is build provenance from a long-lived, reused build machine worth less than from a single-use builder?

## What a provenance statement actually claims Build provenance is a signed record produced by a build platform. It identifies an artifact by its digest and says how it came to be: which builder ran, from which source revision, through which entry point, with which parameters. A consumer verifies the signature, checks the builder identity against policy, and checks that the recorded source and entry point are the ones it expects. Notice what is *not* in that list. The statement describes the **build definition**, not the **build environment's history**. Nothing in a well-formed provenance file tells you whether the machine that executed it had just finished running somebody else's code. ## What 'ephemeral and isolated' means The SLSA build track's hardened rung asks the platform to guarantee that each build ran in an environment provisioned solely for that build, free of influence from other builds - including previous ones - and not reused afterwards. It is a property the *platform* enforces for every tenant, not something an individual pipeline can grant itself. ## What actually crosses a reused machine - **Dependency and tool caches.** A later build silently consumes a cache entry an earlier build wrote. The lockfile still matches; the bytes on disk do not. - **Installed toolchains and anything on `PATH`.** A wrapper planted where the compiler or package manager is looked up intercepts every subsequent build. - **Resident processes.** A daemon left running can watch the filesystem, scrape environment variables from later jobs, or patch an output after the tests have passed. - **Credentials on disk.** Cloud CLI credential caches, registry logins and helper config files written outside the workspace. - **Container images and layer caches**, and the state of the build agent process itself. The common thread: all of it is invisible to the provenance. The statement records intent; the residue changes the outcome. ## Why 'we clean the workspace' is not equivalent Workspace cleanup is a deny-list that humans maintain: someone has to enumerate everything a hostile job might leave and remove it, forever, as the toolchain changes. Ephemerality is the same guarantee by construction - whatever an earlier build touched is gone because the environment is gone. The asymmetry matters: the attacker picks where to hide, and you have to guess correctly every time. ## Trust boundary, not team boundary A common objection is that all the builds on the shared machine belong to one trusted team. Trust in colleagues is not isolation. Every one of those builds executes third-party dependencies, plugins and test frameworks that nobody reviewed. One compromised transitive dependency in the least important job gets a foothold that outlives that job and reaches the release build. The platform's security level is set by the worst code that runs on it, not by the best-behaved pipeline. ## Where the signing key has to live The same reasoning extends to the key the platform signs provenance with. If user-defined build steps can read it, any build can mint a statement naming any builder and any artifact, and verification downstream becomes theatre. Hardened platforms keep that key in a component the build cannot address, and sign after the build's steps have finished. ## What ephemerality does not buy It does not stop a malicious commit, a vulnerable or backdoored dependency, or a compromised platform operator. It closes exactly one class: builds influencing other builds through the environment they share. Being precise about that scope is what separates a candidate who has read the requirement from one who has recited it. ## Practical shape Provision a fresh container or virtual machine per build from a known image, keep no writable state that survives the run, and perform the signing outside the build's reach. Where fresh capacity for everything is genuinely too expensive, the honest compromise is to separate: release builds on single-use environments, fast feedback builds on warm capacity - and claim only what the release path actually satisfies.