Modern software is assembled from hundreds of third-party components. Every library, package, base image, compiler, and build tool becomes part of the software supply chain. If even one of those inputs changes unexpectedly during a build, the resulting artifact can no longer be reliably reproduced or fully trusted.
Hermetic builds solve this problem by creating isolated build environments where every dependency is declared, verified, and fixed before compilation begins. The result is software that can be reproduced, audited, and confidently trusted.
This guide explains what hermetic builds are, why they matter, and how they strengthen software supply chain security.
What Is a Hermetic Build?
A hermetic build is a build process that runs in a completely controlled, isolated environment with access only to inputs that were provided beforehand.
"Hermetic" borrows from the idea of an airtight seal: once the build starts, nothing new gets in. It cannot fetch surprise dependencies, download packages from external repositories, or rely on machine-specific resources. Every dependency, tool, and configuration value is known in advance. The result is a build that behaves the same way regardless of where or when it runs.
A useful way to picture it: a hermetic build is cooking from a recipe with every ingredient already measured and set out on the counter before the stove is turned on. Nothing new gets added partway through, and the same ingredients produce the same dish every time.
Core Principles of Hermetic Builds
Four properties, taken together, make a build hermetic. Each is independently useful, but the security value comes from having all four at once.
Sealed Environment
The build runs in isolation from the network and from ambient machine state. There is no apt-get update, no curl to a release server, no reliance on whatever tools happen to be installed on the runner. If something is needed during the build, it has to have been supplied as a declared input beforehand.
Declared, Pinned Inputs
Every input is named explicitly and pinned to an exact version and content hash: "FastAPI 0.104.1 with this SHA-256" rather than "whatever FastAPI resolves to today." That covers:
- Application libraries
- Build tools and compilers
- Runtime dependencies
- Base container images
- Configuration files
Transitive dependencies are pinned too, usually in a lockfile, so the full graph is fixed before compilation begins.
No Network Access During the Build
This follows from the first two principles but earns its own line, because it is the property auditors and standards bodies care about most. Dependencies are fetched and verified in a separate, earlier step; the build itself runs offline against that pre-verified cache. A build that cannot reach the network cannot pull a surprise version or a tampered package at the moment of compilation.
Reproducible Output
Given the same declared inputs, the build produces a bit-for-bit identical result, verifiable by comparing the digest of two independent builds. This is the property that turns the other three into something testable. If two builds of the same inputs disagree, something leaked into the process that was not declared.
How Hermetic Builds Differ from Traditional Build Processes
Most build pipelines in production today are not hermetic, and the reason is convenience. A typical Dockerfile starts from a base image and resolves its dependencies live:
FROM ubuntu:22.04 RUN apt-get update RUN apt-get install -y python3 python3-pip RUN pip install fastapi uvicorn This is easy to write and it works, the first time. But several inputs here are decided at build time, not declared up front. apt-get update pulls whatever the Ubuntu mirrors currently serve. pip install fastapi resolves to the latest compatible release. The ubuntu:22.04 tag itself is mutable and points at different package sets over time. Rebuild this in six months and the result will differ, with no record of what the first build actually contained.
A hermetic build inverts the model. Inputs are declared and pinned in configuration, fetched and verified once, then fed into a sealed build:
name: python-fastapi python_version: 3.12.1 packages: fastapi: 0.104.1 uvicorn: 0.24.0 build_type: hermetic The difference is not cosmetic. One approach trusts that the registries, mirrors, and resolvers will behave identically on every future run. The other removes that trust dependency entirely by fixing every input before the build starts.
Why Hermetic Builds Matter for Software Supply Chain Security
Supply chain attacks often target the build process rather than the application code. Compromising a dependency, a package repository, or a build environment can reach thousands of downstream systems at once. Hermetic builds shrink that attack surface by tightly limiting what can enter the build in the first place.
Preventing Dependency Tampering
A build that cannot download packages mid-process gives an attacker far fewer openings to inject malicious code through a compromised repository or mirror. Because every dependency was supplied and verified in advance, a tampered input fails its check during the earlier fetch step, before the sealed build ever runs.
Improving Auditability
Security teams regularly have to answer concrete questions: which components went into this release, which version of a library shipped, which tools produced this artifact. A hermetic build makes those answers straightforward, because the entire process is built from a known set of inputs rather than whatever the network served that day.
Supporting Software Provenance
Provenance is the record of where software came from and how it was built. Trustworthy provenance depends on a trustworthy build process. A controlled environment with predefined inputs is what lets an organization make strong, signed attestations about how an artifact was produced.
Strengthening Compliance
Supply chain integrity now sits at the center of many security frameworks. Hermetic builds give organizations a direct way to demonstrate build consistency, dependency control, reproducibility, and traceability: the evidence those frameworks increasingly ask for. Industry standards like Supply-chain Levels for Software Artifacts (SLSA) point in the same direction at their higher levels: an isolated build environment plus signed provenance linking an artifact back to its inputs. A hermetic build generates that evidence as a byproduct rather than a manual afterthought.
Hermetic Builds and Container Security
Every container image inherits the integrity of the process that built it. If the build process can download unexpected packages or resolve changing dependencies, the image itself becomes difficult to trust, regardless of how thoroughly it is scanned later.
Consider a container build that resolves its packages from external repositories every time it runs. From one build to the next, the image can pick up different package versions, unexpected dependencies, or unverified components, which makes it genuinely hard to say what is inside any given image, or whether two images built from the "same" definition are actually the same.
A hermetic build removes that uncertainty by tying image creation to approved, declared inputs only. For containers specifically, that buys a few concrete things:
- Images that are identical from one build to the next, not approximately so
- Clear visibility into every dependency that made it in
- No live channel to a compromised upstream repository at build time
- Accurate SBOM generation, because the inputs are known rather than discovered
- Provenance tied to each image that an auditor or downstream consumer can verify
The build is the layer where container security is either established or quietly lost. Everything downstream (scanning, signing, policy enforcement) is only as trustworthy as the process that produced the image it inspects.
Hermetic Build Implementation Strategies
Moving a pipeline toward hermeticity is usually incremental. A few strategies do most of the work.
Pin Everything, Then Lock It
Replace floating tags and version ranges with exact versions and content hashes, and capture the full transitive graph in a lockfile so the entire dependency set is fixed, not just the top-level packages. This single step removes the largest source of build drift.
Separate Fetch from Build
Split the pipeline into a dependency-resolution phase that has network access and verifies every download against its hash, and a build phase that runs offline against the resulting cache. The seal lives at this boundary.
Vendor or Cache Dependencies
Mirror declared dependencies into an internal artifact store, or vendor them into the repository. The sealed build then pulls only from that trusted, pre-verified source, never from a public registry at build time.
Build in Isolated Environments
Build systems and container-build tools that support sandboxed, network-isolated execution make hermeticity the default rather than something bolted on. Native support is far more reliable than trying to enforce isolation around a tool that assumes network access.
Generate Provenance Automatically
Wire signed provenance and SBOM generation into the build, so every artifact ships with its record. Evidence created by hand drifts out of date; evidence created by the build does not.
Hermetic Builds in a DevSecOps Pipeline
Hermetic builds fit naturally into a DevSecOps workflow because they give the rest of the pipeline a trustworthy foundation to build on. A typical flow looks like this:
The real value shows up downstream. The provenance and SBOM a hermetic build emits aren't just records to file away. A deployment system can check them automatically, refusing any image whose provenance is missing or points to an unexpected source or builder. Verification stops being a manual review someone has to remember and becomes an automated gate the pipeline enforces on every deploy. It composes with the rest of a secure pipeline too: signing, attestations, and policy checks all work better when the thing being checked is exactly the thing that ships.
Common Challenges and Solutions in Adoption
Moving an existing pipeline to hermetic builds takes real work, mostly because conventional builds quietly depend on things hermeticity removes. The common obstacles are predictable, and none of them is a dead end.
Build Scripts That Reach for the Network
Many build scripts assume they can access the internet to download tools or resolve dependencies during execution. Moving those actions into a separate fetch stage ensures every dependency is pre-fetched, verified, and pinned before the hermetic build begins. The migration is usually straightforward, even if it takes some effort.
The Overhead of Vendoring Dependencies
Maintaining an internal artifact repository requires additional storage and operational effort. In return, organizations gain stronger auditability, greater control over dependencies, and protection from compromised public repositories.
Slower Builds
Initial hermetic builds may take longer because every dependency must be verified and cached. However, efficient caching means subsequent builds often recover most of that overhead, and in many environments build performance remains comparable or even improves.
Limited Dependency Visibility
Many organizations don’t have a complete inventory of the dependencies their builds consume. Creating that inventory before introducing hermetic controls helps identify hidden inputs and makes the transition significantly smoother.
Strengthening the Software Supply Chain with Hermetic Builds
Most build problems come down to inputs no one chose on purpose: a version that drifted, a package pulled at the wrong moment, a tool that happened to be on the machine. Hermetic builds remove that category of surprise by making every input a deliberate decision. For containers, that is the difference between an image you assembled and an image you can account for.
This is exactly how CleanStart builds. Every image is produced in a hermetically sealed, network-isolated environment with every input pinned and verified, and ships with a signed SBOM and SLSA Level 3/4 provenance. The result is a container image whose integrity is not a matter of trust but of record: what went in, how it was built, and proof anyone can check.
Software integrity isn’t established when an artifact is scanned. It’s established when an artifact is built. Hermetic builds create that trusted foundation, ensuring SBOMs, provenance, signing, and policy enforcement are backed by a build process that can be independently verified.
