NIST SP 800-190: The Container Security Standard, Explained

In brief

• NIST SP 800-190 groups container security into four control families: image, registry, orchestration, and runtime.
• Minimize image content, scan and sign artifacts, and generate an SBOM before anything ships.
• Lock down the registry with authentication, least privilege, and continuous scanning of stored images.
• Enforce Pod Security Standards, least-privilege RBAC, network segmentation, and admission control in orchestration.
• Detect runtime threats with Falco or eBPF monitors, seccomp/AppArmor, and RBOM®-based drift detection.
• RapidFort maps to 800-190 with RapidFort Analyzer, RapidFort Optimizer, RapidFort Continuous Compliance, and RapidFort Near-Zero CVE Images.

NIST SP 800-190 is the federal guidance for application container security, organized into four control families: image, registry, orchestration, and runtime. It tells organizations how to minimize image content, scan and sign artifacts, enforce least privilege, segment networks, and detect runtime threats. Adopting it reduces breach risk and eases FedRAMP, CMMC, and CIS alignment.

What Is NIST SP 800-190 and Why Does It Matter?

NIST SP 800-190, the "Application Container Security Guide" published by the National Institute of Standards and Technology, is the authoritative federal reference for securing containerized workloads. It does not invent new technology. Instead, it consolidates established best practices drawn from the CIS Benchmarks, the Kubernetes Pod Security Standards, and mainstream Linux hardening into one coherent lifecycle view.

The guide structures its recommendations around the journey of a container. An image is built from a base operating system and application code. That image is pushed to a registry where it is stored and distributed. An orchestrator such as Kubernetes then schedules the image onto nodes and connects it to networks and other services. Finally, the container executes at runtime, where it can be attacked. Each of those four stages is a control family with its own risks and required safeguards.

Why does this matter to practitioners? A container packages application code together with a full user-space operating system. A single vulnerable base image can therefore propagate risk across hundreds of deployments the moment it is reused. Compliance regimes including FedRAMP, CMMC, FIPS, and even commercial frameworks such as SOC 2 and PCI DSS expect teams to demonstrate container controls that map cleanly onto 800-190's four families. Treat the guide as an auditor-ready checklist rather than abstract advice.

What Does the Image Control Family Require?

The image is the root of trust, and the image family is where most risk enters the pipeline. The core controls are straightforward but demanding:

1. Minimize image content. Remove package managers, shells, and unused libraries. A smaller image has fewer packages, fewer CVEs, and a dramatically smaller attack surface.
2. Build from trusted, minimal base images. Prefer distroless or curated images over ad-hoc layers pulled from public sources.
3. Scan every image for known vulnerabilities and generate an SBOM. You cannot secure what you do not inventory. The Software Bill of Materials must capture every component before the artifact ships.
4. Sign images and verify provenance. Tools such as Sigstore and cosign let you attest that only reviewed, signed artifacts reach production.
5. Pin explicit versions and avoid the "latest" tag. Reproducible builds depend on immutable digests, not floating references.

This family is where RapidFort Analyzer delivers direct value: it produces a deep SBOM and applies exploit-aware applicability analysis, reducing vulnerability noise by roughly 20 to 25 percent compared with traditional scanners that report every theoretical CVE regardless of whether the vulnerable code path is present.

What Does the Registry Control Family Require?

Registries store and distribute the images your clusters run, so they are a high-value target. The guide calls for several concrete controls:

• Enforce authentication and least-privilege access to the registry. Every push and pull should be an authenticated, scoped action.
• Store images in a private registry and never pull from unknown public sources into production.
• Continuously scan stored images, and quarantine vulnerable or unsigned artifacts automatically.
• Use immutable tags or content digests to prevent accidental or malicious overwrites.
• Encrypt registry storage at rest and replicate with integrity checks.

A registry that is open, unmonitored, or silently overwritable undermines every control applied earlier in the build. Continuous scanning here closes the gap between a clean build and a later-disclosed CVE.

What Does the Orchestration Control Family Require?

Orchestrators such as Kubernetes schedule containers, assign identities, and wire up networking, which makes them privileged attack paths. NIST SP 800-190 maps the orchestration family to these controls:

• Enforce the Pod Security Standards restricted profile. No privileged pods, no shared host namespaces, and no privilege escalation.
• Apply least-privilege RBAC. Scope every service account narrowly and avoid cluster-admin bindings for workloads.
• Segment networks with default-deny NetworkPolicies so pods cannot freely reach one another.
• Use admission control with OPA Gatekeeper or Kyverno to reject non-compliant workloads before they are admitted.
• Encrypt etcd and enable audit logging so cluster activity is both protected and reviewable.

These controls turn the cluster from an open execution environment into an enforced security boundary. Policy engines like OPA and Kyverno are complementary to, not competitors with, image-level hardening: they stop misconfigured or over-privileged workloads from ever starting.

What Does the Runtime Control Family Require?

Runtime is where a theoretical vulnerability becomes a real intrusion. The runtime family focuses on detecting and containing threats as containers execute:

• Deploy runtime detection with Falco or other eBPF-based monitors to catch anomalous syscalls, file writes, and network behavior.
• Enforce seccomp, AppArmor, and read-only root filesystems to constrain what a compromised process can do.
• Drop Linux capabilities and run as non-root wherever possible.
• Monitor for drift from the known-good RBOM® (Runtime Bill of Materials) to surface unexpected process execution.
• Alert on and respond to unexpected outbound connections or privilege changes.

Runtime visibility is the feedback loop that proves your earlier controls actually hold. An RBOM® produced by runtime profiling shows which components execute in practice, exposing the unused packages you can safely strip from the next build.

How Does RapidFort Map to NIST SP 800-190?

RapidFort Platform aligns cleanly to all four control families without requiring code changes, OS changes, or pipeline modifications:

• RapidFort Analyzer maps to the image family. It performs deep image analysis and produces a complete SBOM, then applies CVE applicability so you know which vulnerabilities are actually reachable.
• RapidFort Optimizer maps to the image and runtime families. Using runtime awareness, it auto-hardens images and rebuilds drop-in replacements every 24 hours with Light, Standard, or Aggressive presets, eliminating up to 99.9 percent of CVEs and up to 90 percent of attack surface.
• RapidFort Continuous Compliance maps to continuous validation across all families. It runs OpenSCAP-based compliance checks against STIG, CIS, NIST, and custom baselines, detects configuration drift, and exports audit-ready evidence in JSON, CSV, HTML, and XML.
• RapidFort Images, which are near-zero CVE, map to the image and registry families. Tens of thousands of hardened images for Alpine, Debian, UBI, and Ubuntu LTS (including STIG and FIPS variants) are rebuilt every 24 hours, giving teams a trusted source that already meets 800-190-aligned expectations.

Together, these capabilities let teams move from a detect-and-alert posture to an eliminate-at-the-source posture, which is the essence of the RapidFort tagline: eliminate attack vectors at the source.

FAQ