Inspect the image with docker buildx imagetools inspect and look for attestation manifests in the index. If they exist, ask for the provenance and SBOM fields. If nothing comes back, the publisher did not attach them in that form, and you should rely on your own scan and SBOM instead.
What attestations are
Docker's build documentation describes attestations as metadata that BuildKit creates at build time and attaches to the final image. Two types are described. An SBOM lists software artifacts the image contains or used to build it. Provenance records how the image was built, and provenance in a minimal mode is added by default for builds made with the right setup.
They are attached to the image index as separate manifests, each referring to one platform image manifest. The data is in in-toto JSON format. Because attestations are manifests, you can inspect them in the registry without pulling the whole image.
How to look
The imagetools reference says attestation entries in the manifest list carry an annotation with the value attestation-manifest and show unknown for operating system and architecture. Start with the default view:
docker buildx imagetools inspect IMAGE
Then ask for the two kinds of data. The reference shows these forms:
docker buildx imagetools inspect IMAGE --format "{{json .Provenance}}"
docker buildx imagetools inspect IMAGE --format "{{json .SBOM}}"
Provenance comes back under an SLSA key with build type, materials and metadata. The SBOM comes back under an SPDX key. The reference notes that for multi-platform images you can select a platform with the index function, and that field names can differ by version, so check what your version accepts.
How to read what you find
- Provenance: Does it name a source repository and a build process you recognise? Does the source match the project's real repository? Treat it as a statement by the builder, not independent proof.
- SBOM: Does it list the packages you expect? An empty or tiny list on a large image suggests an incomplete record.
What attestations do not prove
A provenance record says how the publisher states it built the image. It does not say the build was free of compromise, and it does not say the content has no vulnerabilities. A valid record on a malicious build is possible if the builder itself is the problem. Use it as one input beside a scan, a publisher check and a pinned digest.
When there is no attestation
Many public images do not carry them. That is common and not a sign of bad intent. Your options are to pick an alternative that ships them, to ask the publisher, or to generate your own SBOM from the image you scan and store it with your records.
A simple policy
For images that reach production, require one of these: a publisher SBOM you have read, or your own SBOM generated at adoption. Record the digest, the date and where the data is kept.
Quick check
Do I have to pull the image to read its attestations?
No. Docker's docs say attestations are stored as manifests, so you can inspect them in a registry without pulling the whole image.
Is provenance proof an image is safe?
No. It records how the publisher says the image was built. You still need a scan.
Safeguard generates an SBOM and scans images for known vulnerabilities, so you have your own record when a publisher provides none. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
