Extract the registry hostname from every image reference in your Dockerfiles, Kubernetes manifests, compose files and CI configs, then compare the hosts with your approved registries. References with no hostname are the main trap, because Kubernetes assumes they mean the Docker public registry unless the runtime is configured otherwise.
How an image name hides its source
Kubernetes documents the structure. An image name can include a registry hostname, and possibly a port, such as registry.example:10443/imagename. If you do not specify a hostname, Kubernetes assumes the Docker public registry, though you can change that default in the container runtime configuration. If you do not specify a tag, it assumes the tag latest.
So the image busybox is equivalent to docker.io/library/busybox:latest. A reviewer who reads only the short form will not see where it comes from.
Step 1: collect references
Search for image references in the places they live:
git grep -nE '^\s*FROM\s' -- '*Dockerfile*'
git grep -nE '^\s*image:\s' -- '*.yaml' '*.yml'
git grep -nE 'docker\s+(pull|run)\s' -- '*.sh' '*.yml' '*.md'
Do not forget Helm values files, CI job definitions and build scripts, which often hold image names in variables.
Step 2: normalize and extract the host
A common convention is that a first path segment containing a dot or a colon is a registry host, and anything else is a public registry image. Confirm how your own tooling parses names before you rely on it. A short script that prints host and image per line is enough. Keep the repo and file path on each line.
Step 3: compare with your approved registries
| Result | Meaning |
|---|---|
| Host is your internal registry | Expected |
| Host is on your approved external list | Record the owner |
| No host (defaults to public) | Decide whether public pulls are allowed at all |
| Unknown host | Investigate who published it |
Count unique images per host. The long tail is where surprises are.
Step 4: pin by digest
Tags can move. Kubernetes states that digests are hashes of the image content and are immutable, while tags can be moved to point to a different image. When a reference includes both a tag and a digest, only the digest is used for pulling. Pinning by digest means the image you reviewed is the image you run.
Step 5: enforce at the registry and the cluster
Searching finds what exists. To keep it from coming back, make your internal registry the only place the build and the cluster pull from, with an approved list of upstream sources mirrored into it. For a catalog approach, see approved base image catalog: how to run one.
Try it yourself
Open the container image scan demo. Look at how an image breaks down into layers and packages, and which of those rows carry findings.
Click through it at your own pace, or open it full screen.
Quick check
Is a public registry image always unapproved?
No. Many teams approve specific public images. The point is that the approval is written down, with a pinned digest.
Can the default registry be changed?
Kubernetes says you can set a default image registry in the container runtime configuration. Check that setting in your clusters, because it changes what a short name means.
Safeguard offers container image scanning and SBOM and dependency scanning, with a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
