NIST SP 800-190 sorts container security risk into five areas: images, registries, orchestrators, containers and the host operating system. Each has its own failure modes and its own countermeasures. Using the five areas as a checklist keeps a container program from covering only the image scan.
What is a container, in NIST's terms?
NIST describes application container technologies as a form of operating system virtualization combined with application software packaging. They give a portable, reusable and automatable way to package and run applications. The publication explains the security concerns that come with them and gives recommendations for handling those concerns.
One point recurs: containers share the host kernel. Isolation is weaker than a virtual machine, so what runs on the host and how it is configured matters more.
What are the five risk areas?
The guide's table of contents lists the risks in each area.
Image risks. Image vulnerabilities, image configuration defects, embedded malware, embedded clear text secrets, and use of untrusted images. This is the supply chain end: what you built from and what is inside.
Registry risks. Insecure connections to registries, stale images in registries, and insufficient authentication and authorization restrictions. A registry is where images are trusted by default, so it needs access control and cleanup.
Orchestrator risks. Unbounded administrative access, unauthorized access, poorly separated inter-container network traffic, mixing of workload sensitivity levels, and orchestrator node trust.
Container risks. Vulnerabilities within the runtime software, unbounded network access from containers, insecure container runtime configurations, application vulnerabilities, and rogue containers.
Host OS risks. Large attack surface, shared kernel, and related host issues.
The guide also lists countermeasures for each area and for hardware, and sample threat scenarios: exploit of a vulnerability within an image, exploit of the container runtime, and running a poisoned image.
What does NIST say about the host?
NIST recommends container-specific host operating systems instead of general-purpose ones to reduce attack surfaces. It describes one as a minimalist OS designed only to run containers, with other services and functionality disabled and with read-only file systems and other hardening practices. Attack surfaces are typically much smaller than on a general-purpose host, so there are fewer opportunities to attack and compromise it. NIST adds a caution: even container-specific host operating systems will still have vulnerabilities over time that require remediation.
It also notes that security tools should take the immutable nature of containers and images into account, to give more actionable and reliable results.
A constructed example
A team builds an image from a public base, adds an application and pushes it to a shared registry. Three months later a new vulnerability is published in a library in the base layer. The image has not changed, so no pipeline rebuilt it, and it is still running in six places. The registry also allows any developer account to push, so a mistaken push overwrites the production tag. Two of the five areas, image and registry, failed with no attacker involved: stale content and loose access.
How to check or apply this
- Images. Build from small, known base images. Scan for vulnerabilities and embedded secrets at build time and on a schedule afterward, since new vulnerabilities appear after the build.
- Registries. Require authentication, restrict who can push, use encrypted connections, and delete stale images.
- Orchestrator. Give administrators and workloads only the access they need, and separate workloads with different sensitivity.
- Containers. Limit network access, drop unneeded privileges, and keep the runtime updated.
- Host. Prefer a minimal, container-focused host OS, keep it patched, and treat the shared kernel as a shared fate.
- Inventory. Keep a software bill of materials for each image so you can answer "where is this library running?" within minutes.
- Runtime. Know which vulnerable code is actually reachable in your application, so you fix what matters first.
Safeguard supports this at the supply chain end with SBOM and dependency scanning plus reachability analysis, which helps you rank image findings by whether your code can call the vulnerable path.
Quick check
Is scanning images enough for container security?
No. It covers only image risks. Registry access, orchestrator permissions, runtime configuration and the host OS each need their own controls.
Why do containers raise host security concerns?
Because containers share the host kernel. A weakness in the host or runtime can affect every container on it.
Sources
- NIST SP 800-190, Application Container Security Guide, fetched 18 October 2026, including the full text of the publication.
Last reviewed: 18 October 2026.
