Official images are curated and reviewed, but they are not free of vulnerabilities, not fixed in place and not maintained forever. Verified badges describe publishers, and signing and provenance prove narrower things than people assume. Here are five myths, each checked against the documentation.
Myth 1: official means no vulnerabilities
Fact. Docker's documentation says official images typically have few or no packages containing CVEs. That is a description of upkeep, not a promise about a particular build. New advisories can match packages in a build that was clean last week. Scan the digest you use.
Myth 2: if the tag worked yesterday it is the same today
Fact. Kubernetes documents that tags can be moved to point to different images. For official images that is by design: tags listed in the library file are rebuilt when the file or the base image updates. Pin the digest if you need repeatability.
Myth 3: an image that still pulls is still maintained
Fact. The official-images repository says only tags in the library file are rebuilt, and tags removed from it stay on Docker Hub but are no longer maintained. Pulling works either way. Check the supported tags list.
Myth 4: a verified badge means the image was audited
Fact. Docker describes Verified Publisher as images from commercial publishers Docker has verified, and Sponsored Open Source as projects verified as trusted and active. The documentation page does not list criteria or describe an image audit. Read the badge as being about the publisher.
Myth 5: a valid signature means the image is safe
Fact. A signature shows a named identity signed a particular digest. The Sigstore verification flow checks the digest matches and, for keyless signing, the identity and issuer you specify. It does not check for vulnerabilities, and it does not prove the build was clean before signing.
The pattern behind the myths
Each myth treats a label as a verdict. The label tells you something real: who publishes, whether a recipe was reviewed, who signed. What it cannot tell you is the current state of the contents. That needs a scan and a record, repeated over time.
| Check | Answers | Does not answer |
|---|---|---|
| Badge or namespace | Who publishes | What is inside now |
| Review of the recipe | How it is built and maintained | Whether today's packages have advisories |
| Digest pin | Whether content changed | Whether content is safe |
| Signature | Who signed this digest | Whether the build was compromised |
| Scan and SBOM | What is inside, what is known | Whether the builder is honest |
What to do with this
Combine the rows. Choose an official or verified source where one exists, pin the digest, verify a signature where available, scan, keep an SBOM, and re-scan on a schedule. No single row covers the others.
Quick check
Should I stop using official images because they can have findings?
No. They are a good starting point. Treat them like any other component: scan, pin and track.
How do I know a tag is still maintained?
Check that it is listed in the image's supported tags and in the official-images library file.
Safeguard dependency scanning and SBOM give you the per-digest record, and policies and gates keep the checks running on every change. A free scan is at gold.safeguard.sh/scan.
Sources
- Docker Docs: Trusted content on Docker Hub
- docker-library/official-images on GitHub
- Kubernetes docs: Images
- Sigstore docs: Verifying signatures
Last reviewed: 19 October 2026.
