Docker and Kubernetes transformed how the software industry ships and operates applications, and they did it fast enough that the security architecture around them never quite caught up. Docker made it possible to package an application once and run it anywhere. Kubernetes made it possible to orchestrate thousands of those containers across distributed infrastructure at scale.
Together they became the delivery substrate for modern software so quickly and so completely that container adoption moved from engineering choice to organizational baseline inside a decade. Most of the security assumptions inherited from pre-container infrastructure came along for the ride without being examined against the new reality.
That gap between adoption velocity and security architecture is now running at a scale that has moved it from an organizational problem to a shared one. Container infrastructure underlies financial clearing systems, healthcare records platforms, energy management tooling, and communications networks across dozens of jurisdictions simultaneously.
A base image vulnerability in a widely adopted Docker image or a misconfigured Kubernetes deployment does not expose one organization. It exposes every organization that pulled that image, built on top of it, and shipped it into production. And those organizations operate under different regulatory frameworks, different threat models, and different levels of security maturity. The attack surface is distributed in a way that no single organization controls and no single regulatory framework was designed to address.
The attack surface is distributed in a way that no single organization controls and no single regulatory framework was designed to address.
What the Existing Frameworks Govern and What They Do Not
Regulatory frameworks including the EU's NIS2 Directive, CISA's secure-by-design guidance, and equivalent national frameworks across the UK, Australia, and Asia-Pacific are serious, substantive, and actively enforced responses to the security of critical infrastructure. NIS2 places explicit obligations on operators of essential services to manage supply chain security risks, which in principle covers the container images and Kubernetes configurations those operators depend on.
But the transitive dependency problem in containerized environments creates an accountability chain that does not map cleanly onto the organizational model these frameworks contemplate. When a vulnerability in an upstream base image propagates into thousands of derived containers running across dozens of regulated operators simultaneously, the question of who is responsible for remediation and on what timeline does not have a clean answer inside any existing framework.
The obligation is clear. The mechanism for fulfilling it across a distributed, interdependent container supply chain, where a single Kubernetes cluster might be running images built from dozens of different upstream sources, is not. That mismatch is where the shared attack surface lives and where the gap between regulatory intent and operational reality is widest.
The Remediation Window as Strategic Terrain
State-sponsored threat actors including APT41 and Sandworm have repeatedly demonstrated that the interval between a vulnerability being disclosed and organizations completing remediation is not dead time. It is the operational window that sophisticated actors are positioned to exploit at scale, and containerized infrastructure extends that window in ways that traditional patch management did not anticipate.
A vulnerability in a base image requires every organization that built on top of it to identify the affected containers across their Kubernetes clusters, assess exploitability in their specific deployment context, rebuild and redeploy the affected images, and validate that nothing downstream broke in the process. All of that happens under delivery pressure and frequently without dedicated security resources to drive remediation across a distributed environment.
Because containerized applications increasingly expose their functionality through APIs, a vulnerable container is frequently also a vulnerable API endpoint. The blast radius of a successful exploit extends beyond the container itself into the service integrations, data flows, and third-party dependencies built on top of it. [See: How AI Is Reshaping the API Security Threat Landscape] The container and the API surface above it are part of the same attack chain, and securing one without the other leaves the exposure intact.
Open Source Infrastructure as a High-Value Target
The container ecosystem is fundamentally an open-source ecosystem. Docker, Kubernetes, and the tooling built around them are community-governed projects whose source code is publicly readable, whose dependency chains are publicly documented, and whose vulnerability disclosures are publicly indexed the moment they are filed. That transparency is also a targeting mechanism.
Adversaries do not need to reverse-engineer proprietary software to understand its attack surface. The attack surface of open-source container infrastructure is documented in public repositories, tracked in public CVE databases, and searchable by anyone with an internet connection and a strategic interest in the organizations running it. [See: Why Open Source Technologies Are a Preferred Target for State-Sponsored Actors] The same properties that make open-source software auditable and trustworthy for defenders make it readable and mappable for attackers.
Community-governed security tooling that operates outside commercial vendor incentive structures is one of the few mechanisms positioned to respond to that reality across jurisdictional boundaries. Projects achieving recognized governance status through bodies like OWASP represent a meaningful accountability architecture for infrastructure that existing regulatory frameworks were not designed to govern. But recognized governance and active security are not the same thing, and the open-source container ecosystem has accumulated security debt at the same pace it has accumulated adoption.
What Operators and Policymakers Are Working With
Critical infrastructure operators navigating NIS2, CISA guidance, or equivalent national frameworks are managing a genuine structural mismatch between what the regulations require and what containerized software supply chains make straightforward to deliver. The obligation to manage supply chain security is real and enforceable. The tooling and process infrastructure required to fulfill that obligation at the pace Docker and Kubernetes deployments move has not kept up.
The policy and technical communities working on this problem are not starting from zero. CISA's container security guidance, NIST's work on software supply chain security, and the OWASP community's development of open governance frameworks for security tooling all represent serious and substantive efforts to close the gap between regulatory obligation and operational reality.
But containers became a shared attack surface globally not through any single failure of judgment. They became one through the compounding of individually rational engineering decisions made faster than the governance infrastructure around them could adapt. Closing that gap requires the same compounding logic working in the same direction: engineering practice, regulatory clarity, and community-governed tooling advancing together at the pace the shared attack surface demands.
