TL;DR: Container risk now spans build pipelines, orchestration, runtime, and the cloud IAM layer beneath them, according to Intruder. The operational lesson is that image scanning alone cannot govern containerised systems when credentials, RBAC, and misconfiguration create attack paths beyond the container boundary.
At a glance
What this is: This is an analysis of why container security must be treated as a full lifecycle and cloud governance problem, not an image-scanning problem.
Why it matters: It matters because IAM, Kubernetes and runtime controls determine whether containers stay isolated or become a path into the wider cloud environment.
Context
Container security is the practice of governing how images are built, deployed, connected and monitored once they run. The article argues that teams often secure one layer while leaving the surrounding cloud identity, orchestration and runtime paths exposed, which is where real risk accumulates.
In containerised environments, the security boundary is wider than the workload itself. Kubernetes, managed container services and cloud IAM create overlapping control planes, so a weakness in configuration, privilege or runtime visibility can defeat otherwise sound image hygiene.
The article’s core message is typical of modern container programmes: most organisations can scan images, but far fewer can prove they understand who can deploy them, what they can reach, and how they behave after start-up.
Key questions
Q: What breaks when container security stops at image scanning?
A: You miss the risks that emerge after the image is approved. Production drift, runtime abuse, cluster misconfiguration, and compromised pipeline credentials can all undermine an otherwise clean image. Scanning still matters, but it cannot tell you whether the container is behaving normally, whether it can reach sensitive cloud resources, or whether the build system itself has been subverted.
Q: Why do cloud IAM and Kubernetes RBAC matter so much for containers?
A: Because they define who can deploy, mutate and reach workloads. If those permissions are too broad, an attacker who compromises a container may be able to reach the host, other clusters or adjacent cloud services. Container isolation only works when the surrounding identity model is also tightly governed.
Q: What are the signs that container security controls are failing in production?
A: Warning signs include repeated image drift, unexpected processes, abnormal network flows, replicas that no longer match expected behavior, and suspicious access to Kubernetes APIs or etcd. You should also treat delayed vulnerability remediation and overly broad permissions as failure signals. These indicators usually mean monitoring, policy enforcement, or runtime detection is not keeping pace.
Q: Should teams treat container security and cloud security as separate programmes?
A: No. The article’s central point is that they share the same attack surface once containers depend on cloud identity, orchestration and storage. Separate programmes usually create blind spots in ownership, telemetry and escalation. A unified operating model gives practitioners one view of exposure and one response path.
Technical breakdown
Why container lifecycle security spans build, deploy and runtime
Container risk changes as the workload moves. Build-time scanning looks for known vulnerabilities in the image and dependencies before release, deployment controls govern how the container starts and what it can access, and runtime monitoring watches for behavior after launch. Those are different control problems, not one problem repeated three times. If teams rely on only one stage, they create a false sense of coverage because the attack surface shifts once the image is running.
Practical implication: Treat build, deployment and runtime as separate control stages with different owners and different evidence.
How Kubernetes and cloud identity expand the attack surface
Kubernetes adds its own control plane, including API servers, RBAC roles and admission components. That means compromise does not need to begin inside the container, and a container compromise does not need to stay there. Overly permissive cloud IAM, exposed management endpoints or weak orchestration policy can let attackers move from workload access to broader cloud access. In practice, the workload is only as contained as the identity and orchestration controls around it.
Practical implication: Review RBAC, cloud IAM and cluster exposure together rather than treating container isolation as the primary defence.
Why image scanning cannot replace runtime visibility
Image scanning tells you what was true at a point in time. Runtime visibility tells you what is true now. New vulnerabilities emerge after release, configurations drift, and attackers may abuse trusted components or live credentials without changing the image at all. That is why a clean scan does not equal a safe deployment. Security teams need continuous visibility into active containers, their network paths and their privilege changes to catch the gap between baseline and reality.
Practical implication: Use continuous runtime telemetry to catch drift, privilege abuse and newly exploitable dependencies after deployment.
Threat narrative
Attacker objective: The objective is to turn a container foothold into durable control over workloads, build pipelines or the underlying cloud environment.
- Entry begins when attackers exploit compromised dependencies, exposed orchestration components or CI/CD misconfiguration to get a foothold in the container environment.
- Credential access or privilege abuse follows when trusted build systems, tokens, RBAC roles or injected secrets are used against the environment.
- Escalation occurs when the attacker moves from container access to host or cloud access through excessive permissions, weak isolation or orchestration misconfiguration.
- Impact is achieved through persistence, lateral movement, release tampering, data exposure or broader cloud compromise.
Breaches seen in the wild
- Massive Docker Hub Secrets Leak: 10,000+ Docker Hub container images expose hardcoded secrets and authentication keys.
- LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
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
Container security governance is now a cloud identity problem as much as a workload problem. Image hygiene matters, but it is not the control plane that decides who can deploy, mutate or reach a container. When cloud IAM, Kubernetes RBAC and runtime permissions are misaligned, the attack path moves around the container rather than through it. Practitioners should treat identity and orchestration as first-class container controls.
Lifecycle visibility is the named gap that most container programmes still miss. A point-in-time scan only answers what the image looked like when it was built. It does not answer what changed in production, what new vulnerabilities emerged later, or which trusted pipeline or dependency was abused. The stronger governance model is continuous visibility across build, deploy and runtime, because the risk changes at each stage. Practitioners should align evidence to the stage being controlled.
Misconfiguration, not exotic exploitation, remains the dominant container failure mode. The article’s examples show that compromised dependencies, permissive RBAC and insecure CI/CD paths can be enough on their own. That means teams should spend less time assuming isolation will save them and more time governing the systems that create, release and connect containers. Practitioners should prioritise exposure reduction over theoretical hardening.
Shared ownership is the operational control container security keeps lacking. Developers, platform teams and security teams each control a fragment of the lifecycle, but none can see the full path from image build to cloud runtime. That creates governance gaps around accountability, review and response. Practitioners should assign explicit control ownership for build, admission, runtime and cloud access, then measure it as one programme.
From our research library:
- Kubernetes production adoption has surged from 66% in CNCF's 2023 survey to 82% in 2025.
What this signals
Lifecycle control, not single-point scanning, is the programme shift container teams now need. The useful question is no longer whether the image was clean at build time, but whether the live workload still matches the assumptions that made it safe. That requires continuous evidence from build, deploy and runtime, plus governance over the cloud identity layer that sits underneath.
Cloud identity is the hidden control plane of container risk. Once containers are backed by service accounts, roles and managed orchestration services, privilege decisions made outside the container can completely change what isolation means inside it. Practitioners should expect container reviews to become increasingly IAM-led rather than scan-led.
Attack surface reduction becomes more valuable than total vulnerability reduction when environments are fast-moving. If teams cannot fix everything, they should fix what is reachable, what is privileged and what can be abused without prior knowledge of the environment. That is the practical way to turn container telemetry into risk decisions.
For practitioners
- Define control owners across the container lifecycle Assign explicit ownership for Dockerfile review, image publishing, admission policy, runtime monitoring and incident response so each stage has a named accountable team.
- Review Kubernetes RBAC and cloud IAM together Audit cluster roles, service accounts and cloud permissions as one access surface, with special focus on over-permissive roles that can reach the host or broader cloud services.
- Move from snapshot scanning to continuous runtime checks Keep scanning running workloads after deployment so newly disclosed vulnerabilities, configuration drift and live privilege abuse are visible before they spread.
- Harden CI/CD and build provenance paths Reduce trust in build pipelines, secrets passed through environment variables and third-party dependencies by reviewing repository permissions, token scope and signed artefact flows.
- Prioritise internet-reachable container exposures first Triage findings by exploitability and public reachability rather than raw vulnerability count so the team fixes the paths attackers can actually use from outside the environment.
Key takeaways
- Container security fails when teams treat image scanning as the whole control model instead of one stage in a larger lifecycle.
- The real exposure sits in the combination of runtime drift, Kubernetes control-plane complexity and cloud identity permissions.
- Practitioners should govern containers as part of one cloud attack surface, with explicit ownership and continuous visibility.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8, CSA Cloud Controls Matrix and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0006; TA0008; TA0004 — Credential Access; Lateral Movement; Privilege Escalation | The article centres on abuse of credentials, movement from container to host, and escalation through misconfiguration. |
| Recommendation — Map container exposure paths to TA0006, TA0008 and TA0004, then hunt for privilege and movement gaps in runtime telemetry. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Cloud IAM and Kubernetes RBAC are central to the control failures described in the article. |
| Recommendation — Review access permissions and entitlements across cloud and cluster layers so container workloads only have the reach they need. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article highlights shared ownership, broad tokens and mismanaged access paths across build and runtime. |
| Recommendation — Tighten account and token management for build systems, clusters and cloud services to reduce exposed container paths. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud provider identity controls underpin the container risks described throughout the article. |
| Recommendation — Apply cloud IAM governance to service accounts, workload roles and orchestration permissions before treating containers as isolated. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Secrets, tokens and broad credentials are part of the article’s attack paths through CI/CD and cloud access. |
| Recommendation — Use authenticator management to control token scope, rotation and revocation for build and deployment pipelines. | ||
Key terms
- Container security lifecycle: The container security lifecycle is the set of controls applied from build to registry, deploy, and runtime. It recognises that risk changes as software moves through each stage, so one control never covers the full problem. Mature programmes align different detections and enforcement points to each stage.
- Kubernetes Attack Surface: The Kubernetes attack surface is the total set of cluster components and interfaces that could be targeted by an attacker. It includes the control plane, nodes, network, and add-ons such as ingress controllers and service meshes. As clusters spread across cloud environments, this surface becomes harder to control.
- Runtime Visibility: The ability to observe what an AI client actually accessed, which tools it used, and how it behaved during a session. It is more useful than entitlement snapshots for agent governance because it captures executed reality, not just approved access.
- Cloud Identity: A cloud identity is any account, role, token, or credential used to access cloud services and resources. In practice, it includes both human and non-human identities that can authorize actions in infrastructure, applications, or automation pipelines. Governance depends on knowing which identity type is active and what it can do.
Deepen your knowledge
The NHI Foundation Level course covers NHI governance, IAM and secrets management in the context of cloud-driven identity risk. It helps security practitioners connect workload identity, access control and operational governance in one programme.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org