Only if you kept every input. The reproducible builds project defines the inputs as source code, build environment attributes such as dependency versions and flags, and the build instructions. Missing any of them, an old release may not rebuild or may not match what you shipped.
The inputs to keep
From the reproducible builds definition, a build is reproducible when the same source, environment and instructions yield bit for bit identical artifacts. That definition gives a useful checklist of what to preserve per release:
| Input | What to record |
|---|---|
| Source | Revision identifier, and a copy of the repository |
| Dependencies | Exact versions, ideally with hashes, plus the packages themselves |
| Toolchain | Compiler, runtime and build tool versions |
| Base images | Digest, and a copy of the image |
| Build steps | The pipeline definition at that revision |
| Settings | Flags and environment variables the build reads |
Why old builds break
- A package version was withdrawn or the registry moved.
- A base image tag now points elsewhere.
- A hosted build service changed its runner image.
- A certificate used for signing expired, or a signing key is lost.
- A download URL in a build script is gone.
None of these is exotic. They are ordinary drift over two years.
Run the drill
- Pick a release from 12 to 24 months ago, preferably one still deployed to customers.
- In a clean environment with no cached state, check out the recorded revision.
- Rebuild using only what you archived. If a step needs the live internet, note it.
- Compare the output with the shipped artifact by hash. A match is the best result. A mismatch is a finding, not necessarily a failure, because some builds embed timestamps.
- List every gap and fix the process, not just that one release.
- Repeat after each change to the toolchain.
What to archive going forward
NIST's Secure Software Development Framework includes a practice to preserve each software release, with a sub-practice to securely archive the files and supporting data, such as integrity verification information and provenance data, for each release. Its examples include allowing read-only access to the archive for necessary personnel only, and keeping integrity data in a separate location from the release files or signing it.
Treat the archive like a backup: separate storage, restricted write access, tested restores.
Try it yourself
Click through it at your own pace, or open it full screen.
See how a dependency inventory lists names and versions. That list is the core of the record you need for a rebuild.
Safeguard generates SBOMs per scan, which can serve as part of that record, and has a free scan.
Quick check
Do I need bit for bit identical output?
Not to benefit. Even a rebuild that differs only in known ways proves the inputs still exist.
How often should I run this drill?
Once or twice a year, and after major toolchain or pipeline changes.
Sources
Last reviewed: 19 October 2026.
