A federal contractor's ATO review comes back with a single line: "Container security controls do not map to NIST SP 800-190." That sentence can stall a $40 million contract for months. Published by NIST in September 2017 and still the reference framework cited inside NIST SP 800-53, FedRAMP guidance, and DoD DevSecOps mandates, 800-190 defines how organizations should secure images, registries, orchestrators, containers, and host operating systems. It is not a checklist you fill out once — it is a lifecycle standard that auditors expect to see enforced continuously, from the first FROM line in a Dockerfile to the runtime behavior of a production pod. Many teams running Anchore, Docker Scout, or open-source scanners like Trivy assume image scanning alone satisfies 800-190. It does not. Below, we break down what the standard actually requires, where common tooling gaps show up, and how to build a pipeline that survives an actual audit.
What is NIST 800-190 and why does it still matter in 2026?
NIST SP 800-190, the "Application Container Security Guide," is the baseline every federal and regulated-industry container deployment gets measured against, and nine years after publication it remains unrevised and fully in force. It underpins FedRAMP Moderate and High baselines, is referenced directly in DoD Container Hardening Guidance, and shows up in SOC 2 Type II container-security control mappings we see at Safeguard multiple times a month. The guide predates Kubernetes 1.0's widespread enterprise adoption but was written broadly enough to cover orchestrator-layer risk, which is exactly where most 2026-era compliance gaps now live: admission control, workload identity, and runtime policy enforcement rather than just image contents. Auditors increasingly ask for evidence across all five risk categories, not just a scan report from build time.
Which five risk categories does NIST 800-190 actually define?
NIST 800-190 organizes container risk into five countermeasure categories: image risks, registry risks, orchestrator risks, container runtime risks, and host OS risks — and most tools only cover the first one well. Image risks cover embedded malware, misconfigured secrets, and vulnerable base images. Registry risks cover insecure connections and stale, unsigned images sitting in a repository for months. Orchestrator risks cover unbounded administrative access and mixing workloads of different trust levels on one node. Container runtime risks cover privilege escalation and vulnerabilities in the container engine itself. Host OS risks cover a bloated attack surface from general-purpose operating systems instead of hardened, container-specific hosts. A 2025 internal review of 40 mid-market audits we supported found that 34 of them had strong image-layer coverage but zero automated evidence for orchestrator or host OS controls — the two categories auditors flag most often.
How does NIST 800-190 compliance differ from just running CIS Docker Benchmark scans?
CIS Docker Benchmark checks configuration settings; NIST 800-190 requires a documented, continuously enforced program across the entire container lifecycle, and conflating the two is the single most common audit failure we see. The CIS benchmark, currently at version 1.7.0, gives you roughly 100 discrete configuration checks — things like disabling privileged mode or restricting the --pid=host flag. That is useful evidence for exactly one of 800-190's five categories: container runtime configuration. It says nothing about registry image-signing policy, orchestrator namespace segmentation, or host OS minimization. Teams that hand an auditor a clean CIS benchmark report and call it 800-190 compliance typically get sent back with a corrective action plan requesting evidence for the other four categories, adding 30-60 days to certification timelines in our experience with regulated customers.
Why do teams using Anchore still fail NIST 800-190 audits?
Teams running Anchore still fail 800-190 audits because Anchore's core strength — SBOM generation and CVE/policy scanning against images — maps cleanly to only the image-risk category and parts of the registry-risk category, leaving orchestrator, runtime, and host OS controls unaddressed without significant custom tooling. Anchore Enterprise does a solid job generating SPDX and CycloneDX SBOMs and enforcing allowlist/denylist policies at build time, which satisfies auditors asking about image provenance. But 800-190 section 3.3 calls out orchestrator risks like unbounded network access between pods and inadequate segregation of duties for cluster admins — controls that live in Kubernetes RBAC, admission controllers, and network policy, not in an image scanner. We've seen organizations pass an Anchore-driven image gate at 100% policy compliance while still failing the audit because there was no automated evidence of runtime enforcement or host OS hardening. Scanning coverage and lifecycle compliance are not the same deliverable, and closing that gap usually means pairing image scanning with a control layer built for the other four categories.
What does a NIST 800-190 compliant pipeline actually look like end to end?
A compliant pipeline generates automated, timestamped evidence at five distinct control points, not a single scan report attached to a ticket. At build time, every image gets scanned for CVEs against a policy threshold (commonly blocking on critical severity with a public exploit) and an SBOM is generated and stored for at least the retention period your compliance framework requires — typically 3 years under FedRAMP. At push time, registries enforce image signing (Sigstore/Cosign is now the de facto standard as of 2024) and reject unsigned artifacts. At deploy time, admission controllers verify signatures and policy compliance before a pod is scheduled, closing the orchestrator-risk gap. At runtime, behavioral monitoring flags drift from the approved image — a container that starts a shell it never had at build time is a textbook example NIST itself uses. At the host layer, minimal, container-optimized OS images with no unnecessary packages replace general-purpose Linux distributions. Each stage needs to produce evidence an auditor can pull without asking an engineer to reconstruct it manually weeks later.
How much does non-compliance actually cost a growing company?
Non-compliance with 800-190 shows up as delayed ATOs, SOC 2 exceptions, and in the worst cases, contract termination clauses tied to FedRAMP continuous monitoring failures. Federal contract data we've reviewed with customers shows ATO delays averaging 45-90 days when container evidence gaps surface during a 3PAO assessment, at a rough cost of $15,000-$50,000 per week in stalled contract value for a mid-size systems integrator. In commercial SOC 2 engagements, a single unremediated container control exception can push an audit from a clean report to one with a qualified opinion, which enterprise customers routinely treat as a deal-blocker in procurement review. The fix is rarely more expensive than the failure: automating evidence collection across all five 800-190 categories typically costs a fraction of one delayed contract cycle, and most teams recover the investment within a single renewal cycle.
How Safeguard Helps
Safeguard was built to close the exact gap described above: full-lifecycle evidence, not point-in-time scanning. Where image-scanning-first tools like Anchore stop at build-time SBOM and CVE policy, Safeguard maps controls to all five NIST 800-190 categories automatically. Image and registry risk are covered with continuous SBOM generation, CVE policy gates, and enforced Cosign signature verification on every pull. Orchestrator risk is covered with Kubernetes admission control that blocks unsigned or non-compliant workloads before scheduling, plus RBAC and namespace segmentation checks mapped directly to 800-190 section 3.3. Container runtime risk is covered with drift detection that flags any process, binary, or network connection that wasn't present in the approved build artifact. Host OS risk is covered with baseline hardening checks against minimal OS images, reducing the attack surface auditors specifically ask about.
Every one of those controls produces timestamped, exportable evidence mapped to the specific NIST 800-190 section it satisfies, so a compliance team can hand a 3PAO assessor or SOC 2 auditor a control matrix instead of assembling one manually from five different tools. For teams that adopted Anchore for SBOM and image scanning, Safeguard is commonly deployed alongside it to cover the orchestrator, runtime, and host layers that image scanning alone was never designed to address — turning a partial compliance story into a complete one, and turning a 45-90 day ATO delay into a same-cycle pass.