Source integrity means every change to the code reflects what the producer intended. Build integrity means the shipped artifact was built from that unmodified source, by the intended recipe, and not altered afterward. A supply chain attack can break either one, so a defense for one does not cover the other.
Definitions from SLSA
The SLSA project frames supply chain integrity as protection against tampering or unauthorized modification at any stage of the software lifecycle, and splits it in two.
Source integrity: ensure all changes to the source code reflect the intent of the software producer. SLSA notes that intent is hard to define, so it approximates it as approval from two authorized representatives.
Build integrity: ensure the package is built from the correct, unmodified sources and dependencies according to the build recipe the producer defined, and that artifacts are not modified as they pass between stages.
Where each one breaks
| Break | Example from the SLSA overview | Which integrity |
|---|---|---|
| Unauthorized change submitted | A contractor with access pushed a malicious commit | Source |
| Source repository compromised | An attacker injected commits on a self-hosted git server | Source |
| Build from modified source | Build infrastructure used files that did not match source control | Build |
| Build process compromised | An implant injected behavior during each build | Build |
| Modified package uploaded | Leaked credentials used to upload a malicious artifact | Build |
The overview names real cases for each row. The point for a reader is the pattern: reading the repository would catch the first two, and only checking the build would catch the rest.
Why you need both
Imagine perfect code review. Every commit is approved by two people. An attacker who compromises the build server can still ship something different from what was reviewed. Now imagine a perfectly isolated build. If a malicious commit gets through review, the build faithfully packages it.
Controls for each side
Source side:
- Protected branches with required reviews and status checks.
- Code owners for sensitive files such as workflow and release configuration.
- Strong account security for everyone with write access.
Build side:
- Builds in clean, short-lived environments from a defined recipe.
- Short-lived credentials for publishing.
- Provenance that records where and how the artifact was built, which consumers can compare to expectations.
What this means for buyers
When a supplier says they have secure builds, ask which half they mean. A good answer covers how changes get approved and how builds are isolated, and says what evidence exists. Do not accept a single yes.
Where Safeguard fits
Safeguard's policies and gates operate at the pull request, which supports the source half, and its SBOM and evidence automation help record what shipped. It does not run your build infrastructure.
Quick check
Does a signed commit prove source integrity?
It shows who made the commit. It does not show the change was intended or reviewed.
Is provenance the same as build integrity?
Provenance is evidence about a build. Build integrity is the property of the build itself.
Sources
Last reviewed: 19 October 2026.
