NIST SP 800-190 Checklist: 18 Container Security Controls for Compliance

Your container environment passes every automated scan. The pipeline is green. No HIGH-severity CVEs. Yet something keeps you up at night: are you really secure, or are you just passing the wrong checks?

This is where NIST SP 800-190 comes in. Unlike generic compliance frameworks that barely acknowledge containers exist, NIST 800-190 is the only major published standard designed specifically for containerized applications. Published by the National Institute of Standards and Technology, it maps 18 controls across five critical domains that directly address the unique attack surface of containers.

The Problem: Most Container Security Standards Were Not Built for Containers

ISO 27001 does not know what a Dockerfile is. SOC 2 has never heard of a container registry. These frameworks are excellent for general information security, but they miss the container-specific risks that cause real breaches today: base images pulling in Log4j months after the fix, privileged containers with kernel access to the host, registries leaking private images because someone left anonymous pull enabled, and runtime attacks exploiting shared kernel namespaces.

According to industry research, over 60% of organizations now run containerized workloads in production, yet fewer than one in three have adopted a container-specific security framework. The gap between general compliance and real container security is where breaches happen. NIST SP 800-190 was designed specifically to close this gap.

What Is NIST SP 800-190?

NIST SP 800-190, formally titled the Application Container Security Guide, provides comprehensive security guidance for the entire container lifecycle. Instead of treating containers as just another application deployment, it recognizes containers as a distinct architectural paradigm with unique security challenges: shared operating system kernels, image supply chain risks, ephemeral runtimes, and orchestration-layer complexity.

The framework organizes 18 controls across five domains that map directly to real-world container operations: how you build images, where you store them, how you deploy and orchestrate them, how they run, and the infrastructure beneath them.

The 18 NIST 800-190 Controls: What You Actually Need to Implement

Rather than treating compliance as a checkbox exercise, think of these controls as a security roadmap. Each control addresses a specific risk that has caused real container security incidents. The five domains cover the full container lifecycle in order of operational flow.

Domain 1: Container Image Security (Controls 1-4)

Image security starts before you write a single line of application code. The base image you choose determines your entire attack surface. NIST 800-190 requires using minimal base images pinned to specific digests, scanning every image build for vulnerabilities, signing images to prevent tampering, and maintaining a structured remediation process for discovered CVEs.

The return on investment here is immediate. Pinning your FROM instruction to a specific digest instead of node:18 eliminates the risk of a compromised tag silently introducing malware into your production images. Running Trivy or Grype as a CI gate on every build catches vulnerabilities before they reach the registry.

Domain 2: Container Registry Security (Controls 5-8)

Your registry is the single source of truth for all container images in your organization. A compromised registry means every image pulled from it is suspect. NIST 800-190 mandates strict access controls using IAM roles and service accounts, automated image scanning upon push, encrypted communication for all registry traffic, and backup and disaster recovery procedures.

One of the most overlooked controls here is blocking image uploads that contain HIGH or CRITICAL vulnerabilities at the registry level. Instead of trusting developers to remember to scan, enforce the policy at the registry — if an image fails the scan, the push itself fails.

Domain 3: Container Orchestration Security (Controls 9-12)

Kubernetes is the default orchestrator for most organizations, and its complexity creates an enormous attack surface. NIST 800-190 requires hardening the orchestrator configuration against the CIS Kubernetes Benchmark, implementing network segmentation with policies, securing secret management with external managers like HashiCorp Vault, and enforcing admission controls using OPA/Gatekeeper or Kyverno.

Secret management is particularly critical here. A surprising number of teams still pass database credentials as environment variables, visible to anyone with kubectl describe pod access. NIST 800-190 requires secrets to be encrypted at rest, automatically rotated, and never exposed in environment variables.

Domain 4: Container Runtime Security (Controls 13-15)

Runtime is where theory meets practice. Your image may be perfectly hardened, but if the container runs as root with all Linux capabilities, your security investment is wasted. NIST 800-190 requires containers to run as non-root users, drop all unnecessary Linux capabilities, and implement runtime monitoring to detect anomalous behavior.

Falco or Tracee for runtime detection, seccomp profiles to restrict system calls, and read-only root filesystems are implementation patterns that directly address these controls. The principle is simple: give the container exactly what it needs to run its application and nothing more.

Domain 5: Host OS Security (Controls 16-18)

Container security is ultimately host security. A compromised host kernel breaks isolation for every container running on it. NIST 800-190 requires hardening the host operating system, isolating container resources using kernel namespaces and cgroups with proper limits, and maintaining comprehensive audit logging for host-level security events.

Container-optimized operating systems like Flatcar Container Linux or Bottlerocket significantly reduce the attack surface by stripping away unnecessary packages and read-only mounting the root filesystem.

Common Mistakes Teams Make with NIST 800-190

The most common mistake is treating NIST 800-190 as a one-time compliance project rather than an ongoing security practice. Container images change constantly — every build introduces new packages, new base images, and potentially new vulnerabilities. Compliance must be continuous, not point-in-time.

Another frequent error is focusing exclusively on image scanning while ignoring orchestration and runtime controls. A perfectly scanned image running as root with privileged access to the host kernel is not secure, regardless of how few CVEs it has.

How ShieldOps Automates NIST 800-190 Compliance

ShieldOps AI was built to operationalize frameworks like NIST 800-190 without requiring a dedicated compliance team. Our platform connects directly to your CI/CD pipeline and container registries, providing automated scanning at every stage of the container lifecycle.

Every Dockerfile submitted to ShieldOps is analyzed against NIST 800-190 controls: FROM instructions checked for digest pinning, USER directives verified for non-root execution, capability drops validated, and health checks confirmed. The results map directly to the 18 controls, showing you exactly which controls pass and which need attention.

For teams running Kubernetes, ShieldOps validates pod configurations against the restricted pod security standard and provides admission control recommendations that align with NIST orchestration controls.

Conclusion

NIST SP 800-190 provides the only published framework designed specifically for container security. Its 18 controls across five domains address the real attack surface of modern container environments — from the base image you choose to the host OS beneath your orchestrator.

The goal is not checkbox compliance; it is a genuinely secure container environment. Start with image security controls, implement runtime hardening, and build continuous compliance into your pipeline. The 18 controls are your roadmap, not your destination.

Frequently Asked Questions

Is NIST 800-190 mandatory for container security?

NIST 800-190 is not legally mandatory in the way PCI DSS is for payment data. However, it is increasingly required by federal contracts and enterprise security audits. Many large organizations now mandate NIST 800-190 compliance for any containerized workload in their infrastructure.

How does NIST 800-190 differ from CIS benchmarks?

CIS benchmarks provide technical configuration guidelines for specific technologies like Docker and Kubernetes. NIST 800-190 provides a higher-level security framework that covers the entire container lifecycle. The two complement each other — CIS benchmarks help implement specific NIST controls at the technical level.

Can small teams achieve NIST 800-190 compliance?

Yes. While the framework lists 18 controls, many can be automated with tools like ShieldOps. Small teams should prioritize controls 1-4 (image security) and 13-15 (runtime security) first, as these address the highest-risk areas with the least operational overhead.

How often should NIST 800-190 controls be reviewed?

Container environments change constantly. Images are rebuilt, registries accumulate new images, orchestrator configurations drift. NIST 800-190 compliance should be verified continuously, not quarterly. Automated compliance tooling is strongly recommended for this reason.

What happens if an image fails NIST 800-190 controls?

In a properly configured pipeline, the deployment should be blocked until the control passes. Blocking builds for HIGH and CRITICAL vulnerabilities while filing informational tickets for LOW findings is a practical severity-based approach.