TL;DR: Container scanning is moving toward centralized registry-based visibility because in-cluster agents create coverage gaps, duplicate work, and can expose ImagePullSecrets if compromised, according to Intruder. The governance issue is not just where to scan, but how to avoid turning defensive tooling into another access path.
Editorial analysis by NHI Mgmt Group, based on content published by Intruder: “Registry vs. runtime: where to scan your container images”.
Key questions
Q: What fails when container scanning depends on in-cluster agents?
A: The failure is coverage and governance fragmentation.
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.
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.
Practitioner guidance
- 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.
Bottom line: Container scanning strategy is a governance decision about where to place trust, not just a choice of deployment location.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full 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.
A few things that frame the scale:
- Kubernetes production adoption has surged from 66% in CNCF's 2023 survey to 82% in 2025.
A question worth separating out:
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.
👉 Read our full editorial: Centralised container scanning reduces registry exposure and runtime waste