Container Cybersecurity Is More Than Image Scanning

A Field Guide for IT Pros

If you work in IT, DevOps, or cloud today, you are almost certainly running containers. Docker and Kubernetes changed how we build, ship, and run applications — and quietly, they changed how much of your infrastructure is now exposed to attackers.

So when leadership walks over and asks, “Are our containers secure?” — what’s your honest answer?

For a lot of teams, the reflex is to point at a scanner. “The images are scanned. The YAML passes the linter. We’re good.” And here’s the uncomfortable part: that answer isn’t wrong, exactly. It’s just dangerously incomplete. A clean image scan tells you one thing about one layer of a system that has at least four. It’s like checking that the front door is locked and calling the whole building secure.

Container cybersecurity is bigger than scanning images and configs. In this post we’ll break down what securing a containerized environment actually involves, look at the real OWASP risk landscape (there’s more than one list, and most articles get this wrong), walk through a breach that turned every abstract risk into a headline — and then give you a repeatable way to reason through all of it using the Threat & Control Method.

Let’s make this simple.

First, the good news: you’re not starting from zero

There’s a myth that “cloud-native security” is some separate discipline you have to learn from scratch — a new universe of tools, acronyms, and threats that has nothing to do with the infrastructure you already run.

It isn’t.

A container is a process on a Linux host. A Kubernetes cluster is a distributed system with a network, an API, identities, and permissions. If you’ve spent years managing servers, segmenting networks, handling credentials, and troubleshooting why service A can’t reach service B — you already understand the substance of what container cybersecurity protects. You’re not learning a new language; you’re adding a defensive accent to one you already speak.

That’s the unfair advantage we talk about constantly for IT pros moving toward cybersecurity: the person who built and operated the environment is often better positioned to defend it than someone who arrives knowing only the cybersecurity theory. Keep that in mind as the risks pile up below. None of them are magic. Most of them are old infrastructure problems wearing new, cloud-native clothes.

What container cybersecurity actually is

Real container cybersecurity is continuous, and it spans the entire lifecycle of your application. It is not a gate you slap on at the end of the deployment pipeline. It’s baked into three distinct phases, and each phase has its own failure modes:

Build. Securing the supply chain: signing images, pinning trusted base images, and scanning for known vulnerabilities (CVEs) in those base images and their dependencies. This is the phase your scanner covers — and only this phase.

Deploy. Enforcing policy before a container is allowed to run. Is it asking for root? Does it carry hardcoded secrets? Is it requesting privileges it doesn’t need? This is where admission control lives, and a scanner has nothing to say about it.

Run. Watching the live environment. If a container that should be serving web traffic suddenly spawns a shell, starts scanning the internal network, or phones home to an unknown IP, something needs to catch that and isolate it — in real time, while it’s happening.

Notice that image scanning touches exactly one of these three phases. That’s the whole problem in one sentence.

The reality check: OWASP has two container lists (and they’re different)

Here’s where a lot of blog posts — and honestly a lot of engineers — get tripped up. People say “the OWASP Top 10 for Containers” as if it’s one thing. It isn’t. OWASP maintains two relevant projects, and they do genuinely different jobs.

The OWASP Docker Top 10 is not a risk list at all. It’s ten cybersecurity controls, ordered by relevance, for building a secure Docker-based environment — think of it as a specification sheet you design against, aimed at the container and host layer. Its ten items are: Secure User Mapping, Patch Management Strategy, Network Segmentation and Firewalling, Secure Defaults and Hardening, Maintain Security Contexts, Protect Secrets, Resource Protection, Container Image Integrity and Origin, Follow the Immutable Paradigm, and Logging.

The OWASP Kubernetes Top 10 is the one people usually mean when they say “container risks.” It’s a prioritized list of the most common ways Kubernetes environments actually get compromised — a risk list, aimed at the orchestration layer. The current published version (2022) reads:

K01 — Insecure Workload Configurations. Pods running as root, privileged containers, no resource limits, writable root filesystems.
K02 — Supply Chain Vulnerabilities. Compromised or bloated images pulled from public registries.
K03 — Overly Permissive RBAC. Service accounts and users with far more cluster power than they need.
K04 — Lack of Centralized Policy Enforcement. No consistent guardrails applied across clusters.
K05 — Inadequate Logging and Monitoring. You can’t stop what you can’t see.
K06 — Broken Authentication Mechanisms. Exposed or unauthenticated cluster components and dashboards.
K07 — Missing Network Segmentation Controls. A flat cluster where every pod can talk to every other pod.
K08 — Secrets Management Failures. API keys and passwords hardcoded into images, manifests, or environment variables.
K09 — Misconfigured Cluster Components. An unhardened kubelet, etcd, or control plane.
K10 — Outdated and Vulnerable Kubernetes Components. Unpatched control planes and add-ons.

Read that list again and notice something: almost none of these are exotic. Overly permissive access. Flat networks. Hardcoded credentials. Missing logging. Unpatched software. These are the same failures that have haunted on-prem infrastructure for two decades — they’ve just moved into the cluster. That’s exactly why your operational experience transfers.

Now, here’s the punchline. Look at how much of that list an image scanner can see. It’ll help with K02 and K10 (vulnerable components). It might flag a hardcoded secret baked into an image (part of K08). But your scanner will never tell you your cluster network is flat (K07), that your dashboard is exposed to the internet (K06), or that a service account has cluster-admin for no reason (K03). The scan comes back green, and you’re still wide open.

When theory becomes reality: the 2018 Tesla Kubernetes breach

If those risks feel abstract, one of the most instructive container cybersecurity incidents on record makes them concrete — because it wasn’t a sophisticated, nation-state, zero-day operation. It was a chain of ordinary mistakes.

In February 2018, the cloud cybersecurity firm RedLock reported that attackers had gotten into Tesla’s cloud environment. The way in wasn’t clever. Tesla’s Kubernetes administrative console was exposed to the internet with no password protection at all — a textbook Broken Authentication failure (K06). No exploit required. The door was simply open.

Once inside the cluster, the attackers found a pod that contained hardcoded AWS access credentials (K08 — Secrets Management Failures). Those credentials unlocked an Amazon S3 bucket holding sensitive vehicle telemetry data — and gave the attackers access to Tesla’s AWS compute resources.

And here’s what they did with all that stolen compute: they ran a cryptomining operation on Tesla’s own infrastructure — a classic case of cryptojacking. This was only possible because the workloads had no meaningful resource constraints (K01 — Insecure Workload Configurations); with CPU limits in place, a rogue miner has far less room to operate. To stay hidden, the attackers skipped public mining pools, hid their traffic behind CloudFlare, used non-standard ports, and deliberately throttled CPU usage low enough to avoid tripping the obvious alarms.

Tesla remediated quickly and stated it found no sign that customer privacy or vehicle safety was affected. But step back and look at the anatomy of it: an exposed console, a hardcoded secret, and unconstrained workloads chained together into a full cloud compromise. Not one line of application code was exploited. The application was fine. The environment hosting it was the vulnerability — and every link in that chain is sitting right there on the OWASP Kubernetes Top 10.

That’s the lesson worth tattooing on your monitor: in the container world, the breach usually isn’t in the code. It’s in the configuration.

The trap: tools are just shopping lists

Put the OWASP lists and the Tesla breach side by side and you can see why leaning on a single scanner is such a seductive trap. A scanner produces a satisfying stream of output. Green checkmarks. Neat CVE counts. It feels like security.

But buying a tool doesn’t give you security — it gives you alerts. A scanner is a shopping list of things that might be wrong; it has no idea which of those things actually matters in your environment, which of your containers would hurt the business if compromised, or whether your real exposure is something the scanner can’t even see (like Tesla’s open dashboard).

The thing that turns a pile of alerts into actual security isn’t another tool. It’s a decision-making framework — a repeatable way to figure out what to protect, what can go wrong, and what to do about it, in that order.

Applying the Threat & Control Method to your containers

This is exactly what the Threat & Control Method is built for. It’s a four-phase defensive reasoning process — Inventory → Threats → Controls → Scale — that stops you from trying to fix everything at once and instead moves you deliberately from what you have to what protects it. Here’s how it lands on a container environment you could start on tomorrow morning.

Phase 1 — Inventory: you can’t protect what you can’t see

Before you buy a single runtime tool, map what you actually own. In a containerized world that means:

Registries. Where do your images come from? Are developers pulling straight from Docker Hub, or from a vetted internal registry?
Assets. How many clusters exist? Are they managed (EKS, AKS, GKE) or self-hosted? And — the Tesla question — is any dashboard or API server reachable from the internet?
Identities. Who has cluster-admin? Which service accounts hold permissions nobody remembers granting?
Existing controls. Do you already have a network policy engine like Calico installed but sitting unused? (This happens constantly. People buy the control and never turn it on.)

The output of this phase is an honest asset inventory. Most teams discover their real risk lives in something they forgot they were running.

Phase 2 — Threats: what can actually go wrong here

Don’t stop at “we might get hacked.” Build a specific threat model for your environment, using the OWASP list as a prompt:

What happens if a developer commits an AWS key into an image? (K08 — and yes, this is precisely how Tesla started.)
If an attacker pops our front-end web pod, what stops them from reaching the payment-processing pod right next to it? (K07.)
Which of our workloads, if compromised, would materially hurt the business? Rank them.

The output is a prioritized threat model. Not every threat deserves equal attention — the whole point is to decide what matters first.

Phase 3 — Controls: turn analysis into a plan

Now, and only now, you choose controls that address your prioritized threats — weighing each one against its operational cost. The mapping gets clean fast:

Threat: lateral movement between pods (K07). → Control: Kubernetes Network Policies with a default-deny posture.
Threat: containers running as root (K01). → Control: an admission controller like OPA Gatekeeper or Kyverno that blocks any deployment requesting root or privileged mode.
Threat: hardcoded secrets (K08). → Control: a real secrets manager (Vault, cloud KMS, sealed secrets) plus a pre-commit scan so keys never reach a manifest in the first place.
Threat: runtime anomalies (the cryptojacking-in-progress problem). → Control: runtime monitoring like Falco to alert on unexpected shell execution or suspicious outbound traffic.

The output is a cybersecurity plan tied directly to real, ranked threats — not a wishlist of every product a vendor demoed.

Phase 4 — Scale: make it survive reality

Containers are ephemeral. They spin up and die in seconds, dozens at a time. Any control that depends on a human remembering to check something will fail by Wednesday. To scale, the reasoning has to move into the pipeline:

Automate image scanning inside CI/CD (e.g., a GitHub Actions step) and break the build on a critical CVE.
Continuously audit your Kubernetes manifests with an infrastructure-as-code scanner, so misconfigurations get caught before they ship.
Turn the Threat & Control reasoning itself into a standard step: when someone proposes a new microservice, it automatically runs through Inventory → Threats → Controls before it reaches production.

The output is a repeatable decision process — the same reasoning applied to every new workload, cluster, and cloud, without you personally standing guard over each one.

The takeaway

Container cybersecurity doesn’t have to be paralyzing, and it definitely isn’t a separate universe reserved for a cloud-native priesthood. Strip away the buzzwords and it’s the same discipline you’ve been practicing for years — least privilege, network segmentation, credential hygiene, patching, visibility — applied to a new kind of infrastructure that happens to move faster and disappear quicker.

The teams that get breached aren’t usually the ones without tools. They’re the ones drowning in alerts with no framework to decide what matters. Learn the real risk landscape (both OWASP lists, not the imaginary merged one), study the breaches that turned those risks into headlines, and run everything through a structure like Inventory → Threats → Controls → Scale. Do that, and container cybersecurity stops being a guessing game and becomes what it always should have been: a clear, repeatable engineering process.

Because at the end of the day — cybersecurity is not rocket science.

You just ran the method once. The course is where it becomes automatic.

Everything above — Inventory, Threats, Controls, Scale — is the same reasoning we teach inside the Blue Team Academy course, applied across every environment you’ll defend, not just containers. It’s built for experienced IT pros who don’t want another pile of tools and frameworks to memorize, but a repeatable way to think, decide, and act like a defender. See what’s inside →