The convenience that hid the attack surface

Containers won because they made shipping software repeatable: bundle the app and its dependencies into an image, run it anywhere. But that same bundle quietly became a new attack surface most teams never inspect. A container image is a frozen snapshot of an operating system and dozens of libraries — and the day you build it, some of those libraries already have known vulnerabilities, while more are disclosed every week after. The image that was clean at build time is a vulnerability inventory that only grows, running in production, that nobody re-scans.

Kubernetes adds a second layer of risk on top: a powerful orchestration system whose defaults favor convenience over safety, with its own identities, network policies, and secrets. For a lean team, the goal isn't to master every knob — it's to get the handful of controls right that close the breach paths that actually show up, and to fold container risk into the vulnerability and findings program you already run rather than treating it as a separate universe.

The breach paths that actually show up

You don't need an exhaustive threat model to know where container incidents come from. A few patterns dominate:

  • Vulnerable base images. The single most common container finding: an image built on an old or bloated base full of known CVEs. A slim, current base image is the cheapest risk reduction available — less surface, fewer libraries, fewer flaws.
  • Privileged and root containers. A container running as root, or with privileged or host-mounting flags, turns a single application compromise into a foothold on the node. This is least privilege at the workload level — most containers never need root, and dropping it shrinks the blast radius dramatically.
  • Secrets baked into images. A hard-coded API key or token in an image layer is a credential-hygiene failure that ships everywhere the image does and survives in the layer history even after you "remove" it. Secrets belong in a secrets manager, injected at runtime.
  • Over-permissive Kubernetes RBAC and service accounts. A pod's mounted service-account token is a non-human identity — and the default is often far more access than the workload needs. An over-scoped token is a leaked-credential incident waiting for one compromised container.
  • Flat pod networking. By default everything can talk to everything, so one compromised pod reaches the whole cluster. Network policies are segmentation applied inside the cluster — the same blast-radius logic, one layer down.

The lean baseline

A small team can cover the real risks with a short, enforceable set of practices:

  • Scan images in the pipeline. Wire a container-image scanner into your secure build pipeline so a known-vulnerable image is caught before it deploys, not after. This is the shift-left instinct applied to the artifact you actually ship, and it connects directly to your software-supply-chain story — the image is part of your supply chain.
  • Run as non-root, drop capabilities. Make non-root the default, drop unneeded Linux capabilities, and forbid privileged pods. A policy that rejects privileged workloads at admission turns this from a code-review hope into an enforced control.
  • Keep secrets out of images. Inject them at runtime from a secrets manager; never bake them into a layer.
  • Scope RBAC and service-account tokens tight. Give each workload the narrowest least-privilege role it needs, and don't mount the default token where it isn't used — bringing pods into the same machine-identity discipline as the rest of your environment.
  • Patch the images, not just the running container. A container is immutable; you don't patch it in place, you rebuild from an updated base and redeploy. That makes container patching a function of your patch cadence and rebuild pipeline, not a manual SSH session.

It belongs in the same program

A vulnerable image, a privileged pod, or an over-scoped service account is a finding routed to an owner with a severity set by what the workload can reach — the same exposure-first triage as everything else, with the same prioritization logic deciding what gets fixed first. And container risk drifts faster than almost anything: a base image that was clean last month has new CVEs today, a "temporary" privileged pod outlives the debugging session, a new service ships without a network policy. "Are our images current, our pods unprivileged, and our cluster identities scoped?" is a continuously verified dimension of your posture, not a launch-day audit.

It feeds the framework review, too. Assessors increasingly ask how you secure your deployment pipeline and runtime — SOC 2's change and operations criteria, ISO 27001's development and configuration controls. Your image-scan results, admission policies, and the findings you've closed are exactly the evidence they want, folded into the same continuous-evidence loop as the rest of your program.

One honest caveat: a platform can help you track your container and cluster posture — scan results, privileged workloads, identity scope — surface the gaps as findings, and keep that evidence current for an auditor; it organizes, tracks, and proves the work. It does not rebuild your images, harden your cluster, configure RBAC, make you compliant, or grant or guarantee any certification; the base-image choices, the admission policies, and the remediation are operational steps your team owns, and which obligations apply to you is a question for counsel.

Containers made the attack surface invisible: a stale base image, a root container, a baked-in secret, an over-scoped pod token. You don't need to master every Kubernetes knob — scan your images, run as non-root, keep secrets out, scope your identities, and rebuild to patch. Fold container risk into the program you already run, and the cluster stops being a blind spot.