The CMMC policy pack maps the controls of the Cybersecurity Maturity Model Certification (CMMC) to checks that the Anchore Enterprise policy engine can evaluate against container images. The pack is grounded in NIST SP 800-171r3, the security-requirement publication from which CMMC draws its control set, and ships as a single bundle ready to import as a policy.
Current CMMC policy pack version: Anchore CMMC - NIST 800-171r3 v2026.2
Introduction
CMMC is the U.S. Department of Defense’s certification program for the Defense Industrial Base, the contractors and subcontractors that build, deliver, and support systems for the DoD. It exists because the DoD’s sensitive unclassified information lives largely on contractor networks, and self-attestation alone proved a weak assurance that it was protected there.
The program is tiered by the sensitivity of the information a contract involves. Contracts touching Federal Contract Information (FCI) sit at the lowest tier, while contracts involving Controlled Unclassified Information (CUI) require the full NIST SP 800-171 security requirements, assessed rather than self-asserted. CMMC requirements flow down through the supply chain: a subcontractor handling CUI on a prime’s behalf carries the same obligation the prime does.
For organizations delivering software, this lands squarely on the build pipeline. Container images that process, store, or transmit CUI are in scope, as is the infrastructure that produces them. The least-privilege, unauthorized-software, secrets, malware, and vulnerability-management requirements therefore have to be demonstrable against the artifacts themselves, not just described in a system security plan. That is the evidence this pack produces: each rule set is named for the 800-171r3 requirement it supports, so a policy evaluation maps directly onto the control an assessor is asking about.
Controls
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 | Rule set | Anchore role | Configuration |
|---|---|---|---|
| 03.01.07 Least Privilege | 03.01.07 - Least Privilege | Fail images whose effective user is root or docker | |
| 03.04.06 Least Functionality | 03.04.06 allow ports | Fail images that expose ports outside the allowed list | Required |
| 03.04.06 Least Functionality | 03.04.06 deny ports | Fail images that expose a denied port (ports 0–1024 by default) | Required |
| 03.04.06 Least Functionality | 03.04.06 Unauthorized software | Fail images containing a denied package (openssh-server and opensshd by default) | Required |
| 03.05.07 Password Management | 03.05.07 - Password Management | Fail images where the secret scan matches a configured secret pattern | |
| 03.11.02 Vulnerability Monitoring and Scanning | 03.11.02 vulnerability scan | Warn on vendor-reported vulnerabilities of low severity or higher | |
| 03.11.02 Vulnerability Monitoring and Scanning | 03.11.02 vulnerability fix available | Warn on vulnerabilities that have a fix available | |
| 03.11.02 Vulnerability Monitoring and Scanning | 03.11.02 specific CVE | Fail images containing a denied vulnerability ID | Required |
| 03.11.02 Vulnerability Monitoring and Scanning | 03.11.02 vulnerability feeds | Fail when the vulnerability feed has not synced in 15 days | Required |
| 03.14.02 Malicious Code Protection | 03.14.02 malicious code protection | Fail on malware findings, and fail when the malware scan did not run | |
| None | Dockerfile not found | Fail when no Dockerfile was supplied with the image, since several checks above need one to evaluate |
03.14.02 malicious code protection rule set fails an image when the malware scan has not run, so malware scanning must be enabled in your deployment before this rule set produces meaningful results. See Scanning.VEX Annotations
The 03.11.02 vulnerability rule sets are each 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. This matters for an assessment conversation: the evidence shows which findings were reviewed and dismissed with a justification, rather than suppressed.
The other rule sets (least privilege, port exposure, unauthorized software, secrets, malware, and feed currency) do not depend on annotation state.
SBOM Rule Sets
The pack ships three 03.11.02 rule sets bound to the SBOM mapping, so vulnerability checks apply whether you scan an image or import an SBOM directly: 03.11.02 vulnerability scan - SBOM, 03.11.02 vulnerability fix available - SBOM, and 03.11.02 specific CVE [CONFIGURE] -SBOM.
The remaining controls depend on image content and are bound to the image mapping only. The SBOM rule sets do not always use the same action as their image counterpart, so review them alongside the image rule sets after import.
Allowed and Denied Images
The bundle also ships example deployment-wide image overrides, which force an image’s final result regardless of the rest of the evaluation, as described in Allowed / Denied Images:
| Override | Entry |
|---|---|
| Allowed | approved_registry.io, all repositories and tags |
| Denied | docker.io, all repositories and tags |
| Denied | any repository named badrepo, on any registry |
These are placeholders. Replace them with your own approved and prohibited registries before activating the pack. As shipped, the docker.io entry fails every image pulled from Docker Hub.
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, and attach any allowlists you need before activating it as the account’s default policy.
The CMMC pack is intended as a starting point. Most teams customize mappings, attach allowlists for accepted risks, or layer additional rule sets on top before activating the pack against production registries.
Configure Rule Sets
The rule sets marked Required in the table above ship with placeholder values that stand in for values only you can supply: an allowed port of 123456, a denied package of opensshd, and an example CVE ID. 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.