NIST
The NIST policy packs map the NIST SP 800-53 security controls and the NIST SP 800-190 Application Container Security Guide to checks that the Anchore Enterprise policy engine can evaluate against container images and SBOMs.
Current NIST policy pack versions: Anchore NIST 800-53r5 v2026.2 and Anchore NIST 800-190 v2026.1
Introduction
The National Institute of Standards and Technology (NIST) is a non-regulatory agency of the U.S. Commerce Department that provides industry standards and guidelines to help federal agencies meet requirements set by the Federal Information Security Management Act (FISMA).
Anchore Enterprise provides two NIST policies:
- NIST 800-53: a catalog of security and privacy controls for the U.S. Federal Government. These controls are also the foundation of FedRAMP, the Joint Special Access Program (SAP) Implementation Guide (JSIG), and Intelligence Community Directive (ICD) 503. Anchore Enterprise helps security teams meet the subset of these controls that can be evaluated against container and SBOM content.
- NIST 800-190: the Application Container Security Guide, which describes security concerns with container technologies and recommendations to address them across the container lifecycle.
Anchore also covers NIST 800-218 (SSDF) through the SSDF Attestation Form Guide and Evidence document. See SSDF.
NIST 800-53
Anchore Enterprise checks for the following control specifications against container images. Rule sets marked Required in the Configuration column ship with placeholder values and must be configured for your environment before the policy is used. See Configure Rule Sets.
| Control family | Rule set | Anchore role | Configuration |
|---|---|---|---|
| Access Control (AC) | AC-6(10) least privilege | Fail images whose effective user is root or docker | |
| Access Control (AC) | AC-6(8) least privilege | Fail images containing setuid or setgid binaries | |
| Configuration Management (CM) | CM-7(1b) allow ports | Fail images that expose ports outside the allowed list | Required |
| Configuration Management (CM) | CM-7(1b) deny ports | Fail images that expose a denied port (ports 0–1024 by default) | Required |
| Configuration Management (CM) | CM-7(1b) deny packages | Fail images containing a denied package (openssh-server and opensshd by default) | Required |
| Identification and Authentication (IA) | IA-5(7) authenticator management | Fail images where the secret scan matches a configured secret pattern | |
| Risk Assessment (RA) | RA-5 vulnerability scan | Warn on vendor-reported vulnerabilities of low severity or higher | |
| Risk Assessment (RA) | RA-5 Vulnerability with Known Exploit | Fail on vulnerabilities listed on the CISA Known Exploited Vulnerabilities (KEV) catalog | |
| Risk Assessment (RA) | RA-5 vulnerability fix available | Warn on vulnerabilities that have a fix available | |
| Risk Assessment (RA) | RA-5 specific CVE | Fail images containing a denied vulnerability ID | Required |
| Risk Assessment (RA) | RA-5 vulnerability feeds | Fail when vulnerability data is unavailable, or when the feed has not synced in 15 days | |
| System and Information Integrity (SI) | SI-3 malicious code protection | Fail on malware findings, and fail when the malware scan did not run | |
| System and Communications Protection (SC) | SC-5 denial of service protection | Fail images with no HEALTHCHECK instruction in the Dockerfile | |
| Supply Chain (SR) | SR-4(4) | Fail images whose base image comes from outside the trusted registry list | Required |
| None | Dockerfile not found | Fail when no Dockerfile was supplied with the image, since several checks above need one to evaluate |
Three rule sets are bound to the SBOM mapping, so the RA-5 checks apply whether you scan an image or import an SBOM directly: RA-5 Vulnerability Scan - SBOM, RA-5 Vulnerability on KEV list - SBOM, and RA-5 specific CVE [CONFIGURE] - SBOM.
NIST 800-190
Anchore Enterprise checks for the following control specifications in the NIST 800-190 policy, which is bound to container images only.
| Countermeasure | Rule set | Anchore role | Configuration |
|---|---|---|---|
| Image vulnerabilities | 3.1.1 | Warn on vendor-reported vulnerabilities of low severity or higher | |
| Image vulnerabilities | 3.1.1 vulnerability fix available | Fail on vulnerabilities that have a fix available | |
| Image vulnerabilities | 3.1.1 specific CVE | Fail images containing a denied vulnerability ID | Required |
| Image vulnerabilities | 3.1.1 vulnerability feeds | Fail when vulnerability data is unavailable, or when the feed has not synced in 15 days | |
| Image configuration defects | 3.1.2 configuration | Fail when a required file is missing or does not match its expected checksum | Required |
| Embedded clear text secrets | 3.1.4 | Fail images where the secret scan matches a configured secret pattern | |
| Use of untrusted images | 3.1.5 | Fail images whose base image comes from outside the trusted registry list | Required |
| Unbounded network access | 3.4.2 allow ports | Fail images that expose ports outside the allowed list | Required |
| Unbounded network access | 3.4.2 deny ports | Fail images that expose a denied port (ports 0–1024 by default) | Required |
| Insecure runtime configuration | 3.4.3 root user | Fail images whose effective user is root or docker | |
| Insecure runtime configuration | 3.4.3 setuid/setgid | Fail images containing setuid or setgid binaries | |
| Host OS attack surface | 3.5.1 deny packages | Fail images containing a denied package (openssh-server and opensshd by default) | Required |
| Embedded malware | 4.1.3 | Fail on malware findings, and fail when the malware scan did not run | |
| Denial of service | 2.3.3 | Fail images with no HEALTHCHECK instruction in the Dockerfile | |
| None | Dockerfile not found | Fail when no Dockerfile was supplied with the image, since several checks above need one to evaluate |
Each 800-190 rule set carries the equivalent 800-53 control in its description, so a finding traces to both frameworks at once.
VEX Annotations
The vulnerability rule sets in both packs are split into two rules that differ only in annotation state, as described in Annotations and VEX:
- One rule matches findings that carry no annotation yet, so un-triaged vulnerabilities still count against the policy.
- The other matches findings annotated
affectedorunder_investigation, so vulnerabilities you have assessed as genuinely exploitable keep counting.
Findings annotated not_affected or fixed match neither rule, so an accurate VEX assessment clears them from the evaluation without an allowlist entry, and the compliance result refreshes as soon as the annotation is saved. The configuration, privilege, secret, malware, and feed-currency rule sets do not depend on annotation state.
Use the Pack
Import the pack like any other policy. See Manage Policies for the GUI, AnchoreCTL, and API workflows. Once imported, scope it to the registries and repositories it should apply to through Policy Mappings, then activate it as the account’s default policy.
Configure Rule Sets
The rule sets marked Required in the tables above ship with placeholder values: an allowed port of 123456, a denied package of opensshd, an example CVE ID, a sample trusted-registry list, and a placeholder configuration file and checksum. Each is tagged [CONFIGURE] in its rule set name in the GUI. Edit them from the policy’s Edit action in the Anchore Enterprise GUI (see Manage Policies) before you rely on the pack’s results.