Container security became an urgent problem in 2015 for the most ordinary reason in enterprise technology: adoption outran governance. Docker had reached its first stable release the previous year, Kubernetes hit version 1.0 in July 2015, and development teams had found a packaging model that removed a category of friction they had lived with for a decade. Security teams found out later, which is the part of the story that repeats. The appeal was legitimate. A container image bundles the application and its dependencies into an artefact that runs the same way on a laptop, in a test environment and in production. That solved a genuine and expensive problem. It also quietly redistributed responsibility for the operating system layer from a platform team that patched things on a schedule to a developer who wrote one line at the top of a build file.
What changed underneath the security model
The pre-container model had clear boundaries. Infrastructure teams owned servers and virtual machines, applied patches on a cycle, ran vulnerability scans against known hosts, and maintained an inventory that was stable enough to be accurate. Containers broke each of those assumptions in turn. The base image became an uncontrolled dependency. A build file beginning with a public base image inherits everything in it, including whatever vulnerabilities existed when that image was published. Analyses circulating in 2015 suggested a substantial share of images available in public registries — including official ones — contained known high-severity vulnerabilities. The developer choosing that image was making a security decision without knowing it, using a mechanism no approval process covered. Patching inverted. You do not patch a running container; you rebuild the image and redeploy. That is a better model in principle and it requires a build pipeline that actually rebuilds on a cadence. Organisations without one ended up running images built eighteen months earlier, frozen at the vulnerability state of their build date, with no patch process touching them at all. Inventory became ephemeral. Containers start and stop constantly. Scanning tools built around persistent hosts either missed them or produced noise. Answering "what is running in production and what is in it" required tooling that mostly did not exist yet. Isolation was weaker than it looked. Containers share the host kernel. The isolation comes from namespaces and control groups rather than from a hypervisor boundary, and many teams reasoned about containers as if they were lightweight virtual machines. A kernel vulnerability, a privileged container, or a mounted host socket collapses that boundary — and the container escape vulnerabilities disclosed in the years afterwards confirmed the concern was not theoretical.
The defaults that caused most of the damage
The recurring findings in container assessments were rarely exotic. Processes running as root inside the container, because that is what happened if nobody specified otherwise, meaning any application compromise started with the highest privilege available in that context. Privileged mode used to make something work during troubleshooting and never removed, which effectively disables the isolation the container was providing. Secrets baked into images or passed as environment variables — database passwords, API keys, cloud credentials — where they persist in image layers, in registries, in build logs and in the output of routine inspection commands. The container runtime socket mounted into a container so it could orchestrate other containers, which grants control of the host. Registries without authentication or image signing, so there was no way to verify that the image deployed was the image that was built. Signing infrastructure arrived during 2015, and adoption of it lagged for years. And networking left open by default, with containers able to reach each other freely across an environment where the implicit assumption was that everything inside was trusted. None of these required sophistication to exploit and all of them were the product of defaults chosen for developer convenience rather than for production safety.
Why the answer had to be the pipeline
The important realisation — and the reason this period matters beyond its technology — is that the traditional security intervention point had disappeared. You cannot secure a container by inspecting it in production. It may exist for four minutes. The only durable control point is the build pipeline: what base images are permitted, what gets scanned, what fails the build, what gets signed, and what the cluster will refuse to run. That forced security teams into a place many were not organisationally equipped for. Instead of operating scanners and firewalls, the work became defining policy that executes inside a developer workflow — registry allowlists, admission controllers, image provenance rules and automated rebuild triggers. Teams that made that shift got ahead of the problem. Teams that tried to apply host-based processes to ephemeral workloads produced reports nobody could act on.
Practical Guidance for Container Security Assessment
- Maintain a curated set of approved base images and rebuild them on a schedule. A small number of hardened, regularly refreshed bases removes the largest single source of inherited vulnerabilities.
- Scan images in the pipeline and fail builds on defined severity thresholds. Scanning that produces advisory reports changes nothing; scanning that blocks a merge changes behaviour.
- Run containers as a non-root user and prohibit privileged mode in production. Enforce it at the cluster level with admission policy rather than relying on build-file discipline.
- Keep secrets out of images and environment variables entirely. Use a secrets manager with runtime injection, and scan build history for credentials that were committed before the policy existed.
- Require signed images and refuse unsigned ones at deployment. Provenance is the control that makes the rest of the pipeline meaningful.
- Rebuild and redeploy on a fixed cadence regardless of code changes. An image that has not been rebuilt in a year is an unpatched host with a modern name.
- Default to denied network paths between workloads. Explicit policy for what may talk to what, rather than a flat trusted network inside the cluster.
- Generate and retain a bill of materials for every image. When the next widely exploited library vulnerability is disclosed, the question will be which of your running workloads contain it, and the answer needs to take minutes.
The Regional Angle
Container adoption across the Gulf has followed a distinct path, and it shapes where the risk concentrates. The region skipped a generation of infrastructure in many organisations. Government digital programmes, banking modernisation and the rapid build-out of regional technology companies meant that new platforms were frequently designed cloud-native from the start rather than migrated from existing virtual machine estates. That is an advantage architecturally and a gap operationally: teams building on containers without a prior platform-operations tradition often have no established patching discipline to carry forward. The second factor is delivery model. A large share of regional enterprise systems are built and run by systems integrators, and container pipelines are frequently the integrator's rather than the client's. That creates specific questions that belong in an assessment: who owns the base images, whose registry holds them, whether the client can see scan results, what happens to the pipeline at contract end, and whether images built for one client are shared across an integrator's customer base. These are contract questions with security consequences, and they are usually unasked. Third, residency and sovereignty requirements interact with container platforms in ways teams underestimate. Managed registries, scanning services, CI runners and observability platforms may process image contents, build logs and runtime telemetry outside the country — which matters when a client is a bank, a government entity or a healthcare provider operating under UAE or Saudi residency expectations. The workload may sit in a local region while the pipeline around it does not. Finally, the regional talent market amplifies the knowledge concentration risk. Container platforms are typically built by a small number of specialists, and employment-linked residency means turnover is high. A cluster configured by someone who has left, with undocumented admission policies and hand-built pipeline steps, is a common regional finding. Documentation and infrastructure-as-code are security controls here, not just engineering hygiene.
The objection worth taking seriously
The fair counterargument is that containers made security better, not worse, and that the 2015 alarm was partly the security industry finding a new product category. There is real substance to this. Immutable infrastructure removes configuration drift, which was a chronic source of vulnerability on long-lived servers. Rebuilding from a declarative definition means the environment is reproducible and auditable in a way that hand-administered hosts never were. Minimal images have a dramatically smaller attack surface than a general-purpose operating system with a decade of installed packages. And forcing dependencies to be declared explicitly gave organisations visibility into their software composition that they simply did not have before. The honest assessment is that containers improved the ceiling and lowered the floor. An organisation with a mature pipeline, curated bases, signing and automated rebuilds achieves a security posture that was impractical with traditional servers. An organisation that adopted containers as a deployment convenience without any of that ends up worse off than it was, because the patching process that used to cover its servers no longer reaches anything. Which outcome you get is determined almost entirely by whether the build pipeline is governed. That was the real finding of 2015 and it has not changed.
Common Questions
Are containers less secure than virtual machines?
The isolation boundary is weaker, since containers share the host kernel while virtual machines have a hypervisor boundary. In practice the difference matters most for genuinely hostile multi-tenancy. For internal workloads, the larger determinant of security outcomes is pipeline discipline, not the isolation primitive — and where strong isolation is required, running sensitive workloads on separate node pools or using stronger runtime isolation is the usual answer.
How often should images be rebuilt?
On a fixed schedule independent of code changes — weekly or monthly for most estates — plus immediately on disclosure of a high-severity vulnerability in a base image or common dependency. The rebuild cadence is effectively your patch cadence, and treating it as an engineering preference rather than a security control is the most common failure.
What should an assessment look at first?
Three things: whether images run as root, whether secrets appear in images or environment variables, and how old the running images are. Those three findings predict the maturity of everything else and can be established in a day.
How do AI workloads change container risk?
They concentrate it. Model-serving images are large, dependency-heavy and frequently assembled from research code with permissive practices; GPU access often pushes teams toward elevated privileges; and model weights and prompt data inside containers create a data classification question that ordinary application images do not raise. The supply chain also gets longer — pulling a model artefact from a public hub at runtime is the same trust decision as pulling an unverified base image, made by teams who are not thinking about it that way.
Container Security Assessment — when workloads live for minutes, the build pipeline is the only control point that exists, so govern it or govern nothing.