The cloud isn't secure by default: what containers changed about risk

Containers were supposed to make things easier. And in some ways they did. They made it easier to ship fast and keep things highly available. The ability to package an application with all its dependencies into a portable, lightweight unit and ship it anywhere is a genuine step forward. But that convenience has come with a layer of complexity that most security teams are still catching up on.

Where we once had a single monolithic application to secure, we now have potentially hundreds of microservices, each with its own infrastructure and stack. Most teams are running containers on Kubernetes, which I’d argue is one of the most complex pieces of software on the planet. I’ve had conversations recently where third parties hear we’re running Kubernetes and the first question is: why? How are you handling that complexity?

And on top of that, managed services like Amazon ECS and Google GKE make Kubernetes easier to run, but they introduce their own layer of complexity. Each cloud provider manages those environments differently, with its own configuration and its own way of doing things. You still need to understand how your containers are being run.

All of that adds up to a much broader attack surface than most teams realize. So where does container risk come from exactly? What do recent breaches tell us? And what should your team be prioritizing?

Why “cloud is secure by default” is a dangerous myth

Let's start with one of the biggest sources of risk - a misconception that's still widely held.

One of the most dangerous assumptions teams make is that the cloud provider has your security covered. Cloud providers secure the underlying infrastructure - the hypervisors, the physical data centers. But everything you configure inside that infrastructure is entirely your responsibility.

Gartner estimates that 99% of cloud security failures are the customer's fault. That's not finger-pointing. It's a reflection of how difficult these environments are to manage correctly. 

Container security isn’t a single scan - it’s a lifecycle

Container security isn’t one thing. It’s not a single scan or a single tool. There’s a full lifecycle that needs to be addressed: build time, supply chain, deployment, and runtime.

1. At build time, image scanning lets you analyze for known vulnerabilities in OS packages and application dependencies before they reach production. Tools can integrate into your CI/CD pipelines and run automatically every time a new image is pushed to your repository.
2. The supply chain is the next layer. When you build a Docker image, you’re building on top of a base operating system image. Where did that image come from? Are the dependencies trustworthy? Are the pipelines that build and push it secure?
3. At deployment, you need to consider whether containers are running as root, whether they have excessive Linux capabilities, and how secrets are being passed in - particularly through environment variables, where credentials can start to propagate into logs and other unexpected places.
4. At runtime, once a container is live and processing data, the question shifts to behavior. Is there unexpected network activity? Is privilege escalation happening? Attackers routinely use initial access into a container to escalate onto the underlying host and from there into the broader cloud environment.

The challenge is that each stage requires different tools and different thinking, and a gap at any point can undermine all the work you’ve done everywhere else. There’s been a lot of talk about “shift left” - introducing security as early as possible. In practice, that can end up just shifting responsibility onto developers rather than ensuring coverage across the board. What you actually need is visibility across the entire lifecycle, not just at one end of it.

Why finding vulnerabilities is only half the battle

Most teams think about container security in terms of vulnerabilities - find them, fix them, move on. But in a containerized environment, the picture is more nuanced than that.

Production surprises

You can scan everything before you ship, but new critical vulnerabilities can emerge after you've pushed to prod. That image you scanned and cleared three months ago could now contain a known exploit. Without continuous scanning of what's actually running, you're working off a snapshot that's already out of date.

Configuration drift

An image scan tells you what should be running - it gives you the baseline. But once a container is live, things change. People log in, configurations shift, dependencies get updated. What's actually in production can drift from what you originally shipped, and that gap is where risk creeps in.

The orchestration layer

Even teams that scan their containers thoroughly can overlook the platform running them. Kubernetes has its own attack surface - exposed API servers, overly permissive RBAC roles, misconfigured components - and attackers are starting to target it directly.

Reachability

Even when you do find vulnerabilities, the number can be overwhelming - hundreds, sometimes thousands. Trying to fix them all will bury your team for months. Which of those vulnerabilities could an attacker with no prior knowledge of your environment actually exploit from the internet? That's where your focus should be.

What recent breaches tell us about container risk

Attacks against container infrastructure generally come from two directions: compromised dependencies, and compromised build pipelines. Over the past two years, we've seen both play out in major, headline-grabbing incidents. Here are four that stand out.

XZ Utils (March 2024)

A suspected state-sponsored actor spent three years socially engineering their way into becoming a maintainer of XZ Utils, a widely used compression library. Once in position, they inserted a backdoor that could bypass authentication for certain services. That backdoor spread silently through Docker Hub via Debian-based images. Research conducted in August 2025 found that compromised base images were still available on Docker Hub  - meaning anyone pulling those images was deploying a backdoored container into production.

Ingress Nightmare (March 2025)

A set of five vulnerabilities in the Nginx Ingress Controller for Kubernetes, the most severe carrying a 9.8 CVSS score. It allowed unauthenticated remote code execution via the admission controller webhook. Nginx Ingress is one of the most widely deployed components in the Kubernetes ecosystem. 43% of cloud environments were affected, with over 6,500 clusters publicly exposed.

runC escapes (November 2025)

These vulnerabilities broke the fundamental promise of container isolation, allowing attackers to escape a compromised container and gain root access on the underlying host operating system - and from there, broad access across the network.

HackerBot Claw (February 2026)

An autonomous campaign that exploited misconfigurations in GitHub Actions to compromise CI/CD pipelines across seven organizations. One of the victims was Trivy - ironically, a container security scanner. The attackers stole a personal access token with broad permissions, used it to make the repository private, deleted releases, and pushed a malicious VS Code extension to a public marketplace. No CVEs were involved. It was pure misconfiguration.

The pattern across all four is clear: whether it's the dependencies you pull or the pipelines you build with, if either is compromised, it doesn't matter how secure your container is at runtime. You're still going to end up with a breach. Every one of these came down to misconfiguration, trusted components used against you, and the assumption that somebody else was handling security.

Who owns container security?

Container security sits at the intersection of development, operations, and security. In most organizations, that means it falls between the cracks. Developers build the images but may not think deeply about security. Platform engineers manage the Kubernetes cluster but don’t necessarily have deep security expertise. Security teams understand the risks but lack visibility into fast-moving container environments. Each team sees their slice, but nobody sees the whole picture.

The shared responsibility model you have with your cloud provider also exists internally. You need explicit ownership at each stage of the container lifecycle: who reviews Dockerfiles, who manages admission policies, who monitors runtime behavior, who responds to incidents. Without that - and without shared tooling that gives every team a common view - you end up with blind spots that no single team believes is their problem.

This is as much an organizational design question as a technical one. Security isn't an individual's responsibility - it's a team sport. But that only works if your teams have shared tooling and shared visibility.

Container security doesn’t stop at the container

Everything we’ve covered - image scanning, runtime security, Kubernetes hardening, pipeline security - is essential. But container security alone isn't enough. Containers don't exist in isolation. They run on cloud infrastructure with its own configuration, identity management, network architecture, and storage services. A bulletproof container running in an AWS environment with overly permissive IAM roles, open S3 buckets, and no logging is still vulnerable - just from a different direction.

This is why you need visibility across your full attack surface - your containers, the cloud infrastructure they sit on, and your configuration at each layer.

At Intruder, this is exactly the problem we solve - giving teams a single view of their attack surface that spans containers and cloud, prioritized by what’s actually exploitable. Because in 2026, you can’t have container security without cloud security. They’re the same thing. 

See how Intruder gives you that unified view - start a free trial or book some time to chat with us.