A signature says who vouched for an image digest. Build provenance says how and where the image was built. An SBOM says what software is inside. They answer different questions, and each can be attached to the same image. Together they let you ask a build to show its work.
The three questions
- Who vouched for this? A signature.
- How was it made? Provenance.
- What is in it? An SBOM.
Each can be turned into an attestation, a signed statement about an artifact. The statement names the artifact by digest and carries a claim, which is then signed so its source can be checked.
Provenance in detail
The SLSA specification describes build provenance as an attestation that a particular build platform produced a set of software artifacts. Key fields include:
- Builder id. The identity of the build platform. The spec says consumers must accept only specific signer and builder pairs.
- Build type. The template that defines how the build runs.
- External parameters. Inputs under user control. The spec says these are untrusted and must be verified downstream.
- Resolved dependencies. What the build fetched. The spec says completeness is best effort at the lower levels.
- Subject. The output artifacts, identified by digest.
The SLSA v1.0 page is marked retired, with a newer version current, so check the current spec for exact field rules.
The point is that provenance is only as good as trust in the builder. A build platform you trust, plus a verified identity, gives a statement you can act on. Self-reported provenance from an unknown builder tells you little.
SBOM attestation
An SBOM lists software components in the image or used to build it. BuildKit can create both kinds. The Docker documentation says attestations are attached to the final image as metadata, with SBOM and provenance as the two types. SBOM generation is opt-in, while a minimal provenance level is added by default. They are stored in the image index in in-toto JSON format, each referring to one platform image manifest.
An SBOM is a snapshot. It tells you what was in the image at build time. When a new vulnerability is published next month, the SBOM lets you search for affected images without re-pulling each one.
How they combine
A policy could require all of these before deploy:
- A valid signature from your build identity on the digest.
- Provenance showing the build ran on your trusted builder from your repository.
- An SBOM present, with no components that break a rule.
Each check covers a gap in the others. A signature without provenance does not say how it was built. Provenance without a signature can be forged in transit. An SBOM without either may not match the image.
Limits to keep in mind
- None of them says the software is free of vulnerabilities.
- SBOMs can miss components, such as statically compiled code with no metadata.
- Provenance depends on the builder not being compromised.
- Verifying requires tooling and a policy, not only the files.
For the signature side on its own, see what a signature proves.
See it on an image
Click through it at your own pace, or open it full screen.
Safeguard's SBOM and dependency scanning produces an inventory you can query, and policies and gates can act on it. Try a free scan.
Quick check
Do I need all three?
Not on day one. An SBOM is often the easiest first step, then signing, then provenance once you have a trusted build platform.
Is an attestation the same as a signature?
An attestation is a statement about an artifact, usually signed. The signature is what lets you check who made the statement.
Sources
Last reviewed: 19 October 2026.
