Before a public container image enters your builds, confirm its exact name and publisher, find its source, pin the digest, scan it, record an SBOM, check any signature or provenance, set runtime limits and name an owner. Ten steps, about thirty minutes for a new image, and much less for the next one from the same publisher.
The checklist
- Exact name. Write the full reference with registry host, namespace and repository. Short names depend on defaults, and the Podman docs warn they are exposed to namespace squatting.
- Publisher. Is it an official image, a verified publisher, a sponsored open source project, or a community account? Docker documents these groups, and treats community images as higher risk.
- Source. Find the Dockerfile or the repository. Official images link each tag to its Dockerfile. For others, look for a source label or a linked repository, and check it is the project's real one.
- Maintenance. Is the tag still supported, and when was it last updated? For official images, only tags in the library file are rebuilt.
- Digest. Resolve the tag to a digest and pin it. Kubernetes states tags can move and digests cannot.
- Scan. Scan the digest and read the findings in context, not just the count.
- SBOM. Keep one. Use the publisher's attestation if it exists, or generate your own.
- Signature and provenance. If the publisher signs, verify with the identity and issuer they documented. Read provenance if present. If neither exists, note it.
- Runtime limits. Decide the user, capabilities, filesystem mode and network the container needs, and write them down.
- Owner and review date. Name who answers for this image and when it is reviewed next.
Recording the decision
Put the answers in one record, in a file next to your build code or in your asset register. A short table works:
| Field | Example content |
|---|---|
| Reference | Full name and pinned digest |
| Why chosen | The need it meets and alternatives considered |
| Publisher type | Official, verified, sponsored or community |
| Scan date and result | Date, tool, summary |
| Exceptions | Item, reason, expiry |
| Owner | Person or team |
| Next review | Date |
Keeping intake fast
Intake that takes days teaches people to skip it. Make a template, pre-approve a small set of base images with an owner, and automate steps 5 to 7 in CI. Humans then spend their time on steps 2 to 4 and 8, where judgement matters.
After adoption
Adoption is the start. Advisories arrive after the day you scanned, so schedule re-scans, track digest changes and review the record when the owner or the publisher changes.
Try it yourself
Click through it at your own pace, or open it full screen. Try it on step 6: look at how findings are grouped by the package they come from.
Quick check
Which checklist steps can be automated?
Digest pinning, scanning and SBOM generation are good candidates. Publisher, source and maintenance checks still need a person.
Do I repeat the checklist for every new tag?
Not in full. Re-run the scan, SBOM and signature steps for the new digest, and review the rest on the owner's schedule.
Safeguard scans container images, generates an SBOM, and lets you set policies and gates so the checks run on every change. Start with a free scan at gold.safeguard.sh/scan.
Sources
- Docker Docs: Trusted content on Docker Hub
- docker-library/official-images on GitHub
- Kubernetes docs: Images
- Podman docs: podman pull
Last reviewed: 19 October 2026.
