Run a clean build with the network off. Whatever fails is a live input your build depends on. List each one, then pin it by checksum, keep a copy you control, or remove it. The goal is not to always build offline, but to know what you are trusting.
Why offline is a useful test
The reproducible-builds documentation says inputs from the network are volatile even when they do not seem so, and that the safer course is a build system that does not rely on remote data. Its commandments include allowing for offline builds, since servers can be down and contents can change. You do not have to ship an air-gapped pipeline. You do have to know what your build fetches, and an offline attempt is a cheap way to find out.
The test
- Start from a fresh clone, so there is no leftover state.
- Warm nothing. Clear your package caches or use a clean container.
- Disable networking for the build step. A container with networking off is the easiest way.
- Run the build command and note the first failure.
- Fix or record that failure, and repeat until the build either passes or the remaining downloads are written down.
docker run --rm --network none -v "$PWD":/src -w /src your-build-image ./build.sh
Do the dependency fetch as a separate earlier step with the network on, so you can see what it downloaded, then run the compile step offline.
What the failures usually are
| Failure | What it means | Typical fix |
|---|---|---|
| Package install fails | Dependencies come from a registry at build time | Fetch with a frozen lockfile first, cache or mirror the result |
| A script downloads a tool | Unpinned tool fetched over the network | Pin version and verify a checksum, or bake it into the image |
| Base image pull fails | Image is resolved at build time | Pin by digest and keep it in your own registry |
| Version lookup call | Build asks a service for the latest version | Remove it, use the lockfile |
| Telemetry or license check | Tool phones home | Disable it in config |
Checksums when you must download
For anything that still has to come from the network, the same guidance says to ensure integrity using cryptographic checksums and to keep backups, ideally with a fallback location. It cites the FreeBSD ports system as an example, where a description lists the source files with checksums and the project keeps copies on a mirror network in case the original site is unreachable.
Security angle
An offline build also shrinks what an attacker can change by altering a remote file. Every download in your build is a point where a changed file would change your output. Verifying a checksum turns that into a loud failure.
Keep realistic expectations. Some teams legitimately fetch things at build time. The test asks just that those fetches are listed, pinned and verified.
Where Safeguard fits
Safeguard scans the dependencies recorded in your lockfiles and produces SBOMs, which covers the registry portion of what your build fetches. Free scan: gold.safeguard.sh/scan.
Quick check
Does an offline build mean I need vendored dependencies?
No. A pre-fetched, checksum verified cache or a mirror also works.
How often should we run this test?
When you change the build, and before releases. Add it to CI if it is cheap enough.
Sources
Last reviewed: 19 October 2026.
