Centralised container scanning reduces registry exposure and runtime waste

At a glance

What this is: This is an analysis of why centralised registry-based container scanning can outperform in-cluster scanning, with coverage, efficiency, and credential exposure as the key trade-offs.

Why it matters: It matters because IAM and cloud security teams need scanning models that do not widen registry access, multiply operational burden, or leave multi-cloud workloads inconsistently covered.

Context

Container image scanning is a governance problem as much as a detection problem. The core issue is where to place trust, visibility, and control when the same image may run across Kubernetes, serverless platforms, and managed container services with very different operating models.

A registry-centred model tries to make scanning part of the image lifecycle rather than a workload-side activity. That matters for identity and access because in-cluster scanners often need elevated permissions and registry credentials, which creates a broader access boundary than many teams realise.

The article's starting position is typical for teams that have grown across multiple cloud environments: the operating model fragments before the security model does.

Key questions

Q: What fails when container scanning depends on in-cluster agents?

A: The failure is coverage and governance fragmentation. Runtime agents tie security to a specific cluster, so teams miss other deployment models such as ECS or Cloud Run and end up maintaining separate controls for each environment. That creates blind spots, duplicated effort, and inconsistent reporting across the estate.

Q: Why do scanner credentials increase container risk?

A: Because the scanner becomes a privileged identity that can authenticate to the registry on behalf of the platform. If that tool is compromised, its registry access can be abused to fetch image metadata or expand exposure. The risk is not the scan itself, but the trust granted to perform it.

Q: What are the signs that container visibility is breaking down?

A: Look for separate dashboards, inconsistent severity scales, and repeated scans of the same image across multiple clusters. Those signals show that risk data is fragmented and that teams are paying operational cost without gaining a unified view of exposure.

Q: Should teams scan container images in the registry or at runtime?

A: For most multi-cloud estates, registry-based scanning is the better governance default because it centralises inventory, reduces duplicate work, and avoids distributing privileged agents into every runtime. Runtime scanning still has niche value, but it should be the exception, not the primary control.

Technical breakdown

Why in-cluster scanners create access and coverage trade-offs

An in-cluster scanner runs close to the workload, which can improve local inspection but also ties security coverage to a specific runtime environment. That model breaks down when images are reused across clusters or deployed into services that do not support internal agents in the same way. It also increases maintenance burden because every cluster becomes a separate deployment, policy, and update target. From a security architecture view, the scanner is no longer a passive observer. It becomes another privileged component that must be trusted, governed, and monitored.

Practical implication: Treat cluster-local scanning as a constrained control, not a universal default, and only use it where the runtime model justifies the added operational burden.

Why ImagePullSecrets become an identity risk in runtime scanning

To inspect images at runtime, a scanner may need registry access credentials such as ImagePullSecrets. Those secrets are a form of non-human identity credential because they authorize a workload or tool to authenticate to a registry on behalf of the environment. If the scanner is compromised, the attacker can potentially reuse that access path to reach image metadata or other registry resources. The security concern is not just leakage, but privilege concentration: one tool now holds credentials that were meant to support pulling, not broad analysis or inspection.

Practical implication: Limit the registry permissions granted to scanning tooling and separate inspection access from general image-pull authority wherever possible.

How centralised registry scanning changes the control plane

Centralised scanning moves analysis away from each runtime and into a shared registry or external exposure-management layer. That shifts the control point to image publication and inventory, where the same artifact can be scanned once and evaluated consistently across environments. It also improves comparability because findings can be normalised across cloud providers and deployment models. The security gain is not only fewer scans, but a cleaner trust boundary: the tool does not need to live inside every cluster to observe the image estate. That reduces duplication and helps teams see exposure as a portfolio problem rather than a node-level event.

Practical implication: Anchor scanning in registry inventory and standardised reporting so every environment is assessed through the same control model.

Threat narrative

Attacker objective: The attacker aims to obtain registry credentials and leverage the scanner's trust to extend access beyond the original inspection function.

1. Entry occurs when a runtime scanner inside the cluster is granted elevated access and registry credentials so it can inspect container images.
2. Credential access follows if the scanner is compromised, because ImagePullSecrets can expose registry authentication material and associated metadata access.
3. Impact emerges when the stolen access path is reused to reach container image assets or widen exposure across the container estate.

Breaches seen in the wild

• Secrets in Docker Hub images (RWTH Aachen study): A 2023 RWTH Aachen study found secrets in 8.5% of container images, and 275,269 internet hosts still using the leaked private keys.
• TeamTNT worm 2020: A TeamTNT cryptomining worm spread through exposed Docker APIs and stole AWS credential files from every host it infected, Cado Security found.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Centralised container scanning is really a trust-boundary decision: teams are deciding whether image inspection belongs inside every runtime or at the registry and exposure-management layer. The centralised model reduces duplicated effort and makes coverage more consistent, but only if registry controls and inventory are authoritative. For practitioners, the real question is where the control can be enforced without multiplying privileged access paths.

ImagePullSecrets are a governance asset, not just a technical convenience: once a scanning tool needs them, the scanner inherits part of the registry trust model. That creates a non-human identity governance problem because a defensive workload now depends on credentials that can be abused if the tool is compromised. Practitioners should treat scanning access as a scoped identity with explicit lifecycle and least-privilege controls.

Multi-cloud container estates expose a visibility gap that dashboard sprawl does not solve: a security team cannot compare risk accurately when AWS, Azure, Google Cloud, and Kubernetes present different formats and control surfaces. The named concept here is registry visibility fragmentation, the condition where risk data exists but cannot be governed consistently across environments. Practitioners need one exposure model that normalises findings across all deployment targets.

Security tooling should not expand the attack surface it is meant to reduce: that is the central lesson from in-cluster scanning. The more a scanner behaves like a privileged platform service, the more it needs the same governance discipline applied to any high-trust workload. For teams building container controls, the practical conclusion is to separate inspection capability from runtime privilege wherever feasible.

From our research library:

• Kubernetes production adoption has surged from 66% in CNCF's 2023 survey to 82% in 2025.

What this signals

Registry visibility fragmentation: once container estates span Kubernetes, serverless, and managed services, the security problem becomes consistency of control rather than the presence of a scanner. Teams should expect the governance model to fail first through duplicated tooling, uneven reporting, and hidden credential paths rather than through a single obvious outage.

A registry-centred model gives practitioners a cleaner place to enforce policy, but it only works if the registry inventory is authoritative and the scanner does not inherit broad access. That is the control boundary worth hardening because it defines whether scanning reduces risk or becomes another privileged service in the estate.

For practitioners

• Define a registry-first scanning architecture Map all container sources and decide which registries and proxies will be the authoritative inspection points for image risk.
• Restrict scanner access to least privilege Review whether scanning tools need registry pull credentials, and remove any broader access than is required to inspect image metadata.
• Normalize findings across cloud providers Use a single exposure-management layer or reporting format so AWS, Azure, Google Cloud, and Kubernetes results can be compared consistently.
• Reduce duplicate re-scanning work Scan images once at the registry and re-use those results across clusters and deployment targets instead of repeating the same analysis at every node.
• Audit privileged runtime scanners Inventory every cluster-local scanner, the permissions it holds, and the image or registry assets it can reach if compromised.

Key takeaways

• Container scanning strategy is a governance decision about where to place trust, not just a choice of deployment location.
• In-cluster scanners can widen the attack surface when they require elevated access to registry secrets and metadata.
• Centralising scanning at the registry can simplify coverage and reporting, but only if access scopes and inventory are tightly controlled.

Key terms

• Registry-Based Scanning: A container security model that evaluates images at the registry or publication layer instead of inside each runtime. It improves consistency because one artifact can be scanned once and reused across many deployment targets, but it only works well when the registry inventory is authoritative and access is tightly controlled.
• ImagePullSecret: An ImagePullSecret is a credential object that lets Kubernetes authenticate to a private container registry when pulling images. It extends trust beyond the application runtime into image supply and registry access, so its scope and lifecycle need to be managed like any other non-human credential.
• Container Exposure Management: A governance approach that normalises container risk findings across registries, clouds, and deployment environments. It focuses on making image vulnerabilities, access paths, and inventory visible in one place so teams can compare risk without relying on disconnected dashboards.
• Runtime Scanner Privilege: The elevated access granted to a scanning component so it can inspect images where they execute. In practice, this privilege often includes registry access and cluster permissions, which means the scanner must be treated as a high-trust identity with a lifecycle that is actively governed.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.