Description
Utho Container Registry stores Docker/OCI images in repositories, each with a visibility of Public or Private. A Public repository lets anyone pull its images without authentication; a Private repository requires the registry credentials (retrieved via View Credentials) to pull or push.
This control checks that repositories holding internal images are Private and that none have been flipped to Public. Newly created Utho repositories default to Private, so the risk is a repository that was deliberately or accidentally made Public.
If specific images are genuinely meant to be shared, they should live in a dedicated public repository, with all internal images kept Private.
Repositories set to Public that expose internal images to anonymous pulls
Proprietary source, binaries, or secrets/config baked into image layers being downloadable
Push/pull workflows relying on anonymous access instead of registry credentials
Rationale
A public container registry lets anyone pull your images, exposing proprietary source, binaries, and any secrets or configuration baked into the layers, and hands an attacker a blueprint of your stack — versions, dependencies, internal service names — to plan further attacks.
Keeping repositories Private makes possession of the registry credentials a precondition for pulling images, which is the baseline expectation for anything containing internal code.
Image layers frequently contain embedded secrets, config, and proprietary code
Public images reveal exact component versions an attacker can target
Anonymous pull removes any audit trail of who obtained an image
Impact
Pros:
Internal images can only be pulled with valid registry credentials
Removes anonymous exposure of code, binaries, and baked-in secrets
Genuinely public images are isolated to a dedicated repository
Cons:
Every push/pull workflow must authenticate with the registry credentials
Any consumer that relied on anonymous public pulls must be updated
Sharing an image publicly now requires publishing it to a separate public repository
Default Value
By default, all newly created Utho Container Registry repositories are set to Private; only repositories explicitly switched to Public are at risk.
Pre-Requisite
Utho console access to the account/team that owns the registry
The registry credentials (from View Credentials) so push/pull workflows can authenticate once repositories are Private
Awareness of which images (if any) are genuinely intended to be public
Remediation
Test Plan
Using the Utho Console:
Sign in to the Utho console and open Container Registry.
Review the repository list and read each repository's visibility (Public or Private).
As a live check, attempt an unauthenticated docker pull of an image and confirm it is refused.
Repeat for every repository.
Pass: every repository holding internal images is Private and an unauthenticated pull returns an authentication-required error.
Fail: any internal repository is marked Public, or an unauthenticated pull succeeds.
Using the Utho API:
Repository visibility is read in the Utho console; the exact api.utho.com/v2 registry path that returns a repository's visibility could not be confirmed against Utho's published API reference, so no read command is given — verify at utho.com/api-docs before scripting.
Implementation Steps
Using the Utho Console:
Open Container Registry in the Utho console and select the repository.
In the repository's visibility settings, set it to Private (use the Make Private button if it is currently Public).
Repeat for every repository and confirm none remain Public.
Use View Credentials to retrieve the registry username/password and update all push/pull workflows to authenticate with those credentials instead of relying on anonymous pulls.
If specific images must be shared, publish only those to a dedicated separate public repository and keep all internal images Private.
Using the Utho API:
This fix is performed in the Utho console (Container Registry → select repository → Make Private). Utho's Developer API may cover registry management, but the exact endpoint to change repository visibility could not be confirmed against the published spec, so no command is provided.
Backout Plan:
If a legitimate consumer breaks after a repository is made Private, do not simply re-open it — give the consumer the registry credentials (View Credentials) and update its docker login / pull config.
If an image genuinely needs to be public, move that specific image to a dedicated public repository rather than making the internal repository Public.
Only with documented, reviewed approval should a repository be returned to Public; record who approved it and revert once the authenticated path is in place.