resolvedDependencies is the field in SLSA provenance that lists artifacts fetched during a build. The spec says completeness is best effort, especially at Build L3. Use it as a useful lead, not as a full inventory, and cross check it with an SBOM and a dependency scan.
Readers sometimes treat provenance as a complete parts list. The specification does not make that promise.
What the field is
In the v1.1 provenance format, buildDefinition has a resolvedDependencies entry for artifacts the build fetched. Each item can carry a URI and a digest. The format records what the platform observed and could describe.
The same page says that completeness is best effort. That is deliberate. A build can fetch from places the platform cannot fully see, such as a script that downloads a tool at run time.
What you can reasonably use it for
- A quick check that expected inputs, such as a base image, appear with the digest you pinned.
- A lead when investigating a bad component: did this build touch it?
- Input to deeper verification. The verification page says you may check
resolvedDependenciesas available and as far as you want, and that SLSA v1.0 does not require them to be complete.
What it cannot promise
| Expectation | Reality from the spec |
|---|---|
| Lists every file the build touched | Completeness is best effort |
| Lets you verify every transitive dependency | Recursive checks need a trimming heuristic, because some are L0 |
| Replaces an SBOM | No, it describes build inputs, not shipped components |
Notice the last row. An SBOM answers "what is in this software." Provenance answers "how was it made." Dependencies fetched during a build and components shipped inside the artifact overlap but are not the same set. Build tools, for instance, are fetched but never ship.
A working method
- Read
resolvedDependenciesfor the items that matter most, such as base images and the toolchain. - Confirm each has a digest, and compare with your pinned values.
- Generate an SBOM for the shipped artifact separately.
- Compare the two lists and look at differences. A component in the SBOM but absent from provenance means the provenance is incomplete, which is allowed, but you should know.
- Scan the SBOM for known vulnerabilities and license problems.
When you find a gap, decide whether to close it by pinning that input or accept it with a note.
Recursive verification
The verification page describes an optional step: check dependencies recursively. It warns that some transitive dependencies are at L0, so you need an exception mechanism. It also mentions that a verification summary attestation can record the results of prior verifications, which makes repeat checks cheaper. Start small. Verify direct inputs you control, then widen.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how direct and transitive components appear in one inventory, then imagine comparing that list with a provenance record.
Safeguard generates SBOMs and scans dependencies, and the free scan at https://gold.safeguard.sh/scan gives you a first inventory.
Quick check
Is resolvedDependencies required to be complete?
No. SLSA says completeness is best effort.
Can provenance replace my SBOM?
No. Provenance records how the build ran. An SBOM lists what the artifact contains.
Sources
- SLSA v1.1 provenance (page marked retired, v1.2 is current)
- SLSA v1.1 verifying artifacts
Last reviewed: 19 October 2026.
