Notifications
Clear all
Topic starter
19/08/2026 3:31 pm
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.
NHIMG editorial — based on content published by Intruder: centralised container scanning and the runtime vs registry scanning trade-off
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams scan container images across Kubernetes and cloud services?
A: Use the registry as the primary inspection point and reserve in-cluster scanning for narrow cases where runtime context is genuinely required.
Q: Why do in-cluster scanners increase container security risk?
A: Because they often need elevated permissions and access to registry authentication material such as ImagePullSecrets.
Q: What breaks when container vulnerability data is split across multiple dashboards?
A: Teams lose comparability.
Practitioner guidance
- Remove scanner access to ImagePullSecrets Audit any in-cluster scanning design for direct access to registry authentication material and eliminate it where registry-side inspection can do the job.
- Centralise image inspection at the registry layer Make the registry the primary control point for continuous vulnerability checks so the same image is not rescanned independently in every cluster or account.
- Standardise findings across clouds and accounts Normalise severity, naming, and reporting fields so AWS, Azure, Google Cloud, Kubernetes, and on-prem results can be compared on the same scale.
What's in the full article
Intruder's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance for choosing between registry-side and in-cluster scanning models in mixed Kubernetes and cloud environments.
- Operational considerations for maintaining scanners across multiple clusters, accounts, and cloud providers without duplicating effort.
- Examples of how unified exposure reporting changes day-to-day vulnerability management workflows for platform and security teams.
- Practical setup advice for registry controls that limit uncontrolled image pulls and reduce scanner privilege exposure.
👉 Read Intruder's analysis of centralised container scanning and runtime risk →
Container image scanning: are registry controls keeping pace with runtime risk?
Explore further
19/08/2026 4:13 pm
Centralised container scanning is really an access-governance problem in disguise. The article is not only about vulnerability visibility, it is about where the organisation chooses to place trust. When scanners need ImagePullSecrets and elevated cluster access, they become identity-bearing workloads that must be governed like any other privileged service account. Practitioners should treat scanning architecture as part of their access model, not as a purely operational choice.
A question worth separating out:
Q: Who should own scanner identities and privileges in a container programme?
A: Security and platform teams should treat scanners as governed non-human identities with a named owner, defined access scope, rotation or review cadence, and offboarding process. That prevents a scanner from becoming an unmonitored privileged path into the registry and cluster.
👉 Read our full editorial: Centralised container scanning reduces registry exposure and runtime waste
