Most small teams should aim for pinned inputs and a build record, add a clean environment and offline test if they ship to customers, and pursue bit-identical output for artifacts where outside verification matters. Choose the tier by what you ship and who needs to trust it.
The three tiers
Tier 1: pinned inputs. Lockfiles committed, installs frozen in CI, toolchain versions declared, base image pinned by digest, a build record kept. Anyone on the team can rebuild with the same inputs. The output may still differ in timestamps and similar noise.
Tier 2: controlled environment. Tier 1 plus builds in a clean container, no network after dependencies are fetched, fixed locale, timezone and build path. This is where "works on my machine" mostly ends. The reproducible-builds guidance says to keep the set of relevant environment attributes small and to capture as little as possible from the environment.
Tier 3: bit-identical output. Tier 2 plus timestamps, file order, archive metadata and randomness removed, with two independent builds producing the same hash. This matches the project's definition: any party recreating bit-by-bit identical copies of the specified artifacts.
Decision table
| What you ship | Suggested target | Reason |
|---|---|---|
| Internal web service | Tier 1 | Faster rollbacks, fewer surprises |
| Customer facing SaaS | Tier 1, moving to Tier 2 | Buyers ask what is in a release |
| Libraries others consume | Tier 2 | Your consumers rebuild and compare |
| Desktop or mobile apps | Tier 2, then Tier 3 for the core artifact | Users cannot inspect what they run |
| Firmware or installers | Tier 3 where tools allow | Long lifetimes, hard to patch |
| Anything with regulated customers | Tier 2, plus a clear record | Evidence matters more than identical bytes |
This is a starting point, not a rule. The definition itself leaves it to the authors or distributors to name the relevant attributes and the expected artifacts.
What each tier costs
| Tier | Typical effort | Maintenance |
|---|---|---|
| 1 | Days | Dependency and image refresh routine |
| 2 | Weeks | Keeping the container and fixed settings current |
| 3 | Weeks to months, depends on language | Watching for new tool versions that add nondeterminism |
Signs you should move up a tier
- A customer asks you to prove which source a binary came from.
- You have rebuilt an old release and got something different.
- A build step was compromised, or you cannot rule it out after a security event.
- You distribute binaries to people who cannot easily review the source.
Signs you should stop
- Remaining differences are timestamps in logs or other files you do not ship.
- The next fix needs a patched compiler or a custom tool.
- Nobody outside the team would ever compare hashes.
Stopping is fine. Write down what is known to differ and why, so the decision is visible and can be revisited.
A caution
None of the tiers says the software is free of vulnerabilities. Reproducibility describes how the artifact was made, while scanning describes what is in it. Keep both.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning at any tier, plus policies and gates for pull requests. Free scan: gold.safeguard.sh/scan.
Quick check
Can we skip Tier 2 and go straight to Tier 3?
In practice no. Bit-identical output depends on a controlled environment, so Tier 2 work is part of the path.
How often should we review our tier?
When you change the toolchain, add a new artifact type, or get a new class of customer. Once a year otherwise.
Sources
Last reviewed: 19 October 2026.
