Start with pinned inputs and a build record, then add provenance from your CI platform, then work toward reproducible output where your tools allow it. Provenance says how and where an artifact was built. Reproducibility lets a third party check the claim by rebuilding. They solve different problems.
Two different questions
Provenance asks: who built this, with what process, from which inputs? The SLSA specification describes provenance in exactly those terms. Its build track has levels. Build level 1 requires that provenance exists, level 2 requires signed provenance generated by a hosted build platform, and level 3 requires a hardened build platform. The descriptions say level 1 helps against mistakes and documents the build, level 2 addresses tampering after the build, and level 3 addresses tampering during the build.
Reproducibility asks: if I build the same source with the same environment and instructions, do I get the same bytes? The reproducible-builds project defines it as any party being able to recreate bit-by-bit identical copies of the specified artifacts, verified by comparison, usually with cryptographic hashes.
One is a statement you read and trust at some level. The other is something you can test yourself.
Comparison
| Provenance | Reproducible build | |
|---|---|---|
| Main output | A signed or recorded statement about the build | Identical bytes on a rebuild |
| Who checks | Consumer verifies the statement against expectations | Anyone rebuilds and compares hashes |
| Depends on | Trust in the build platform | Deterministic tools and pinned inputs |
| Typical effort for a small team | Low if the CI platform supports it | Medium to high, varies by language |
| Protects against | Mistakes and tampering, depending on level | A compromised build step, because a second build would differ |
A sensible order
- Pin inputs. Lockfiles, toolchain versions, base image digests. This helps both goals and costs little.
- Write a build record. Source commit, inputs and output hashes, kept with the artifact.
- Turn on provenance if your CI platform offers it, and check what level the platform's documentation says it meets. Do not describe your project as meeting a level unless you have checked the requirements.
- Aim at reproducible output for the artifacts that matter most, and compare two builds on different machines.
- Consider an independent rebuild for releases that need the highest trust.
Why not skip to reproducible
It is attractive because identical bytes are strong evidence. But the work depends heavily on your language and tools. Some ecosystems make it easy, and some embed timestamps and paths deep in outputs. A small team that spends three months chasing a hash is not necessarily safer than one that pinned inputs and published provenance in a week.
Why not stop at provenance
Provenance is as trustworthy as the platform that produced it. Reproducibility removes that single point of trust, because a second party can check without taking your word. That is the reason to keep it on the roadmap.
Where Safeguard fits
Safeguard is not a build platform or a provenance generator. It covers the dependency side: SBOMs, dependency scanning and policies that gate what enters a build. Free scan: gold.safeguard.sh/scan.
Quick check
Can I have provenance without reproducibility?
Yes. Many projects do. You are then trusting the platform that generated the provenance.
Can I be reproducible without provenance?
Yes. Anyone can verify by rebuilding, although provenance still helps tell people where to look.
Sources
Last reviewed: 19 October 2026.
