Why do reproducible build guides say to avoid network access in builds?

Because anything fetched from the network during a build can change or disappear between runs. Reproducible Builds guidance says network inputs are volatile, even when they do not seem so. If a build must fetch, check each download against a cryptographic checksum, keep backups, and prefer lockfiles or vendored copies.

What the guidance says

The Reproducible Builds documentation recommends that a build system not rely on remote data at all. If it must, it gives two rules:

1. Ensure integrity using cryptographic checksums.
2. Keep backups, ideally with a fallback location.

Its commandments list says to allow for offline builds, because servers can be down and contents can change. The SOURCE_DATE_EPOCH specification lists, among the benefits of reproducible builds, that they require removing non-deterministic or unsafe behaviour such as connecting to the internet to download build dependencies. Bazel's description of hermetic builds makes the same point from another angle: a hermetic build is self contained and does not rely on services external to the build environment.

Why fetching at build time is risky

Three different things can go wrong.

The first breaks reproducibility. The second breaks availability. The third is a supply chain risk. A checksum check handles the first and third. A backup handles the second.

The documented patterns

Checksums with mirrors. The docs use the FreeBSD ports system as an example. Port descriptions list master sites, the files to retrieve, and a distinfo file with a cryptographic checksum for each file. The infrastructure keeps a copy of all distribution files on a mirror network, so the build can fall back if the original site is unreachable.

Lockfiles. Some build systems, such as Go, Cargo and npm, can record exact dependency versions. The docs say to version that file or include it in source tarballs, so people can recreate a similar environment.

Vendored dependencies. Include a copy of your dependencies in your source tree, or reference them with methods such as git submodules.

Snapshots of distribution archives. Debian packages must be reproducible with the packages that were available in the archive when they were built, and snapshot.debian.org lets you create a system in that state. See what snapshot.debian.org is and when to use it for builds.

A step by step plan for an application team

1. List every download in your build and in your Dockerfile: base images, language runtimes, tools, scripts, models and data files.
2. Give each one a pinned version and a checksum or digest, stored in the repository.
3. Verify each checksum in the build, and fail on mismatch. For an example, see verifying a Node.js download in CI.
4. Resolve dependencies from a lockfile, not from ranges.
5. Keep a copy you control, such as a mirror or vendored directory, for what you cannot rebuild without.
6. Test it: run the build on a machine or job with network access blocked after the fetch step, and confirm it still completes.

Step 6 is the one most teams skip. It finds the fetch you forgot, such as a build script that downloads a helper tool at the last minute.

Quick check

Try it yourself

Safeguard's SBOM and dependency scanning, generally available, builds an inventory of the components your build pulls in, which gives you the list for step 1. Click the demo to see how an inventory looks.

Click through it at your own pace, or open it full screen.

Sources

• Reproducible Builds: Volatile inputs can disappear
• Reproducible Builds: Commandments
• Reproducible Builds: SOURCE_DATE_EPOCH specification
• Bazel: Hermeticity

Last reviewed: 19 October 2026.