Verifying the image

The published image carries two machine-generated attestations alongside it in the registry: a provenance record of how it was built, and — from 2.0.5 on — an SBOM listing what is inside it. Both can be read without pulling the image, and both are there so that questions about the container can be answered by the person asking rather than by us.

Read what this does not prove before relying on any of it. It is a shorter list than the commands below might suggest.

What is inside it

The SBOM is SPDX, generated during the build by Syft, one document per platform.

docker buildx imagetools inspect ghcr.io/srmadscience/mcpdbwizard:<tag> \
    --format '{{ json .SBOM }}' \
  | jq -r '.["linux/amd64"].SPDX.packages[] | "\(.name) \(.versionInfo)"' \
  | sort

The question this exists for is the one that arrives on the morning of the next Log4Shell — is the bad version in your image? — and it is a search, not a support ticket:

docker buildx imagetools inspect ghcr.io/srmadscience/mcpdbwizard:<tag> \
    --format '{{ json .SBOM }}' \
  | jq -r '.["linux/amd64"].SPDX.packages[]
           | select(.name | test("openssl"; "i"))
           | "\(.name) \(.versionInfo)"'

Swap linux/amd64 for linux/arm64 for the other architecture. They are built from the same source, but they are different operating system builds, so the package versions are worth checking separately rather than assumed identical.

How it was built

The provenance record names the builder, the Dockerfile, the build steps, and — the part worth reading — the exact base images that were resolved:

docker buildx imagetools inspect ghcr.io/srmadscience/mcpdbwizard:<tag> \
    --format '{{ json .Provenance }}' \
  | jq -r '.["linux/amd64"].SLSA.buildDefinition.resolvedDependencies[]?
           | "\(.uri)  \(.digest.sha256)"'

The base images are pinned by digest in the Dockerfile, so what the provenance reports is what was chosen rather than whatever the tag happened to point at that morning. Without the pin the record is still accurate and much less useful: it would faithfully tell you which operating system you got by accident.

The labels

Separately from the attestations, the image describes itself. These need a pull, since they live in the image config rather than the manifest:

docker inspect --format '{{json .Config.Labels}}' ghcr.io/srmadscience/mcpdbwizard:<tag>

org.opencontainers.image.revision is the source commit and version is the release. The four that vary per build are also published as manifest annotations, so a registry UI can show them without pulling either.

What this does not prove

Being straight about the limits, because “provenance” and “SBOM” are words that invite more confidence than the artefacts here have earned.


The image is not signed.	There is no cosign or Sigstore signature. An attestation records what the build tool observed; it says nothing about who published it, and anyone with write access to the registry can push an image with attestations of their own. If you need to verify the publisher, this does not do that.
The provenance is self-attested.	It is produced on a developer machine, by the same party that publishes the image. In SLSA terms that is the bottom of the ladder: it is a record, not an independent one, and it carries exactly as much weight as your trust in us already does. A hosted build service would make it evidence rather than testimony.
An SBOM is a scanner’s opinion.	Syft reports what it recognises in the filesystem. It is good at operating system packages and reasonable at JARs, but a component it does not recognise is silently absent rather than reported as unknown. Absence from the list is weak evidence of absence from the image.
Neither makes the container safer.	Nothing here removes a vulnerability. It makes the contents checkable, which is what turns a disclosure into a search you can run in a minute.

What it is genuinely good for: answering “what is in it”, “what was it built from”, and “is this the same image I checked last week” — quickly, yourself, without pulling gigabytes or asking anyone.

Which images have what

Provenance is not new. BuildKit has attached it by default for as long as these images have been published, so every release back to 2.0.0 has a provenance record and every one of them reports two attestation manifests. Counting those manifests therefore tells you nothing about which image you are holding — it answers two on all of them.

What changed at 2.0.5 is the SBOM, which no earlier image carries, and the digest-pinned base images, which are what make the provenance worth reading rather than merely present. So the SBOM is the thing to test for:

docker buildx imagetools inspect ghcr.io/srmadscience/mcpdbwizard:<tag> --format '{{ json .SBOM }}'

{} on 2.0.4 and earlier; a document per platform from 2.0.5 on. An empty result on an older tag is that, rather than a broken command.

	Provenance	SBOM	Bases pinned by digest
2.0.0 – 2.0.4	yes	no	no
2.0.5 and later	yes	yes	yes

Note that 2.0.1 and 2.0.2 were never published as images at all; image publishing became routine at 2.0.3.

jq is not required for any of this; it only makes the output readable. docker buildx is, and it ships with Docker Desktop.