A build log is text a human reads to understand what happened. Provenance is a signed, structured statement that names an artifact by digest and records who built it, from what inputs and on which platform. Logs help investigation. Provenance supports automated verification.
Side by side
| Build log | Provenance | |
|---|---|---|
| Format | Free text, varies by tool | Structured fields with a defined schema |
| Tied to an artifact | Usually by convention | By digest in the subject |
| Signed | Rarely | Yes at SLSA Build L2 and above |
| Machine checkable | Poorly | Yes, against expectations |
| Main use | Debugging and forensics | Trust decisions |
Why a log cannot do the job
Logs are written for people and change shape between tools and versions. A verifier cannot reliably ask a log whether the source repository was the official one. It would be parsing prose.
Provenance puts those answers in fields. The SLSA provenance predicate records a builder id, a build type, external parameters such as the repository and ref, and resolved dependencies. A verifier compares those values to what it expects.
Authenticity is the other gap. SLSA Build L2 requires that the build platform generate and sign the provenance, so a consumer can check the signature for integrity and identify the platform. An unsigned log can be edited after the fact by anyone with access.
How they work together
The provenance runDetails section has a metadata object with an invocationId, plus a byproducts list for artifacts such as logs. So provenance can point you to the log of that exact run. The signed record says what happened at a structured level, and the log gives the detail when you need to dig.
A good incident workflow looks like this:
- Verify the provenance on the suspect artifact.
- If a field looks wrong, take the invocation id.
- Pull the matching log from the build platform.
- Compare timestamps against the started and finished times in the provenance.
What neither one proves
SLSA's threat model is clear that provenance is a claim that an artifact was built, not that it was published to a given registry. And neither a log nor provenance says the source code was free of malicious changes. Producer intent is outside what SLSA controls can mitigate directly.
Where Safeguard fits
Safeguard's SBOM and dependency scanning, plus policy gates, add an automated check on vulnerabilities and rules that sits beside provenance and logs.
Quick check
Can I keep logs and skip provenance?
You can, but you lose automated, signed verification. Logs alone are weak evidence for buyers or auditors who need to check an artifact.
Does provenance include the log?
Not usually. It can reference the run through an invocation id and list logs as byproducts, but the signed statement itself is structured data.
Sources
Last reviewed: 19 October 2026.
