Hermetic & reproducible builds

Pinned inputs, isolation, bit-identical output.

Trustworthy provenance depends on a trustworthy build. Hermetic, isolated, reproducible builds are what make the difference between provenance you can rely on and a record a compromised build could fabricate.

Hermetic and isolated

A hermetic build declares all its inputs up front and runs without arbitrary network access, so it cannot fetch an unknown dependency or attacker payload mid-build — the inputs are pinned, known, and recorded in provenance. Isolation means build steps cannot tamper with the platform that observes and attests them, which is exactly what makes SLSA L3 provenance non-falsifiable. Together they shrink the build’s attack surface: no surprise inputs, no cross-contamination between builds, and a record the build itself cannot forge.

# WEAK: fetches whatever is current at build time — unrecorded, mutable input.
RUN curl -sL https://example.com/install.sh | bash
RUN pip install requests            # resolves to "latest" at build time
 
# STRONG: pinned by digest/hash; hermetic builders forbid unpinned network I/O.
RUN pip install --require-hashes -r requirements.lock   # exact versions + hashes
COPY --from=builder /out /app        # inputs come from declared, pinned stages
# The provenance then records exactly these inputs by digest.

Reproducible builds

A reproducible build yields bit-for-bit identical output from the same source and inputs, no matter who runs it or when. That property is powerful for the supply chain: an independent party can rebuild the artifact and confirm it matches, so injected changes are detectable and provenance claims are checkable. Achieving it means eliminating nondeterminism — timestamps, build paths, ordering — which many toolchains now support. Reproducibility complements signing and provenance: signing says who, provenance says how, and reproducibility lets anyone independently verify the how.