Containerization packages an application with the libraries it needs into an image that runs as an isolated process on a shared host kernel. It is lighter than a virtual machine and easy to ship. NIST SP 800-190 groups the risks into five areas: images, registries, orchestrators, containers and the host operating system.
How does a container isolate things?
NIST describes isolation built from namespaces, which give each container its own view of processes and networking, resource allocation, which limits how much of the host a container can use (control groups on Linux), and filesystem virtualization, which lets containers share storage without reading each other's data. The important word is shared. Containers use the host kernel.
NIST states the consequence plainly: container runtimes give strong software-level isolation, but a shared kernel results in a larger inter-object attack surface than hypervisors, so isolation is not as high as a hypervisor provides.
What are the five risk areas?
Images. An image is a static archive of everything the app runs on, so its components go stale. NIST notes that an image built from fully current components can be free of known flaws for days or weeks and then not. Unlike hosts patched in place, containers must be fixed upstream in the image and redeployed. Other image risks are configuration defects, embedded malware, embedded clear text secrets such as connection strings and private keys, and use of untrusted images.
Registries. Insecure connections, stale images that linger, and weak authentication or authorization on who may pull and push.
Orchestrators. Unbounded administrative access, unauthorized access, poorly separated network traffic between containers, mixing workloads of different sensitivity, and weak trust between nodes. One example NIST gives is a single compromised host leading to the whole cluster if the same key pairs authenticate every node.
Containers. Runtime software vulnerabilities, with container escape as the dangerous case. Unbounded network access: by default in most runtimes, containers can reach each other and the host over the network, so a compromised container can scan for the next target.
Host OS. Large attack surface, shared kernel, vulnerable components and improper user rights. NIST notes container-specific operating systems have a much smaller attack surface than general-purpose ones.
What does this look like in practice?
Constructed example. A team builds an image from a public base layer, copies in the app, and bakes a database password into an environment file in the image. The image is pushed to a registry that any developer account can read. Three NIST risks in one build: unknown provenance, embedded secret, weak registry access. The app itself might be perfect.
Another: the cluster runs a payment service and a marketing site in the same namespace on the same nodes, with open pod-to-pod traffic. A flaw in the marketing site gives a foothold one hop from payments.
How to check or apply this
- Build from minimal, known base images, and record where each came from.
- Rebuild and redeploy on a schedule so base layers pick up fixes. Do not patch inside running containers.
- Keep secrets out of images. Inject them at runtime from a secret store.
- Scan images and the packages inside them before they reach the registry, and again while they sit there.
- Restrict who can push to and pull from registries, and use encrypted connections.
- Run containers as non-root, drop capabilities you do not need, and limit CPU and memory.
- Separate workloads of different sensitivity onto different nodes or clusters, and restrict traffic between pods and outbound.
- Patch the host and runtime, and use a minimal host OS where you can.
Where Safeguard fits
The image risk is largely a dependency risk. Safeguard's SBOM and dependency scanning and reachability analysis help you see which vulnerable packages in your software are actually reachable, so rebuild effort goes to the findings that matter. Scanning does not replace the runtime and host controls above.
Quick check
Are containers less secure than virtual machines?
They isolate differently. Containers share a kernel, so NIST says their isolation is not as strong as a hypervisor's. They can still be run securely, with extra care on hosts and network paths.
Where should I fix a vulnerable library in a container?
In the image, then redeploy. NIST notes that updates are made upstream in the images, not in the field on running hosts.
Sources
Last reviewed: 18 October 2026.
