A scanner that reads images from your registry needs two things: permission to list repositories and images, and permission to pull layers. It does not need to push, delete or change settings. Give it a read-only identity, scope it to the repositories you want scanned, and review it like any other service account.
Why this is a buyer question
Scanner trials often start with a request for registry credentials. Some teams hand over an administrator token to save time. That turns a vulnerability tool into a high-value target, because anyone who steals its credential can alter images, and a changed image is a supply chain incident. Ask early what the minimum permission set is and test it.
The minimum, using Amazon ECR as an example
AWS documents several managed policies for Amazon Elastic Container Registry:
| Managed policy | What AWS says it grants |
|---|---|
| AmazonEC2ContainerRegistryReadOnly | Read-only permissions, including listing repositories and images and pulling images with the Docker CLI |
| AmazonEC2ContainerRegistryPullOnly | Permission to pull images, and, if pull-through cache is enabled, to import an image from an upstream registry |
| AmazonEC2ContainerRegistryFullAccess | Administrative access to Amazon ECR resources |
For a scanner, the read-only policy matches the job: it can list and pull. The full access policy does not belong anywhere near a scanner.
AWS also notes that its managed policies might not grant least-privilege permissions for your specific use case, because they are available to all customers, and recommends reducing permissions further with customer managed policies. In practice that means restricting the identity to specific repositories rather than the whole registry, where your layout allows it.
Other registries have similar concepts under different names: a reader or pull role, a read-only token, or a scoped access key. Look for the one that lists and pulls, and nothing else.
A short checklist
- Create a dedicated identity for the scanner. Do not reuse a person's account or a CI deploy key.
- Grant list and pull only.
- Scope it to the repositories in your inventory.
- Use short-lived credentials where the registry supports them, and rotate any static token on a schedule.
- Log pulls by that identity and review them.
- Remove access at the end of a trial and confirm it is gone.
Watch for the pull-through cache side effect
The AWS description of the pull-only policy mentions that with pull-through cache enabled, a pull can import an image from an upstream registry. That means a scanner's pull might cause content to be fetched and stored in your registry. Know whether that matches what you want, and check the cost and policy implications before you grant it.
Questions for a vendor
- What is the minimum permission set, listed exactly?
- Can you work with a read-only role we create ourselves?
- Do you store registry credentials, and where?
- Can we use short-lived tokens or a role we assume?
- How do we revoke access, and how fast does it take effect?
If the answer to the first question is "admin", ask why.
A worked example: choosing a policy for a pilot
A team is piloting a scanner against 20 repositories in a registry that holds 200. They consider three options.
| Option | Access | Risk if the credential leaks |
|---|---|---|
| Administrator role | Everything, including delete and push | An attacker can replace images that production pulls |
| Managed read-only policy for the whole registry | List and pull on all repositories | Attacker can read every image, which may include internal code |
| Custom policy limited to the 20 repositories | List and pull on those repositories only | Attacker can read 20 images |
The third option takes an hour longer to set up and cuts the damage a leak can do by a large margin. For the pilot, the team uses it, and also sets the credential to expire when the pilot ends.
The AWS documentation lists the managed read-only policy as covering listing repositories and images and pulling images, and it advises narrowing managed policies to your own use case with customer managed policies, since managed ones are written for all customers.
Step by step: set up a scanner identity
- Create a new identity just for the scanner, named so its purpose is obvious.
- Attach a read-only policy, then narrow it to the repositories in scope.
- Prefer short-lived credentials or an assumed role over a static key.
- Store any secret in a secrets manager, not in a pipeline variable that many people can read.
- Turn on logging for the identity and check the first pulls match your expectations.
- Set a calendar reminder to review and rotate the credential.
- When the trial ends, remove the identity and confirm that a pull with it now fails.
Beyond the registry: what else a scanner may ask for
Registry access is only one of the requests. Ask about each of these.
| Request | Question to ask |
|---|---|
| Source repository access | Is read-only enough, and which repositories? |
| Cluster access | Is it read-only, and does it need secrets? |
| Ticketing integration | Which projects can it write to? |
| Chat integration | Which channels does it post to? |
Each should be the least that works, and each should be removable on the day the trial ends.
Pull-through cache note
AWS describes its pull-only policy as allowing pulls that import an image from an upstream registry when pull-through cache is enabled. If your registry works that way, a scanner's pull may cause content to be copied in. Decide whether that is acceptable before granting it.
Common mistakes
- Reusing the CI deploy credential for the scanner.
- Leaving the credential in place after a failed trial.
- Granting registry wide access when a short list would do.
- Never checking the registry logs for what the scanner pulled.
Try it yourself
Click through it at your own pace, or open it full screen.
See how monitoring depends on regular, read-only access to what you deploy, and consider which credential would sit behind it.
Where Safeguard fits
Safeguard offers scanning from the CLI and the desktop app, and a free web scan at gold.safeguard.sh/scan, so you can test an image without handing over registry credentials. For a pilot plan, see least privilege access for a scanner pilot.
Quick check
Does a scanner need push access?
No. Scanning reads images. Push access lets someone change what you deploy, so keep it off the scanner's identity.
Is a managed read-only policy enough?
It is a good start, but AWS itself suggests narrowing managed policies to your own use case, for example by limiting repositories.
Should the scanner credential be short-lived?
Yes where the registry supports it. A role the scanner assumes, or a token that expires in hours, limits the damage if it leaks.
Sources
Last reviewed: 19 October 2026.
