Container hardening means reducing risk at every layer a container touches: the image, the registry that stores it, the orchestrator that schedules it, the runtime, and the host. NIST SP 800-190 organizes these risks and countermeasures. Begin with trusted, minimal, regularly rebuilt images and policy gates in the build.
Why do containers need their own guidance?
NIST's Application Container Security Guide describes containers as a form of operating system virtualization combined with application packaging. They are portable and automatable, which is the appeal. It also means a bad image can be copied everywhere quickly.
NIST points out that traditional vulnerability tools make assumptions about long-lived hosts and update habits that are misaligned with a containerized model, and that such tools often cannot detect vulnerabilities inside containers, leading to a false sense of safety. Containers need tools that understand images and pipelines.
What does the guide cover?
Its countermeasure sections are organized by layer.
Images. Vulnerabilities, configuration defects, embedded malware, embedded clear text secrets and the use of untrusted images. NIST says to maintain a set of trusted images and registries and allow only images from that set to run. It gives examples of embedded secrets as connection strings, SSH private keys and X.509 private keys, which have no business inside an image.
Registries. Insecure connections, stale images and weak authentication and authorization.
Orchestrators. Unbounded administrative access, unauthorized access, poorly separated container network traffic, mixing workloads of different sensitivity, and node trust.
Containers at runtime. Runtime software vulnerabilities, unbounded network access, insecure runtime configuration, application vulnerabilities and rogue containers.
Host operating systems. Large attack surface, shared kernel, component vulnerabilities, improper user access rights and file system tampering.
What are the highest value steps?
NIST recommends vulnerability management that covers the whole life of an image, from the start of the build through registries to runtime, with visibility into every layer, not only the base layer, and policy-driven enforcement. Its example is a rule in the build process that stops images with vulnerabilities above a chosen CVSS rating from moving forward.
For configuration, it advises running images as non-privileged users and using base layers from trusted sources, updated often, preferring minimal technologies to reduce attack surface. For the runtime, it says to automate compliance with container runtime configuration standards, and mentions that point-in-time scanning does not scale, so continuous assessment and enforcement are better. It encourages mandatory access control such as SELinux and AppArmor, and at a minimum the runtime's default seccomp profile, with extra profiles for high-risk apps.
A constructed example
A team of 30 ships 12 microservices. Each service builds from a different base image pulled from a public registry. They pick one minimal base, rebuild it weekly in their own pipeline, and store it in a private registry. The build fails if the image runs as root or contains a file matching a private key pattern, and fails on high severity vulnerabilities that have a fix. The cluster admission rule allows only images from the private registry. A month later, a developer pushes an image built from an unknown base, and the cluster rejects it before it starts. The hardening work took about three weeks, and the next audit question, where did this image come from, has an answer.
How to check or apply this
- Choose a small set of approved base images and rebuild them on a schedule.
- Scan every layer in the build and block images above a chosen severity when a fix exists.
- Check configuration: non-root user, no embedded secrets, no unneeded packages.
- Run a private registry with authentication, encrypted connections and cleanup of stale images.
- Enforce at the cluster that only trusted registries and images may run.
- Limit network access from containers to what each service needs.
- Turn on default seccomp and a mandatory access control profile.
- Keep the host OS minimal and patched, and separate workloads by sensitivity.
- Keep a software bill of materials for each image.
Safeguard's SBOM and dependency scanning and its policies and gates can cover the application dependency part of steps 2 and 9. Base operating system and cluster controls need their own tooling.
Quick check
Is a container a security boundary?
Only partly. Containers share the host kernel, which NIST lists as a host risk, so isolation depends on configuration and host hardening.
Where should secrets live?
Outside images. NIST warns about embedded clear text secrets such as private keys and connection strings. Inject them at runtime from a secrets store.
Sources
Last reviewed: 18 October 2026.
