Answer with what you can demonstrate today, in plain terms: which inputs are pinned, whether you keep a build record, and which artifacts you have rebuilt and compared. If you have not verified identical output, say so. A precise partial answer is more useful to a buyer than a broad yes.
What the buyer is really asking
A questionnaire line about reproducible builds is usually a stand-in for a few concerns: can you tell what is in a release, could someone tamper with the build without you noticing, and can you rebuild an old version if needed. You can speak to those directly, whatever your reproducibility status.
The reproducible-builds project defines the term as recreating bit-by-bit identical copies of specified artifacts from the same source, environment and instructions. Use that definition so your answer and the buyer's question mean the same thing.
Three honest tiers
| Your situation | Suggested wording shape |
|---|---|
| Inputs pinned, no hash comparison yet | "Our builds use pinned dependencies and base images, and we keep a record of inputs for each release. We have not verified bit-identical rebuilds." |
| Some artifacts compared | "We have rebuilt the following artifacts on separate machines and confirmed matching hashes: (list). Others are not yet verified." |
| Routine independent rebuilds | "We rebuild releases independently and compare output hashes before publishing. Known exceptions: (list)." |
Fill in the bracketed parts with facts you checked. Do not copy wording that implies a stronger tier than the one you are in.
What to attach or offer
- A description of the build script and where it runs.
- An example build record with source commit, inputs and output hashes.
- Your policy for updating pinned dependencies and base images.
- An SBOM for the release, if the buyer asks for one.
Keep the offer to things that exist. If you are going to produce something on request, say so.
Words to avoid
- "Fully reproducible" without naming the artifacts and the test you ran.
- Anything that implies a certification or third-party attestation. Reproducibility is a technical property that anyone can test, not a certificate.
- "Tamper proof." A reproducible build helps detect a compromised build step, but it does not protect the source or the dependencies.
Prepare before the questionnaire arrives
- Run the two-build comparison on your main artifact and note the result, including differences.
- Write the three line answer above and keep it in your questionnaire answer library.
- Date it. Review it whenever the toolchain or base image changes, since the status can change.
- Make sure security, engineering and sales give the same answer.
This is general guidance on wording, not legal advice. If a contract commits you to a specific build practice, have the people who handle contracts review the language.
Where Safeguard fits
Safeguard can generate SBOMs and evidence of dependency scanning that you can attach to a build related questionnaire answer. A free scan is at gold.safeguard.sh/scan.
Quick check
Is it fine to answer "partially"?
Yes, with specifics. Name what is pinned, what is recorded and what has been verified.
Should we offer to demonstrate a rebuild?
If you can do it reliably. Practice it internally first.
Sources
Last reviewed: 19 October 2026.
