Containers change where security controls have to sit: a vulnerable package, a hard-coded key or an over-privileged runtime setting is copied into every instance an image launches, and a shared kernel means one escape can reach every workload on the host. NIST SP 800-190, the Application Container Security Guide, is still the reference most auditors and federal programmes use to judge container security. This guide summarises what it requires across its five risk areas, how to implement and evidence it on current platforms such as Kubernetes, where it touches workload identity and secrets, and how it maps to SP 800-53, CSF 2.0 and ATT&CK. It is for platform, DevSecOps and cloud security engineers, and for assessors working against the publication.
Key takeaways
- SP 800-190 is from September 2017 and has not been revised. NIST lists no draft or revision as of October 2026, so read it as a stable risk model and pair it with newer guidance such as the SP 800-204 series for current tooling.
- Five components, five risks each. Images, registries, orchestrators, containers and host operating systems each have five named risks and matching countermeasures in sections 3 and 4.
- Security moves left into the pipeline. Vulnerability and configuration checks, signing and allowlisting happen before an image runs, with policy gates that block deployment.
- Secrets never belong in images. Section 4.1.4 says to inject them at runtime through the orchestrator or a secret manager, limited to the containers that need them.
- Separate by sensitivity. Group containers on hosts, networks and clusters by purpose and sensitivity so that a shared kernel never mixes sensitivity levels.
What it is and who it applies to
SP 800-190 was written by Murugiah Souppaya (NIST), John Morello and Karen Scarfone, and published as final on 25 September 2017 after two drafts that year. It describes containers as operating system virtualisation combined with application packaging, and explains the risks this creates and how to address them. It is technology-neutral: it says "orchestrator" rather than Kubernetes, though its examples map directly to Kubernetes, Docker and similar runtimes.
| Item | Status as of October 2026 |
|---|---|
| Current edition | SP 800-190 (final), 25 September 2017; no Rev. 1 or draft listed on the CSRC publication page or NIST's publication record |
| Executive summary recommendations | Six: adapt culture and processes; use container-specific host OSs; group containers by sensitivity; adopt container-specific vulnerability management; use hardware-based trust; deploy container-aware runtime defence |
| Related NIST work | SP 800-204 (microservices, August 2019) and SP 800-204D (software supply chain security in DevSecOps CI/CD pipelines, February 2024); NIST IR 8176 |
| Who uses it | US federal agencies and their cloud providers, regulated private sector teams, and assessors who need a neutral container baseline |
The SP 800-204 series fills gaps that 2017 could not cover: 800-204 itself addresses microservice security features such as authentication, service discovery and secure communication through API gateways or service meshes, and 800-204D addresses supply chain security inside CI/CD pipelines. Use 800-190 for the container risk model and those documents for service mesh and pipeline specifics. See the Microservices Security Guide.
Structure and key requirements
Section 3 names the risks and section 4 gives the countermeasures with matching numbers, so 3.1.4 (embedded clear text secrets) pairs with 4.1.4. Section 5 walks through three threat scenarios (a vulnerable image, a runtime exploit, a poisoned image) and section 6 covers the lifecycle from initiation to disposition.
| Component | Risks named in section 3 | Key countermeasures in section 4 |
|---|---|---|
| Images (3.1, 4.1) | Vulnerabilities; configuration defects; embedded malware; embedded clear text secrets; untrusted images | Pipeline-integrated scanning across all layers with policy gates (for example, block above a CVSS threshold); run as a non-root user; no SSH daemon or remote shell; malware monitoring; runtime secret injection; signed images and trusted image allowlists |
| Registries (3.2, 4.2) | Insecure connections; stale images; insufficient authentication and authorisation | Encrypted connections only; prune vulnerable images; immutable version tags and cautious use of "latest"; authentication for sensitive images and all writes, federated with existing directories; scoped push rights; audited access |
| Orchestrators (3.3, 4.3) | Unbounded administrative access; unauthorised access; poorly separated inter-container traffic; mixed workload sensitivity; orchestrator node trust | Least privilege per role; MFA and single sign-on for cluster-wide administrators; encryption at rest that works across nodes; separate virtual networks per sensitivity; pin workloads to hosts or clusters by sensitivity; secure node introduction, persistent node identity, mutual authentication |
| Containers (3.4, 4.4) | Runtime vulnerabilities; unbounded network access; insecure runtime configuration; application vulnerabilities; rogue containers | Patch runtimes and block deployment to unpatched ones; control egress; automate CIS Docker Benchmark style configuration checks; SELinux or AppArmor; default or custom seccomp profiles; behavioural runtime monitoring; read-only root filesystems; separate dev, test and production with RBAC; tie container creation to individual identities |
| Host OS (3.5, 4.5) | Large attack surface; shared kernel; host component vulnerabilities; improper user access rights; host file system tampering | Minimal container-specific OS with read-only file systems, or a hardened general-purpose OS per SP 800-123; no mixing of containerised and other workloads; patch or redeploy immutable hosts; audit host logins and privilege escalation; avoid host directory mounts |
| Hardware (4.6) | Software defences can be subverted below them | Measured boot with a hardware root of trust such as a TPM, extending trust through boot loader, kernel, runtime and images; address it in agreements where a cloud provider does not expose it |
How the 2017 terms translate to Kubernetes today
- Image policy gates (4.1.1, 4.1.5): admission control that rejects unsigned images or images with critical findings. See the Kubernetes Admission Control Guide.
- Insecure runtime configuration (4.4.3): privileged containers, host namespaces and host path mounts, which Kubernetes Pod Security Standards restrict at the Baseline and Restricted levels.
- Unbounded network access (4.4.2): default-deny NetworkPolicy plus egress control at the cluster boundary.
- Orchestrator least privilege (4.3.1): namespace-scoped RBAC roles instead of cluster-admin. See the Kubernetes RBAC Guide.
- Node trust (4.3.5): node bootstrap and kubelet certificates with authorisation that limits each node to its own pods.
Identity and NHI requirements
SP 800-190 predates the term non-human identity, but several of its countermeasures are identity controls, and container platforms are now among the densest concentrations of machine credentials in an organisation.
| SP 800-190 section | Identity it governs | Current practice |
|---|---|---|
| 3.1.4 and 4.1.4 Embedded secrets | Passwords, connection strings, SSH and X.509 private keys in images | Secret scanning on every build layer; inject at runtime from a secret manager; prefer short-lived workload identity over static keys; encrypt with FIPS 140 validated cryptography as the publication specifies |
| 3.2.3 and 4.2.3 Registry authentication | Developer, CI and pull credentials | Federated sign-in for people; scoped, short-lived push tokens for pipelines; read-only pull credentials per cluster |
| 3.3.1, 3.3.2, 4.3.2 Orchestrator access | Cluster administrators, orphaned and highly privileged accounts | SSO and MFA, no shared admin accounts, regular review of cluster role bindings |
| 3.3.5 and 4.3.5 Node trust | Node identities and key pairs | Unique per-node credentials, no shared key pairs, mutual TLS between nodes and control plane |
| 4.4.5 Rogue containers | The person or pipeline that created a container | Tie every deployment to an individual or a named pipeline identity and keep audit logs |
| 6.5 Disposition | Container keys and storage | Revoke or delete keys when workloads are retired |
Kubernetes service account tokens are the main gap: 800-190 does not address them explicitly, yet a pod's mounted token and any cloud keys it holds are what an attacker uses after a container compromise (ATT&CK T1552.007 Container API, T1078.004 Cloud Accounts). In the Tesla Kubernetes cryptojacking incident, an unauthenticated administration console led to AWS credentials stored in a pod. See the Kubernetes NHI Security Guide and the Kubernetes Service Account Token Guide.
Implementation steps
- Inventory and classify. List clusters, registries, base images, host OS builds and workloads, and assign each workload a sensitivity level (section 6.1 and the executive summary grouping recommendation).
- Fix the pipeline first. Add image scanning for vulnerabilities, configuration and secrets to CI, initially in report-only mode. Record a baseline of findings per image before setting gates.
- Harden registries. Enforce TLS, federated authentication, scoped push rights and immutable tags; remove stale images on a schedule.
- Sign and allowlist. Sign images at build, then enforce signature verification and trusted registry allowlists at admission, starting in audit or warn mode on non-production namespaces.
- Constrain runtime. Apply non-root, read-only root filesystems, dropped capabilities, default seccomp and SELinux or AppArmor. Roll out namespace by namespace: audit, fix violations, then enforce.
- Segment by sensitivity. Default-deny network policies, egress control, and node pools or separate clusters for high-sensitivity workloads (4.3.3, 4.3.4).
- Harden hosts. Move to a minimal container-specific OS where possible, remove direct user logons, and replace in-place patching with node image rotation.
- Move secrets out. Replace secrets found in images and environment files with runtime injection or workload identity, then rotate every credential that was ever baked into an image.
- Turn on enforcement and monitoring. Switch gates from audit to enforce with a documented break-glass exception, send container and orchestrator events to the SIEM, and deploy container-aware runtime detection.
Rollback: keep admission policies in audit mode in a parallel policy set so enforcement can be reverted per namespace without removing logging, and keep the last known good image digest for each workload. Section 6.3 recommends a phased rollout to a small number of applications first.
Choosing between options
| Decision | Option A | Option B | Choose A when |
|---|---|---|---|
| Isolation of sensitive workloads | Dedicated node pools with taints and tolerations | Separate clusters | A small team runs few sensitivity levels; choose separate clusters when regulators or tenants require hard separation of control planes |
| Host OS | Container-specific minimal OS | Hardened general-purpose OS | You can run immutable nodes; keep a general-purpose OS only where agents or drivers require it |
| Secrets delivery | Workload identity federation to cloud services | Secret manager injection | The target service supports federated tokens; use injection for databases and third-party APIs that need static secrets |
| Vulnerability gate | Block on critical severity with known exploitation | Block on any high or critical | You are starting out and need low friction; tighten once the backlog is under control |
Smaller teams can lean on managed Kubernetes and managed registries for node and control plane hardening and concentrate on images, admission policy and secrets. Larger organisations need policy as code across many clusters and a platform team that owns base images.
Evidence and assessment
- Pipeline: scan reports per image digest, gate decisions and documented exceptions.
- Registry: authentication configuration, push permission lists, tag immutability settings, pruning logs.
- Orchestrator: RBAC role bindings with review dates, admission policies and their mode, API server audit logs.
- Runtime: pod security settings per namespace, network policies, runtime detection alerts and how they were handled.
- Host: host OS build standard, patch or rotation records, host login audit records.
Metrics
- Percentage of running containers from signed images in allowlisted registries.
- Percentage of running images with no critical vulnerabilities older than your remediation SLA.
- Number of secrets detected in images per month, and median time to rotate them.
- Percentage of namespaces enforcing a restricted pod security level.
- Percentage of workloads covered by a default-deny network policy.
- Median node image age across clusters.
Mapping to other frameworks
| SP 800-190 area | SP 800-53 Rev. 5 | NIST CSF 2.0 | MITRE ATT&CK risk addressed |
|---|---|---|---|
| Image vulnerabilities and configuration (4.1.1, 4.1.2) | RA-5, CM-6, CM-7 | PR.PS-01, PR.PS-02 | T1610 Deploy Container |
| Trusted images and signing (4.1.5) | SI-7, CM-7 | PR.PS-06 | T1525 Implant Internal Image |
| Embedded secrets (4.1.4) | IA-5, SC-28 | PR.AA (identity management and access control) | T1552.007 Container API |
| Registry connections and authentication (4.2) | SC-8, AC-6, IA-5 | PR.DS, PR.AA | T1078.004 Cloud Accounts |
| Orchestrator access and node trust (4.3) | AC-6, IA-9, AU-2 | PR.AA | T1613 Container and Resource Discovery |
| Runtime configuration and isolation (4.4, 4.5) | SC-39, SC-7, CM-6 | PR.PS-01, PR.IR | T1611 Escape to Host |
| Runtime monitoring (4.4.4, 6.4) | SI-4, AU-6 | DE.CM-09 | T1610, T1611 |
For the image supply chain itself, pair this with SP 800-204D and the Software Supply Chain Security Guide.
Common pitfalls
- Deleting the secret but not revoking it. Flare's study of Docker Hub uploads in November 2025 found 10,456 public images with exposed keys, and most developers who removed a secret did not revoke the credential. See the Docker Hub Secrets Leak 2025. Image history keeps every layer.
- Unauthenticated management interfaces. Dashboards, kubelet and runtime APIs exposed without authentication break 4.3.2 outright, as the Tesla case shows.
- Scanning without gates. Reports that never block a deployment do not meet 4.1.1, which expects policy-driven enforcement.
- Mutable tags in production. Deploying "latest" means the image you scanned is not necessarily the image you run. Pin by digest.
- Patching containers in place. Section 6.4 expects rebuild and redeploy; patched running containers drift from their images and break forensics.
- Mixing sensitivity on shared nodes. Default scheduling places public-facing and sensitive pods together, so one escape crosses the boundary that 3.3.4 warns about.
Practitioner checklist
- Record that SP 800-190 (2017) is the current edition and note which newer documents you use alongside it.
- Classify every workload by sensitivity and map it to node pools or clusters.
- Scan every image for vulnerabilities, misconfiguration and secrets in CI, with an enforced gate.
- Sign images and verify signatures and registry allowlists at admission.
- Enforce TLS, federated authentication and scoped push rights on every registry; prune stale images.
- Require SSO and MFA for cluster administrators and review cluster role bindings quarterly.
- Enforce non-root, read-only root filesystems, seccomp and default-deny network policy.
- Remove static credentials from images and pods; rotate any that were ever embedded.
- Run minimal, immutable hosts and rotate node images rather than patching in place.
- Send orchestrator audit logs and runtime detections to the SIEM and track the six metrics.
Standards and references
- NIST: SP 800-190, Application Container Security Guide
- NIST: SP 800-190 full text (PDF)
- NIST: SP 800-204, Security Strategies for Microservices-based Application Systems
- NIST: SP 800-204D, Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
- MITRE ATT&CK: Escape to Host
- CIS: Docker Benchmark
Related NHI Mgmt Group resources: Container Security Guide · Container Image Security Guide · Kubernetes Security Guide · Container Registry Security Guide · SBOM Guide