A secure container image is built from a trusted base, contains only what the application needs, has no embedded secrets, is scanned for known vulnerabilities, and is stored in a registry you control. NIST SP 800-190 treats these as the main image level risks and recommends managing them as a process.
What does NIST say about containers?
NIST SP 800-190, the Application Container Security Guide, was published in September 2017. Its abstract describes containers as operating system virtualization combined with application software packaging, a portable and automatable way to run applications. It explains the security concerns of containers and recommends ways to address them.
The guide splits risk by layer: images, registries, orchestrators, containers and the host operating system. For anyone building images, the image layer is the part you control directly.
What are the main image risks?
The guide names a small set of image risks. Read the document for the full text, but in summary they are these.
- Image vulnerabilities. An image bundles an operating system layer and libraries, and any of them can carry known flaws.
- Image configuration defects. Examples include running as an administrative user inside the container.
- Embedded malware. An image from an untrusted source can contain code you did not intend to run.
- Embedded clear text secrets. Keys and passwords baked into layers can be read by anyone who can pull the image.
- Use of untrusted images. Pulling an unknown image because its name looks right is the container version of running a downloaded script.
Notice that two of the five are about provenance, not code quality. Knowing where an image came from matters as much as scanning it.
Why do rebuilds matter more than patches?
Containers are meant to be immutable. You do not patch a running container, you build a new image and replace it. That makes the rebuild cadence the real patching policy. An image built eight months ago and never rebuilt carries eight months of unfixed base layer flaws, even if your own code never changed.
Set a rebuild schedule and also trigger a rebuild when a serious flaw lands in a base layer or a package you use.
A constructed example
Two teams ship the same service. Team A builds from a general purpose operating system image, installs build tools in the final image, and runs as root. Team B uses two stages, copies only the built output into a minimal base, and runs as a non-root user. A scan of each shows hundreds of findings for A and a short list for B. The difference is not cleverness. B shipped fewer packages, so there was less to flag and less for an attacker to use.
How to check or apply this
- Choose approved base images from sources you trust, and record which ones are allowed.
- Use multi-stage builds so compilers and package managers stay out of the final image.
- Run as a non-root user and avoid unnecessary privileges.
- Search image layers for secrets and move credentials to run-time injection.
- Scan images on every build and before deployment, and decide in advance which severities block a release.
- Store images in a private registry with access control, and restrict clusters to pull from it.
- Rebuild on a schedule, not only when someone remembers.
For the application dependencies inside the image, Safeguard scans the tree and applies policy gates in pull requests and pipelines. Layer by layer image scanning is a separate capability, so confirm what your current scanner covers.
Quick check
Should I patch a running container?
The guidance favors rebuilding and replacing the image. Patching in place breaks the idea that every running container matches a known image.
Is scanning enough?
No. Scanning finds known flaws. You also need trusted sources, minimal contents, no embedded secrets and a controlled registry.
Sources
Last reviewed: 18 October 2026.
