What does a hermetic build guarantee that makes a provenance statement's input list worth trusting?
answer
- nothing enters that was not declared
- no fetching once the build starts
- the recorded list versus the real list
- completeness, not honesty
- close cousin of, not equal to, reproducible
basics
~20 sA 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.
solid answer
~50 sA build is hermetic when it is a function of a fixed, fully declared input set — source, pinned dependencies, a pinned toolchain, parameters — and the build step cannot reach anything else: no fetches mid-build, no ambient machine state, no floating version resolved at run time. Provenance is a signed statement about how an artifact came to be, and part of it is the set of inputs the platform observed. In a non-hermetic build that list can be honest yet incomplete — a step downloads a script, a resolver picks a range, a base layer is pulled by tag — so material lands in the artifact that provenance never mentions. Hermeticity closes that gap, turning "the inputs the platform noticed" into "all the inputs." It says nothing about whether those inputs are safe, and does not by itself make the build reproducible.
go deeper
Be ready to define it in one line — only declared inputs, nothing fetched once the build starts — and to say why that matters: it makes the recorded input list complete.
Explain the mechanics of the gap: mid-build downloads, floating version ranges and moving image tags land inside the artifact without ever appearing in the provenance the verifier reads.
Show you know that no SLSA build level requires hermeticity, so you must ask a producer directly, and be able to name which of your verification policies silently assume a complete input list.
Own the argument for where hermeticity is worth its cost. Locking a whole estate's builds off the network is a multi-quarter programme, and the payoff is concentrated in the artifacts whose provenance someone actually verifies.
## What hermetic means A build is **hermetic** when everything it consumes is declared and made available *before* execution starts, and the build step has no way to obtain anything else. Concretely that means no network access during the build, no reliance on whatever happens to be installed on the machine, no mutable references (a `latest` tag, an unpinned version range) resolved while the build runs, and no ambient environment that silently changes behaviour. The build becomes a function: given the same source revision, the same pinned dependency set, the same toolchain and the same parameters, it runs the same way. ## Why a verifier cares Keep the three artifacts of supply-chain evidence straight, because mixing them up is the canonical wrong answer in this area: | Artifact | Question it answers | | --- | --- | | SBOM | What is *inside* this artifact | | Provenance | *How* this artifact came to be | | Signature | *Who* vouches for it | Provenance names the artifact by digest, names the builder, describes the build definition, and lists the inputs the build platform saw. A consumer's verification policy usually reasons over that list: "was this built from our repository, from a reviewed revision, with only inputs from our approved feed." All of that reasoning inherits one assumption — that the list is **complete**. In a non-hermetic build it usually is not. The platform can only record what passed through it. If a build step curls a helper script, if a dependency resolver picks up a floating version at build time, if a container base image is referenced by a moving tag, that content lands in the artifact without appearing anywhere in provenance. Nothing was forged and nobody lied; the statement is simply describing a smaller artifact than the one you deployed. An attacker who can influence any of those unrecorded fetch paths — a compromised mirror, a hijacked download host, a maintainer account pushing a new build of a floating version — gets code into the artifact and leaves no trace in the evidence you are checking. Hermeticity removes that class of gap. If the build cannot obtain anything it did not declare, then "provenance lists only these inputs" becomes a claim about the artifact rather than a claim about the platform's powers of observation. ## Three things hermeticity is not **Not reproducibility.** They are related but distinct. Hermeticity means the same inputs are the *only* inputs; reproducibility means the same inputs yield the *identical bytes*. A hermetic build can still stamp a timestamp, a hostname or an absolute source path into the output, or iterate a map in random order, and produce a different digest every run. Hermeticity is close to a precondition for reproducibility — a build that reaches the network for unpinned content will rarely reproduce — but it does not deliver it. **Not a safety judgement about the inputs.** A dependency with a backdoor, pinned by digest, builds hermetically and is faithfully recorded. Hermeticity makes the input list trustworthy; deciding whether the things on that list are acceptable is a separate control. **Not "the build runs in a container."** Isolation of the *process* is not isolation of its *inputs*. A container with outbound network access and an unpinned package install is not hermetic in any useful sense. ## Where the SLSA build track sits on this This catches people out: the SLSA v1.0 **build track** runs L0 through L3 and does **not** require hermeticity at any level. Its levels are about the provenance existing, being produced and signed by a hosted platform, and coming from a hardened builder whose provenance a tenant cannot forge. An artifact can therefore be Build L3 and still come from a build that pulled unrecorded content off the network mid-run. If your policy reasons over the provenance's dependency list, hermeticity is what makes that reasoning sound — and you cannot infer it from the level. You have to ask the producer. ## The practical reading As a consumer of an artifact, two questions sit behind everything else. Is the recorded input list *complete* — is the build hermetic? And can I *check the answer myself* rather than take it on trust — is the build reproducible? A signed provenance statement, on its own, answers neither.
- If a build is hermetic, does that mean it is reproducible?No. Hermeticity fixes the inputs; reproducibility is about the output bytes being identical each time. A hermetic build can still embed a build timestamp, a hostname, an absolute source path, or emit files in a non-deterministic order, so two honest runs differ. Hermeticity is close to a precondition for reproducibility, not a substitute for it.
- A build downloads a helper script during its run. What is the concrete risk to the evidence?The script's content is in the artifact but not in the provenance, so every downstream check reasons about an artifact that is missing a component. Whoever controls that URL — the host, a mirror, or anyone who can hijack the name — can change what the build ingests without altering the source, the build definition, or anything a verifier reads.
- Does hermeticity tell you anything about whether your dependencies are safe?Nothing at all. It guarantees the declared inputs are the only inputs; it makes no claim about their quality. A malicious package pinned by digest is consumed and recorded faithfully. Judging the inputs is a separate control — review, provenance on those inputs, vulnerability and behaviour analysis — layered on top of a complete list.
It is the difference between a chef listing every ingredient they used and a chef cooking in a kitchen where only the ingredients on the list are in the room. The first is an honest account; the second makes the account complete.
saying these in an interview costs you the question
- Says hermetic just means the build runs in a container
- Treats hermetic and reproducible as the same property
- Claims hermeticity proves the dependencies are free of vulnerabilities
- Assumes provenance lists every input regardless of how the build ran
- Thinks a high SLSA build level implies the build was hermetic