Authenticate every pull, scan by digest so you never fetch the same image twice, route pulls through an internal pull-through cache, and reuse layer analysis. Public registries apply pull limits per account or address, and a scanner fleet behind one egress IP can hit them quickly.
Why scanners hit limits
Scanning an image means pulling it, or at least its manifest and layers. A platform scanning thousands of images, plus rescans after advisory updates, generates a high pull volume from a small number of source addresses. That is exactly the pattern registries limit.
Docker's documentation is a concrete example. It states that unauthenticated users get 100 pulls per six hours per IPv4 address or IPv6 /64 subnet, authenticated personal accounts get 200 per six hours, and paid tiers are described as unlimited, subject to fair use. It also notes that a pull counts a version check as well as a download, and it shows rate limit headers you can read to see how many pulls remain. Other registries have their own rules, so check yours.
Tactics, from cheapest to biggest
| Tactic | Effect |
|---|---|
| Authenticate all pulls | Moves you from a shared per-address budget to an account budget |
| Scan by digest | Skip images whose digest you already analysed |
| Reuse layer analysis | Most images share base layers, so cache by layer digest |
| Pull-through cache | One upstream pull, many internal pulls |
| Mirror the base images you rely on | Removes upstream dependence for the most common layers |
| Spread scheduled scans over time | Avoids a burst at the top of the hour |
Steps
- Inventory which registries your scanners pull from and what limit each applies.
- Add credentials for each, using a service account with read access only.
- Read the rate limit headers where available and feed them into your queue, so workers slow down before they are blocked.
- Stand up a pull-through cache inside your network and point scanners at it. Our post on pull-through cache settings covers TTL, credentials and storage.
- Before pulling, check whether you already hold analysis for that digest, and skip the pull if so.
- When a limit error appears, back off and retry later instead of retrying immediately.
Trade-offs of a cache
A pull-through cache makes you dependent on it and can serve stale tags. Scan by digest to avoid that confusion, and remember that a cache does not prove an image is trustworthy; it only saves bandwidth. Restrict who can push to the cache and monitor its storage.
When the image is already in your own registry
Scanning images from your own registry avoids public limits entirely, but you still pay in egress and time. Ask whether you can scan at build time, when the layers are already local, and store the inventory, rather than pulling again later.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how the report breaks down by layer and package, which is what you can reuse.
Safeguard scans container images and can also scan at build time. You can try the free scan at https://gold.safeguard.sh/scan.
Quick check
Does authenticating really help?
For registries with different limits for anonymous and signed-in users, yes. Docker's published limits are higher for authenticated accounts than for anonymous pulls.
Is a pull-through cache a security control?
No. It reduces bandwidth and upstream dependence. It does not verify that an image is safe.
Sources
Last reviewed: 19 October 2026.
