Mostly a speed and availability measure. A pull-through cache keeps copies of images you pull, so repeat pulls are faster and survive an upstream outage. It helps security only when you add logging, authentication and scanning around it. On its own it will serve a bad image as readily as a good one.
What a cache really does
Docker's documentation describes running the registry as a pull-through cache, with a proxy section pointing at the upstream. When a client asks for an image, the cache fetches it from upstream and stores it. Later requests come from the store. The docs add that removed content is fetched from upstream again on the next request.
Nothing in that flow judges the image. The cache is a copy machine.
Where it helps security indirectly
- One egress point. Build machines talk to your cache, so you can restrict outbound traffic to a single host and watch it.
- A record of what was pulled. Access logs show which images your teams adopted and when, which helps when you need to find everything that pulled a given image.
- Fewer anonymous pulls. Using one authenticated upstream account from the cache can reduce rate-limit surprises, within the registry's fair use rules.
- Time. If an upstream image is pulled from the registry, your copy may keep working while you decide what to do. That is a convenience and also a risk, because a pulled image may have been removed for a reason.
Where it can hurt
The Docker docs note that the optional username and password under proxy let the cache reach private Docker Hub images, and that anyone using the mirror can then reach those private resources. An unauthenticated cache with upstream credentials is a way to expose private content.
A cache can also hold a stale copy of a tag after upstream has moved it. Know how long your cache keeps entries, and do not assume a cached tag equals the current upstream tag.
What to put around it
| Need | Add |
|---|---|
| Know what is inside | Scan images when they first enter, and again on a schedule |
| Control who can pull | Authentication on the cache itself |
| Know what changed | Pin digests in build files and update them deliberately |
| Stop unknown sources | Network rules and CI checks that reject other hosts |
| Find affected workloads later | An SBOM per image and logs of pulls |
A simple decision
Use a cache if you want steady builds and one place to log. Do not describe it to auditors as a vetting step unless you also run a scan and an approval step in front of it. A cache that nobody scans is a faster route for the same risk.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a finding appears on something you already adopted, which is the situation a cache leaves you in when an advisory lands after the pull.
Quick check
Does a cache scan the images it stores?
Not by itself. The Docker registry in cache mode stores and serves content. Add scanning around it.
Should the cache require a login?
Yes, especially if it holds upstream credentials. The Docker docs warn that anyone using the mirror can reach private resources those credentials allow.
Safeguard scans container images, keeps an SBOM, and continues to check them as new advisories appear, whether they came through a cache or not. Try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
