To vet a Docker Hub image, check who publishes it and whether it belongs to a curated program, pull by digest instead of tag, inspect its attestations, scan its contents, and run it first with no privileges and no secrets. A name that looks familiar is not evidence.
Who publishes the image?
Docker Hub marks several kinds of trusted content. Docker's documentation lists Docker Official Images, Docker Hardened Images, Verified Publisher images and Docker-Sponsored Open Source Software images. Official Images are a curated set of repositories with clear documentation, a focus on best practices and regular updates.
Anything outside those programs is a community image. That does not make it bad, but it moves the burden of proof to you. Look at the namespace, how long it has existed, whether a source repository is linked, and whether the Dockerfile in that repository matches what the image claims.
A constructed example: you search for a Redis image and see redis-fast with a large pull count next to the official redis. Pull counts can be inflated and say nothing about contents. Use the official one unless you can name a reason.
Why pull by digest?
Tags are labels that publishers can move. Docker's pull documentation describes digests as the immutable identifier: pulling by digest lets you pin an image to exactly one version and guarantees it is always the same. Docker prints the digest after a pull.
docker pull ubuntu:24.04
# note the line starting with Digest: sha256:
docker pull ubuntu@sha256:<digest-you-recorded>
Record the digest you vetted in your Dockerfile or deployment manifest. When you want an update, you repeat the vetting for the new digest.
What can you learn from attestations?
Images built with BuildKit can carry provenance and SBOM attestations. Docker's attestation docs show how to read them with docker buildx imagetools inspect, using the .Provenance attribute for SLSA data. Check the source repository and revision, and whether the base images are themselves pinned.
Absence tells you something too. A missing attestation does not mean malicious, but it means you cannot see how the image was built and must rely on scanning and sandboxing instead.
What should you scan?
Scan the image layers for known vulnerable packages and for embedded secrets. Compare the package list with what the application needs: a web proxy image that includes a compiler and a package manager has more attack surface than one that does not. Check which user the process runs as, and whether the image expects to run privileged.
Run the scan on the exact digest you intend to deploy, not on a tag you pulled last week. Safeguard's container image scanning and SBOM tooling can do this check, and its policies can block images that fail your rules at the pull request or pipeline stage.
How do you run it safely the first time?
Use a throwaway host or VM. Run the container without --privileged, without mounting the Docker socket or your home directory, without cloud credentials in the environment, and with outbound network blocked unless you need to observe it. A container that tries to reach unexpected hosts on first start deserves a closer look.
What to do
- Prefer Official, Hardened, Verified Publisher or Sponsored OSS images where one exists.
- For community images, check namespace history and the linked source repository.
- Pull once, record the digest, and reference the digest from then on.
- Inspect provenance and SBOM attestations when present.
- Scan the exact digest for vulnerabilities and secrets.
- Test run unprivileged, with no secrets and restricted network.
- Put the digest in version control so changes are reviewed.
Quick check
Is a high pull count a sign an image is safe?
No. It shows popularity, not trustworthiness. Use publisher status, source linkage, attestations and scanning.
Does pinning by digest stop me getting security updates?
It stops automatic updates. Schedule a regular review where you vet and record a new digest, and use automation to open the pull request.
Sources
- Trusted content on Docker Hub, Docker Docs, fetched 18 October 2026
- docker image pull, pulling by digest, Docker Docs, fetched 18 October 2026
- SLSA provenance attestations, Docker Docs, fetched 18 October 2026
Last reviewed: 18 October 2026.
