Test the registry endpoints directly with anonymous Docker or OCI pull requests and verify that manifests and blobs are denied. If the UI says private but the API still serves content, the control is cosmetic rather than real. Effective privacy must hold at the protocol layer, not just in the console.
Why This Matters for Security Teams
A private registry is only private if unauthenticated clients are denied at the protocol boundary. A private label in a console, repository metadata, or access banner can be misleading if the registry still serves manifests, layers, or tags over anonymous API calls. That gap turns “private” into a UI property, not an access control property.
This matters because registries often sit inside CI/CD paths, build automation, and software supply chains. If anonymous pulls succeed, the registry can leak proprietary images, embedded credentials, signed artifacts, or dependency history. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls treats access enforcement as a control outcome, not a documentation claim. NHIMG reporting on Massive Docker Hub Secrets Leak shows why container exposure is rarely theoretical once image access is misconfigured.
Security teams also miss that registry privacy is often checked only during setup, then assumed stable even as permissions, mirror settings, or automation tokens change over time. In practice, many teams discover a registry is not truly private only after images have already been indexed, copied, or pulled by something they never intended to trust.
How It Works in Practice
The right test is simple: attempt anonymous access to the registry endpoints the same way a client would. A private registry should deny unauthenticated requests for the catalog, manifests, and blobs, not just hide them from the user interface. For OCI-compliant systems, that means testing the actual registry API, not only the vendor console or repository listing.
Practitioners usually validate privacy in layers:
- Try an anonymous docker pull or OCI client request against a known image reference.
- Request the manifest directly and confirm the registry returns an authorization error rather than image metadata.
- Request a blob URL and verify it cannot be fetched without a valid bearer token or session.
- Repeat from outside the trusted network, because some registries only look private internally.
That approach aligns with the registry security logic described in the OCI Distribution specification and with NIST’s emphasis on explicit access enforcement. It also helps distinguish true protocol-layer protection from cosmetic restrictions such as disabled UI buttons, obscured repository names, or portal-only permissions. NHIMG’s analysis of Docker Hub Auth Secrets in Container Images is a reminder that if a registry is reachable, whatever is stored inside it can become reachable too.
For operational validation, teams should check token scope, anonymous fallback behavior, and whether reverse proxies or caching layers can bypass registry authentication. These controls tend to break down when a mirror, CDN, or legacy compatibility endpoint serves content outside the intended auth path because the front-end policy and back-end storage policy have drifted apart.
Common Variations and Edge Cases
Tighter registry controls often increase operational overhead, requiring organisations to balance usability against assurance. A registry may be intentionally reachable only from a build subnet, through a service mesh, or via short-lived credentials, but that still does not make it “private” if unauthenticated requests are accepted somewhere in the path.
There is no universal standard for this yet, but current guidance suggests treating the following as red flags:
- Anonymous reads work for manifests even when pushes are blocked.
- Different endpoints enforce different rules, especially between UI, API, and blob storage.
- Role-based settings claim privacy while service accounts or robot accounts have broad pull access.
- Replicated registries inherit weaker permissions from a source or mirror.
Teams should also remember that “private” can mean different things depending on the platform. Some systems only restrict listing, while others restrict retrieval. The practical question is not whether the registry is labelled private, but whether every unauthenticated path fails consistently. If a registry can be fetched by a direct URL, a stale token, or a misrouted proxy, it is not meaningfully private even if the admin console says it is.
NHIMG’s coverage of The State of Secrets in AppSec reinforces the broader pattern: access claims often outpace real enforcement, and that gap is where exposure starts.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Validates whether registry access is truly enforced for non-human identities. |
| NIST CSF 2.0 | PR.AC-3 | Directly addresses access control enforcement for systems and services. |
| NIST SP 800-63 | Supports assurance around authenticated access versus anonymous access. | |
| NIST Zero Trust (SP 800-207) | SC-7 | Privacy depends on controlling traffic at the boundary, not trusting labels. |
| NIST AI RMF | Useful for evaluating whether registry trust assumptions are justified and monitored. |
Test anonymous and service-token access paths to confirm NHI controls block unauthorized registry reads.
Related resources from NHI Mgmt Group
- How do teams know if patch prioritisation is actually reducing identity risk?
- How can security teams know whether n8n-style exposure is actually dangerous?
- How do security teams know whether remote access edge devices are actually protected?
- How do security teams know if dependency controls are actually limiting blast radius?
