Topic starter
19/08/2026 3:31 pm
TL;DR: Centralising container scanning at the registry reduces duplicate work and avoids some coverage gaps, Intruder argues. Registry access still needs tight scopes, because a compromised scanner can widen exposure through ImagePullSecrets and metadata access.
Editorial analysis by NHI Mgmt Group, based on content published by Intruder: “Registry vs. runtime: where to scan your container images”.
Key questions
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.
Q: What fails when container scanning depends on in-cluster agents?
A: The failure is coverage and governance fragmentation.
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.
Glossary terms: Registry-Based Scanning, ImagePullSecret, Container Exposure Management, Runtime Scanner Privilege
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
19/08/2026 4:13 pm
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