A reproducible build means that, given the same source, environment and instructions, anyone can rebuild bit for bit identical artifacts. In Maven you start by upgrading plugins and setting project.build.outputTimestamp, then test with the artifact plugin's compare goal. The payoff is that a released jar can be independently checked against its source.
Why it matters for security
Maven's guide defines reproducible builds as practices that create an independently verifiable path from source to binary code. If a published jar and an independent rebuild match, you have evidence that nothing was injected between source and release. If they differ, you have a question to answer.
It also supports the Reproducible Central project, which the guide describes as listing project releases that were checked as reproducible by rebuilding independently from the reference build published in Central.
Steps
- Upgrade your plugins to reproducible versions. The guide suggests running the artifact plugin's check-buildplan goal to detect what needs upgrading.
- Set the output timestamp in the POM, which turns on reproducible mode for plugins.
<properties>
<project.build.outputTimestamp>2023-01-01T00:00:00Z</project.build.outputTimestamp>
</properties>
- Build and install once.
mvn clean install
- Rebuild and compare against the first result.
mvn clean verify artifact:compare
- If anything differs, investigate the diff.
The guide notes that starting with Maven 3.10.0 and 4.0.0-beta-5, reproducible mode is active by default without a POM change, and that setting a value in your POM remains useful to override the inherited static default. Check which Maven version your CI uses.
A caution about the local test
The guide is candid that this local comparison does not prove a third party can reproduce your build, because it may still suffer from environment leaks such as username or current directory. Real confirmation means rebuilding from a completely different setup, and containers can make that easier.
Fixing differences
| Symptom | What to try |
|---|---|
| Jar differs between runs | Use diffoscope to find the unstable output |
| Not sure which plugin caused it | The buildinfo goal prints a ready command with file paths |
| A plugin writes timestamps | Look for a reproducible release of that plugin |
| Differences only on another machine | Look for username, path or locale leaks |
For release votes, the guide shows comparing against a staging repository with a reference repo property, which is how Apache projects verify release candidates.
What to tell a buyer or auditor
If someone asks whether your releases are reproducible, answer with what you have actually tested. Saying that you set the output timestamp and compare two local builds is accurate. Saying that third parties can rebuild identical artifacts is a stronger claim and needs an independent rebuild to back it. Keep the comparison output as evidence, with the Maven version and plugin versions used.
Where it fits in a program
Reproducibility is one control among several. Pair it with a signed release, an SBOM and verified checksums. If you also want repeatable inputs, add Maven Enforcer rules that ban moving versions. See Enforcer rules for supply chain hygiene, and compare with the Gradle side in dependency locking.
Safeguard produces SBOMs and runs dependency scanning for Java builds, so a reproducible release can come with a current record of its components. Free scan: gold.safeguard.sh/scan.
Quick check
Does a reproducible build mean the code is secure?
No. It means the binary matches the source and build instructions. The source itself can still contain flaws.
Does this require a particular Maven version?
The guide says there is no version prerequisite, because it works at plugin level. Newer Maven versions turn the mode on by default.
Sources
Last reviewed: 19 October 2026.
