Four groups of fields help most in an incident: the subject digest to find the exact artifact, builder.id and metadata to find the exact run, externalParameters to see what was requested, and internalParameters and byproducts for platform detail and logs. Know where they are before you need them.
When a bad release is suspected, the first questions are always the same. Which build made it, from what, when, and who triggered it? Provenance can answer if you recorded it well.
Field map
| Question | Field to read |
|---|---|
| Is this the artifact in question? | Subject digest |
| Which platform built it? | builder.id |
| Which run? | metadata invocationId |
| When did it run? | metadata startedOn and finishedOn |
| What did the caller ask for? | externalParameters |
| How was the platform set up? | internalParameters |
| What logs or configs exist? | byproducts |
| What was fetched? | resolvedDependencies |
The SLSA provenance page describes these. It says internalParameters are trusted values set by the platform and help with debugging, incident response and sometimes reproducing a build. It says byproducts are extra artifacts such as logs or a digest of the evaluated configuration that may help debugging or incident response, and that they are not the build output and should not include every intermediate file.
A response sequence
- Match the digest. Confirm that the file you hold is the subject of a provenance record. If no record matches, treat the artifact's origin as unknown.
- Read the builder and run. Note builder.id and invocationId, then find the matching run in your CI system.
- Check the times. Compare startedOn and finishedOn with the timeline of the suspected event. A build that ran at an odd hour deserves attention.
- Read externalParameters. Look for an unexpected repository, branch or input value. This is where tampered requests show up.
- Pull logs. If byproducts reference logs or a configuration digest, retrieve them before retention policies delete them.
- List affected artifacts. Search your stored provenance for the same builder, parameters or dependency, and list every artifact that shares it.
What to store in advance
- Provenance for every release, named by artifact digest and kept for as long as the release is supported.
- A mapping from invocationId to the CI run page and its logs, with log retention long enough to cover your support window.
- Copies of the provenance outside the CI system, so a platform compromise cannot erase it.
Retention is a decision, not a default. Ask your CI provider how long logs live and set up export where needed.
Limits
Provenance is a record the platform produced. If the platform was compromised, treat its records as suspect and lean on other evidence such as registry logs and source control history. The spec also says resolvedDependencies completeness is best effort, so a missing entry is not proof that the build did not fetch something.
After the incident
Write down which fields helped and which were missing, then change what you record. Teams often discover they wished for a field they did not capture.
Safeguard can help you find which of your products contain an affected component through SBOM and dependency scanning, and the free scan at https://gold.safeguard.sh/scan is a way to start building that inventory.
Quick check
What is the first thing to match in an incident?
The artifact digest against the subject of a provenance record.
Are byproducts part of the build output?
No. The spec says they are extra artifacts, such as logs, and not the build output.
Sources
- SLSA v1.1 provenance (page marked retired, v1.2 is current)
Last reviewed: 19 October 2026.
