skip to content

SLSA Levels

The SLSA build track turns "a provenance file exists" into "a hardened, isolated builder produced it". Interviewers use the levels as shorthand for how much a pipeline's own claims are worth.

on this pageshow

explore

questions

16

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

level: juniorimportance: must knowfreq 62%

answer

  1. who produced it, not just what it says
  2. state survives between jobs
  3. an earlier job can poison a later one
  4. residue never appears in the statement
  5. provisioned solely for this build, then destroyed

basics

~20 s

A reused machine keeps state from earlier builds - caches, installed tools, leftover credentials, running processes - so an earlier job could have altered this build or what was recorded about it. A single-use environment removes that whole class of doubt.

solid answer

~40 s

Provenance is a signed record saying 'this builder ran this build definition and produced this artifact'. That claim is only as strong as the platform's ability to stop one build from influencing another. On a machine that is reused, an earlier job can leave a poisoned entry in a dependency cache, a wrapper script earlier on `PATH`, a background process, or credentials on disk - and none of that residue appears anywhere in the provenance. So every field in the statement can verify while the artifact is not what the recorded definition would honestly have produced. That is why the hardened rung of the SLSA build track asks for an environment provisioned solely for one build and discarded afterwards, rather than only for a signed document. Ephemerality is what makes the record describe reality.

go deeper

for a junior

Be ready to say what provenance claims and why the machine matters at all. Know the phrase 'ephemeral and isolated' and that it means an environment created for one build and thrown away afterwards.

for a middle

Explain the concrete carriers of state between builds - caches, installed tools, background processes, credentials on disk - and why none of them show up in the provenance, so the record can verify while the artifact is wrong.

for a senior

Show judgment about a real fleet: which builds actually get fresh environments, what your cleanup misses, whether release builds are separated from everything else, and what you would stop claiming until they are.

for a principal

Own the cost argument. Fresh capacity per build is a platform spend, so be able to say what you buy by moving release builds to single-use environments while leaving pull-request feedback on warm capacity, and how you keep the claim honest.

## 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.

  • Does wiping the workspace between builds give you the same property as an ephemeral environment?
    No. Cleaning the checkout directory removes the most visible contamination, but the host still carries tool caches, installed packages, running daemons, environment state, container images and anything an earlier job planted outside the workspace. The property being asked for is an environment provisioned solely for this build and discarded after it, so residue is gone by construction rather than by a cleanup script somebody has to keep exhaustive.
  • If every build on that shared machine belongs to one trusted team, does reuse still matter?
    Yes. Trust in colleagues is not isolation. Every build pulls dependencies, plugins and test frameworks whose code nobody reviewed, so one compromised package in the least important job gets a foothold that outlives it and reaches the release build. The guarantee is about what the platform enforces, not about who owns the pipelines.
  • Where does the provenance signing key have to live for any of this to mean something?
    Outside the build. If build steps can read the key the platform signs with, any build on the platform can mint provenance naming any builder and any artifact, and the chain collapses back to self-assertion. A hardened platform holds that key in a component the build cannot address and signs once the build's own steps are finished.

A signed lab certificate is only as good as the lab. If the bench was never cleaned between samples, the paperwork is perfectly honest about the procedure and still tells you nothing reliable about your sample.

saying these in an interview costs you the question

  • Thinks signing the provenance compensates for a dirty build machine
  • Treats machine reuse as only a flakiness and caching problem
  • Assumes deleting the workspace equals an ephemeral environment
  • Calls builds isolated because trusted teams own them
  • Claims ephemerality also stops malicious commits or bad dependencies

context

open as a page

Does SLSA Build L3 provenance mean an artifact has no known vulnerable dependencies?

level: juniorimportance: must knowfreq 62%

basics

~10 s

No. The SLSA build track attests to how an artifact was produced and by which builder, not to what is inside it or whether those components are flawed. Vulnerable dependencies are a separate question.

open as a page

Why does SLSA Build L2 reject a provenance file that your own release script wrote and signed?

level: middleimportance: must knowfreq 56%

basics

~20 s

SLSA Build L2 is about who attests, not what the document says: the hosted build platform must generate and sign the provenance itself. Provenance composed and signed by the build's own steps stays at Build L1.

open as a page

Under SLSA, why is provenance signed by the build job itself worth little to a consumer?

level: middleimportance: must knowfreq 55%

basics

~20 s

Because whoever can change the build steps can also change the claim. Self-issued provenance sits at Build L1; L2 moves generation and signing to the hosted platform, and L3 puts the signing material out of reach of user-defined build steps.

open as a page

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

level: seniorimportance: must knowfreq 60%

basics

~20 s

Almost certainly Build L1 — provenance exists, but the release script that controls the build also writes it. The highest-leverage single change is having the build platform generate and sign provenance under an identity the job cannot use.

open as a page

Two organisations rebuild the same package to identical digests — what does that prove that one builder's signed provenance cannot?

level: seniorimportance: must knowfreq 46%

basics

~10 s

It turns testimony into a fact anyone can re-derive. Signed provenance is one builder's claim; independent agreement shows unrelated parties derived the same bytes, so subverting a single build platform no longer goes unchallenged.

open as a page

Signed SLSA provenance exists, but a release tarball was swapped after the build. What catches it?

level: seniorimportance: must knowfreq 50%

basics

~20 s

Only verification at the point of use catches it. Recompute the digest of the bytes about to be deployed and match it against the provenance subject digest, after checking the envelope signature and the builder identity.

open as a page

What does SLSA Build L1 add over L0 when the provenance is written by the machine that built the artifact?

level: juniorimportance: should knowfreq 52%

basics

~20 s

Build L0 means no provenance at all. L1 means provenance exists and is distributed: a machine-readable record of how the artifact was built. Self-issued and unsigned, it catches mistakes and supports investigation, not a determined forger.

open as a page

What does a hermetic build guarantee that makes a provenance statement's input list worth trusting?

level: juniorimportance: should knowfreq 42%

basics

~20 s

A hermetic build consumes only inputs declared and fetched before the build step runs, with no network access during it. That makes the provenance's list of inputs complete, not merely honest: nothing can enter the artifact that was never recorded.

open as a page

Why must a build platform fix the build definition before a run starts for its provenance to mean anything?

level: middleimportance: should knowfreq 44%

basics

~20 s

Provenance records what the platform decided to run. If the running build can rewrite the definition it is executing, the recorded steps and the executed steps drift apart, and the signed statement describes a build that never happened.

open as a page

Why does the SLSA v1.0 build track stop at L3 rather than requiring hermetic or reproducible builds?

level: middleimportance: should knowfreq 34%

basics

~20 s

SLSA v1.0 specified only the build track, L0 to L3, where each level is a build-platform property a consumer can check. Hermeticity lives in a project's own build definition and reproducibility needs a second rebuilder, so neither is checkable that way.

open as a page

A bank's build platform mounts one shared secret store into every job. Why is that a builder-level failure no pipeline fix repairs?

level: seniorimportance: should knowfreq 50%

basics

~20 s

Isolation between builds is a property of the platform, not of any one pipeline. If every job can reach every secret, the lowest-trust build on the platform effectively holds the release credentials, and no pipeline-level care takes that access away.

open as a page

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

level: principalimportance: should knowfreq 38%

basics

~20 s

The build track guarantees an artifact was faithfully built from a stated source revision on a hardened builder. It says nothing about that revision, so a backdoor merged by an authorised committer still yields a verifiable artifact.

open as a page

Why does SLSA v1.0's build track have no rung for source review, and where should that requirement land?

level: middleimportance: nice to knowfreq 34%

basics

~20 s

SLSA v1.0 split the specification into independent tracks and defines only the build track. It grades the build process and how believable its provenance is; two-person review is a source-side control, evidenced separately from any build level.

open as a page

Can an on-prem, air-gapped build platform satisfy SLSA's hosted build platform requirement, and what must you show?

level: principalimportance: nice to knowfreq 30%

basics

~20 s

Yes. Hosted is a trust property, not a purchase: the build runs as a service the projects being built cannot modify. An on-prem builder qualifies when its operators are separate from its users and its configuration is outside their control.

open as a page

A regulator asks you to prove deployed bytes came from a source revision built four years ago, on a platform since decommissioned. What holds up?

level: principalimportance: nice to knowfreq 20%

basics

~20 s

An archived attestation is evidence only while its trust chain can still be evaluated; once the issuing platform and keys are gone it is unverifiable. A deterministic build with source, inputs and toolchain preserved lets an auditor re-derive the digest.

open as a page