Use the registry as the primary inspection point and reserve in-cluster scanning for narrow cases where runtime context is genuinely required. That approach avoids duplicated scans across clusters, reduces privileged workload sprawl, and makes vulnerability reporting more consistent across ECS, Cloud Run, Kubernetes, and on-prem environments.
Why This Matters for Security Teams
Container image scanning sounds simple until teams try to apply it consistently across Kubernetes, managed container services, and CI pipelines. The practical question is not whether to scan, but where the scan produces a trustworthy result that can be governed, deduplicated, and acted on. If the same image is scanned in the registry, again in the cluster, and again at deployment time, teams often end up with conflicting findings, delayed remediation, and unclear ownership.
Registry-first scanning also supports better control mapping. Security and compliance teams can anchor the process to NIST SP 800-53 Rev 5 Security and Privacy Controls for continuous monitoring, configuration management, and vulnerability handling rather than treating scanning as an ad hoc platform feature. That matters because container estates are rarely limited to one runtime. Images move through Kubernetes, ECS, Cloud Run, and other managed services, while the vulnerability signal must remain consistent enough to support risk decisions.
In practice, many security teams encounter drift only after the same vulnerable image has already been deployed in multiple places, rather than through intentional scan governance.
How It Works in Practice
The most stable model is to treat the container registry as the system of record for image inspection. That means scanning on push, rescanning when vulnerability intelligence changes, and using immutable image digests so the same artifact is assessed everywhere it runs. Kubernetes admission controls can then be used to block or warn on images that fail policy, while runtime telemetry handles the separate problem of detecting malicious behaviour after launch.
A workable implementation usually combines three layers:
- Registry scanning for baseline vulnerability identification, package inventory, and secret exposure checks.
- CI scanning for developer feedback before release, ideally against the same policy logic used in production.
- Selective in-cluster or node-level validation only when runtime context, ephemeral sidecars, or local image caches prevent reliable registry inspection.
This approach aligns well with the control intent described in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where teams need repeatable evidence for vulnerability management and change control. It also fits a broader platform-security pattern: scan the artifact once, promote the same digest through environments, and attach policy results to that digest rather than to each deployment instance.
For cloud services, the practical issue is visibility. Managed platforms may abstract the node, the filesystem, or even the image retrieval path, so in-cluster scanning can be incomplete or expensive. Registry-based scanning avoids that by inspecting the canonical artifact before it fans out to multiple runtimes. It also reduces the risk of privileged DaemonSets or broad cluster access simply to run a scanner.
These controls tend to break down when image provenance is weak and mutable tags are reused across environments, because the scan result no longer maps cleanly to the artifact actually running.
Common Variations and Edge Cases
Tighter image governance often increases pipeline friction, requiring organisations to balance release speed against the need for reproducible, auditable results. That tradeoff becomes more visible in hybrid estates where a single image can be deployed to Kubernetes, serverless containers, and legacy hosts.
One common edge case is private base images that are rebuilt frequently. In that situation, current guidance suggests rescanning on rebuild and on vulnerability feed updates, because a clean result from yesterday can become stale quickly. Another edge case is air-gapped or disconnected environments, where registry access may be limited and local mirrors become the practical source of truth. Best practice is evolving here, but the key principle remains the same: the scan should follow the immutable artifact, not the ephemeral runtime location.
There is also no universal standard for when runtime-only scanners should be mandatory. They make sense when you need to inspect generated files, mounted secrets, or environment-specific libraries that are not visible in the base image. They are less useful when they merely duplicate registry findings and create more alert noise. For teams operating under broader cloud governance expectations, pairing this model with NIST SP 800-53 Rev 5 Security and Privacy Controls gives a defensible way to justify where scanning occurs and why.
Where this breaks down is in environments with unmanaged image promotion, manual retagging, or multiple registries lacking digest-level traceability, because the same image can no longer be reliably tied to one scan result.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 | Image scanning needs clear ownership and risk governance across teams and platforms. |
| MITRE ATT&CK | T1611 | Container environments can be abused through escape or runtime compromise after deployment. |
| CIS Controls | 7 | Vulnerability management requires regular assessment of software and container images. |
Assign ownership for image risk decisions and make scan results part of the security governance process.
Related resources from NHI Mgmt Group
- How should security teams govern ephemeral credentials across Kubernetes and cloud services?
- How should security teams monitor risky identity activity across cloud services?
- How should security teams unify identity across cloud and data center environments?
- How should security teams govern machine credentials across cloud and CI/CD environments?
