Build integrity is about whether the software you ship is the software you meant to ship. Eight terms cover most meetings: provenance, attestation, SBOM, digest, reproducible build, ephemeral build, transparency log and builder identity. Each one gets a single plain sentence below, plus the question it helps you ask.
Use this page as a briefing handout. It avoids jargon where it can and flags where a term is often misused.
The glossary
| Term | In one sentence | Question it helps you ask |
|---|---|---|
| Provenance | A record of how an artifact was built | Can we show how each release was made? |
| Attestation | A signed claim about an artifact | Who vouches for that record? |
| SBOM | A list of the components inside software | What is in this product? |
| Digest | A fingerprint of exact content | Is this the same file we tested? |
| Reproducible build | A build any party can repeat to get bit for bit identical output | Could someone else confirm our build? |
| Ephemeral build | A build run in a fresh environment, discarded afterward | Can one build contaminate the next? |
| Transparency log | A public, append-only record of signing events | Would we notice a signing we did not do? |
| Builder identity | The name of the platform that ran the build | Which systems do we trust to build? |
Where definitions come from
The reproducible build wording follows the Reproducible Builds project: given the same source code, build environment and build instructions, any party can recreate bit by bit identical copies of all specified artifacts. The ephemeral idea comes from SLSA Build L3, which requires a fresh environment for each build. The transparency log description follows the Sigstore overview, which calls its log an immutable, append-only ledger. Provenance, builder identity and digest usage follow the SLSA and in-toto specifications.
Three misunderstandings to correct early
"Signed means safe." A signature says who signed something. It does not say the content is free of flaws.
"Provenance means the code was reviewed." Provenance records how the build ran. Code review is a separate control on the source.
"Reproducible means secure." Reproducibility lets others check a build. It does not make the code safe, and SLSA does not require it.
How these fit together
Think of a delivery chain. The digest is the tracking number, provenance is the shipping record, the attestation is the signature on that record, and the builder identity is the depot that handled the package. The SBOM is the packing list. Reproducibility and a transparency log are independent ways to double check the depot.
Questions leadership can ask engineering
- For our last release, can we show the provenance and who signed it?
- Which builders do we trust, and what level do we assess each at?
- Are release builds run in fresh environments?
- Does the deploy step check provenance, or only that a signature exists?
- Where is our SBOM for this release, and when did we last scan it?
Good answers are short and specific. Vague answers tell you where to dig.
Using the glossary
Share it before a customer security review, so the people in the room use the same words. Safeguard can supply SBOM and dependency scan output for the component side, and the free scan at https://gold.safeguard.sh/scan is a no cost way to see a sample.
Quick check
Which term answers what is inside our software?
The SBOM. Provenance describes how it was built.
Do all eight terms need to be in place?
No. They describe different controls. Start with the ones that match your biggest risk.
Sources
- Reproducible Builds definition
- Sigstore overview
- SLSA v1.1 build requirements (page marked retired, v1.2 is current)
- in-toto attestation Statement spec
Last reviewed: 19 October 2026.
