A container image is a frozen snapshot. It does not get patched, it gets rebuilt, and almost everything that makes container security different follows from that.
The short answer
Container security covers three separate things: the image you build, the container running from it, and the orchestrator scheduling them. Each fails differently. Images carry inherited vulnerabilities, running containers are usually over-privileged, and orchestrators are commonly deployed with permissive defaults that nobody revisits.
Container security that stops at image scanning has covered one layer of three.
On this page
The three container security layers
| Layer | What goes wrong |
|---|---|
| Image | Inherited vulnerabilities from the base image, unnecessary packages, embedded credentials, and no record of what is inside |
| Runtime | Containers running as root, granted more privilege than the workload needs, or able to reach every other container on the network |
| Orchestrator | Permissive defaults, exposed control plane, over-broad service accounts and no segmentation between workloads |
Images are not patched
The habit that shapes container security most is one borrowed from servers, where it no longer applies.
This inverts how most teams approach container security, because it inverts patch management. There is nothing to update inside a running container, and updating one by hand produces a machine that no longer matches its image, which is worse than leaving it alone.
Scanning at build is not enough on its own
A clean scan proves the image had no known vulnerabilities on the day it was created. Vulnerabilities are disclosed continuously, so the same image is quietly less safe every week it stays deployed, without anything changing. Two habits close the gap. Rescan images already in your registry on a schedule rather than only at build, and rebuild long-lived services periodically even when the application code has not changed, so the base layer picks up fixes.
Where container security findings come from
| Source | What it means for the fix |
|---|---|
| The base image | Usually the largest share by a wide margin. A general-purpose base carries a full operating system, most of which your application never calls. The fix is choosing a smaller base, not repairing anything |
| System packages | Tools added during the build for convenience, such as shells and package managers, which remain in the shipped image and are useful to an attacker |
| Application dependencies | The libraries your code imports, which is the same problem SCA addresses outside containers |
| Your own code | Typically the smallest share of reported findings, and the part SAST covers |
The practical consequence surprises people. Moving from a general-purpose base image to a minimal or distribution-free one frequently removes most reported vulnerabilities in a single change, because the packages carrying them are simply no longer present. That is usually a better first move than working through a findings list, and a software bill of materials is what tells you which layer each finding came from.
Runtime and orchestrator risks
Container security beyond the image is mostly a question of what a workload is permitted to do once it is running.
| Risk | Why it matters |
|---|---|
| Running as root | The default in many images. If the application is compromised, the attacker holds root inside the container and is one weakness away from the host |
| Privileged containers | Granted for convenience during debugging and rarely removed. Effectively removes the boundary the container was providing |
| Secrets in environment variables | Visible to anyone who can inspect the container and frequently printed into logs. See secrets management |
| Flat internal networking | By default every workload can reach every other. One compromised container then has the whole cluster available to it |
| Exposed control plane | An orchestrator API or dashboard reachable from the internet is a direct route to scheduling anything you like |
| Over-broad service accounts | Default accounts often carry more cluster rights than the workload needs, which turns a single compromise into cluster access |
Most of these are defaults rather than mistakes, which is why they survive so long. Nobody chose them, so nobody reviews them, and container security work at this layer is largely a matter of going through the settings once.
Where Osto fits
Osto has no container runtime agent and no Kubernetes posture module. If you are running a large orchestrated estate and need admission control, pod-level policy and runtime enforcement inside the cluster, that is a dedicated product and this is not it.
What Osto covers is the parts of container security that sit outside the cluster boundary, which for most teams running a handful of services is the majority of the real exposure. Dependency scanning and SBOM generation handle the libraries inside your images and give you the inventory to answer which services are affected when a component is found vulnerable. Cloud posture management covers the infrastructure the cluster runs on, including the managed service configuration, the network rules around it and the roles attached to nodes.
Access to the control plane is handled through zero trust access, so the orchestrator API is reachable only from a managed device rather than from the internet, which removes the exposed control plane row above rather than monitoring for it. Identity and access management narrows what the roles around the cluster can reach, and events land in one SIEM alongside everything else. That evidence supports the configuration and vulnerability management expectations in SOC 2, ISO 27001 Annex A and PCI DSS.
Platform walkthrough
Cover what sits around the cluster
Dependency scanning and SBOM for your images, cloud posture for the infrastructure, and zero trust access to the control plane.
Book a demoEvidence from live controls · 200+ frameworks mapped · One platform, everything
Frequently asked questions
What is container security?
Protecting three layers: the image being built, the container running from it, and the orchestrator scheduling them. Each has distinct failure modes, and covering only image scanning leaves two uncovered.
How do you patch a container?
You do not. Update the base image, rebuild and redeploy. Patching inside a running container produces something that no longer matches its image, which will be replaced on the next deployment anyway.
Why do image scans report so many vulnerabilities?
Most come from the base image rather than your code. A general-purpose base ships a full operating system your application never uses. Switching to a minimal base often removes the majority of findings in one change.
Should containers run as root?
No, although many images default to it. Running as a non-root user means a compromised application does not hold root inside the container, which removes the easiest path toward the host.
Is container security just image scanning?
No. A build-time scan reflects the day the image was built. New vulnerabilities are disclosed continuously, so rescan images in your registry on a schedule and rebuild long-lived services periodically even when the code has not changed.