Policy Packs
Policy packs are pre-built policies that map to common regulatory frameworks. Each pack ships as a complete bundle — rule sets, mappings, and allowlists — ready to import, customize, and activate against your account.
The Secure pack ships with every Anchore Enterprise deployment. The remaining packs require additional license entitlements:
| Pack | Frameworks covered | Entitlement |
|---|
| Secure | Anchore’s default checks — feed data availability, low and moderate vulnerabilities with fixes, and critical-severity vulnerabilities | Included with every deployment |
| NIST | NIST 800-53 and NIST 800-190 (Application Container Security Guide) | Anchore Enforce |
| CIS | CIS Docker Benchmark | Anchore Enforce |
| FedRAMP | FedRAMP Vulnerability Scanning Requirements, NIST 800-53 Rev 5, NIST 800-190 | Anchore Enforce plus the FedRAMP add-on |
| DoD | DISA Image Creation and Deployment Guide, IronBank requirements | Anchore Enforce plus the DoD add-on |
| CMMC | CMMC compliance via NIST 800-171r3 controls | Anchore Enforce |
| ASD Essential 8 | Australian Signals Directorate (ASD) Essential Eight, Maturity Levels 1–3 | Anchore Enforce |
The NIST SSDF sub-pack covers the Secure Software Development Framework (NIST SP 800-218); see the NIST page for how it relates to the broader NIST pack.
How Packs Are Used
Each pack page covers the same workflow: download the bundle, import it into Anchore Enterprise, activate it, and adjust its mappings or allowlists for your environment. The mechanics — anchorectl policy add, the GUI’s Import action, and the POST /policies endpoint — are the same as for any policy. See Manage Policies for the general CRUD workflow.
Packs are a starting point, not a final shape. Most teams customize the pack they import — adjusting mappings to scope the pack to specific registries or repositories, attaching allowlists for known false positives, or layering additional rule sets on top — before activating the result as the account’s default policy.
1 - FedRAMP
Current FedRAMP policy pack version: Anchore FedRAMP v5 Checks v20250101
The FedRAMP pack requires the Anchore Enforce entitlement plus the FedRAMP add-on. Contact Anchore Customer Success to request the latest version.
Introduction
FedRAMP (Federal Risk and Authorization Management Program) is a standardized approach for assessing, authorizing, and monitoring cloud service providers (CSPs) that provide service to federal agencies. Through a rigorous and comprehensive process, FedRAMP ensures that CSPs meet security standards by providing a baseline set of security controls to enhance the overall security of federal information systems.
Anchore Enterprise’s FedRAMP policy validates whether container images are compliant with the FedRAMP Vulnerability Scanning Requirements, and validates them against the FedRAMP controls specified in NIST 800-53 Rev 5 and NIST 800-190. The policy checks only the specification requirements relevant to software supply chain security.
Anchore Enterprise’s FedRAMP policy checks for the following specifications:
- AC-6(10) ACCESS CONTROL: Prevent Non-Privileged Users from Executing Privileged Functions
- CM-2(2), CM-3(1), CM-6 CONFIGURATION MANAGEMENT: Baseline Configuration | Configure Systems and Components for High-risk Areas
- CM-10 CONFIGURATION MANAGEMENT: Software Usage Restrictions
- CM-5(5) CONFIGURATION MANAGEMENT: Access Restrictions for Change | Privilege Limitation for Production and Operation
- CM-7(1) CONFIGURATION MANAGEMENT: Least Functionality - Network Port Exposure Checks
- CM-7(5), CM-8(3) CONFIGURATION MANAGEMENT: Least Functionality - Container Image Build Content Checks
- IA-05(7) IDENTIFICATION AND AUTHENTICATION: Authenticator Management | No Embedded Unencrypted Static Authenticators
- RA-5, SI-02(2) RISK ASSESSMENT: Vulnerability Monitoring and Scanning
- SC-5 SYSTEM AND COMMUNICATIONS PROTECTION: Denial-of-Service Protection
Using 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.
Configuring Rule Sets
Some control specifications need configuration for your environment. The control specifications are represented by rule sets, edited from the policy’s Edit action in the Anchore Enterprise GUI (see Manage Policies).
The following rule sets must be configured before using the FedRAMP policy:
- CM-2(2), CM-3(1), CM-6 CONFIGURATION MANAGEMENT: Baseline Configuration | Configure Systems and Components for High-risk Areas
- CM-10 CONFIGURATION MANAGEMENT: Software Usage Restrictions
- CM-5(5) CONFIGURATION MANAGEMENT: Access Restrictions for Change | Privilege Limitation for Production and Operation
- CM-7(1) CONFIGURATION MANAGEMENT: Least Functionality - Network Port Exposure Checks
- CM-7(5), CM-8(3) CONFIGURATION MANAGEMENT: Least Functionality - Container Image Build Content Checks
2 - NIST
Current NIST 800-53 and 800-190 policy pack versions: Anchore NIST 800-53 v20251201 and Anchore NIST 800-190 v20250101
The NIST packs require the Anchore Enforce entitlement. Contact Anchore Customer Success to request the latest versions.
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 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 assesses for the following controls:
| Control Families | NIST 800-53 Control | Anchore Role |
|---|
| Access Control (AC) | AC-6(10) Least Privilege | Validate containers are not running as root |
| Configuration Management (CM) | CM-7(1b) Network Ports | Check for allowed ports that can be exposed & which ports cannot be exposed |
| Configuration Management (CM) | CM-8 System Component Inventory | Generate an SBOM to understand all components within source code and containers |
| Identification and Authentication (IA) | IA-5(7) Authenticator Management | Validate that there are no embedded unencrypted static authenticators/passwords |
| Risk Assessment (RA) | RA-5 Vulnerability Monitoring & Scanning | Vulnerability scans of both containers and source code |
| System and Information Integrity (SI) | SI-3 Malicious Code Protection | Scan source and container images for malware |
| Secure Communications (SC) | SC-5 Denial of Service Protection | HEALTHCHECK instruction within the Dockerfile |
| Supply Chain (SR) | SR-4(4) Provenance | Only trusted registries shall be used for container images |
NIST 800-190
Anchore Enterprise checks for the following control specifications in the NIST 800-190 policy:
| Countermeasures | NIST 800-190 Reference | Anchore Role |
|---|
| Image | 4.1.1 Image Vulnerabilities | Leverage policies to continuously detect image vulnerabilities sourced from the CVE database and KEV list. The policy can be defined with something as extreme as no known vulnerabilities allowed, down to only if a critical vulnerability is on the KEV list. The date of the vulnerability database is also crucial, especially in an air-gapped environment, which is part of this policy |
| Image | 4.1.2 Image Configuration Defects | Assess images and source code for specific configuration requirements as set by organizational policy |
| Image | 4.1.3 Embedded Malware | Images and source code are scanned for malware using up-to-date anti-virus definitions |
| Image | 4.1.4 Embedded Clear Text Secrets | Scan container images for clear text passwords, API keys, and private keys |
| Image | 4.1.5 Use of Untrusted Images | Policy as code is used to ensure that containers are built only using trusted registries, repositories, and tags |
| Container | 4.4.1 Vulnerabilities within the runtime software | Runtime containers can be scanned both in CI and via Kubernetes Runtime Inventory, ensuring vulnerabilities are scanned and mitigated according to organizational requirements |
| Container | 4.4.2 Unbounded network access from containers | Evaluate containers to ensure only authorized ports are open |
| Container | 4.4.3 Insecure container runtime configurations | Ensure the container is not running as the root user |
Using 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.
Configuring Rule Sets
Some control specifications need configuration for your environment. The control specifications are represented by rule sets, edited from the policy’s Edit action in the Anchore Enterprise GUI (see Manage Policies).
The following rule sets must be configured before using the NIST 800-53 policy:
- CM-6(b) Confidential Data Checks
- CM-7(1b) Network Port Exposure Checks
- CM-7(a) Container Image Build Content Checks
2.1 - SSDF
In February 2021, The National Institute of Standards and Technology (NIST) created NIST SP 800-218, otherwise known as Secure Software Development Framework (SSDF), in response to a new executive order mandated by the federal government.
SSDF provides a comprehensive set of guidelines aimed at integrating security into the software development lifecycle, thereby enhancing the security posture of software products from inception to deployment. To verify and validate that organizations meet the controls needed to be SSDF compliant, CISA created an official SSDF Attestation Form that allows organizations to verify and attest that they adhere to the SSDF guidelines and comply with a subset of security controls.
Purpose
Anchore provides a downloadable document that serves as an evidence attachment for the SSDF Attestation Form. The document makes the assumption Anchore Enterprise is used in the organization’s environment and is configured to scan the software that is in scope for the SSDF Attestation Form.
The SSDF Attestation Form consists of three sections that must be completed. Sections I and II cover organization-specific details, whereas Section III lists requirements against various security controls. The intent of this document is to provide guidance for first time applicants and help organizations save time collecting evidence required for Section III of the SSDF Attestation Form.
Download
Detailed instructions to complete the form can be found on page 1. This document uses the official SSDF Attestation Form as its base template. Once completed, the document can be directly attached to an SSDF Attestation Form submission. Click below to obtain the form:
Additional Resources
- SSDF Attestation 101: A practical guide for Software Producers - Download eBook
- Using the Common Form for SSDF Attestation: What Software Producers Need to Know - Read blog
- Automate NIST compliance and SSDF attestation with Anchore Enterprise - Learn more
If you want to contact one of our experts, please contact us.
3 - CIS
The Center for Internet Security (CIS) provides prescriptive configuration recommendations for a variety of software vendors. Anchore Enterprise’s CIS policy pack is based on the CIS Docker 1.8 Benchmark and validates a subset of security and compliance checks against container images.
Current CIS policy pack version: Anchore CIS Docker Benchmark V1.8.0 v20251101
The CIS pack requires the Anchore Enforce entitlement. Contact Anchore Customer Success to request the latest version.
Controls
Anchore Enterprise checks for the following control specifications in the CIS policy:
- 4.1 Ensure that a user for the container has been created
- 4.2 Ensure that containers use only trusted base
- 4.3 Ensure that unnecessary packages are not installed in the container
- 4.4 Ensure images are scanned and rebuilt to include security patches
- 4.6 Ensure that HEALTHCHECK instructions have been added to container images
- 4.7 Ensure update instructions are not used alone in Dockerfiles
- 4.8 Ensure setuid and setgid permissions are removed
- 4.9 Ensure that COPY is used instead of ADD in Dockerfiles
- 4.10 Ensure secrets are not stored in Dockerfiles
- 4.11 Ensure only verified packages are installed
- 5.8 Ensure privileged ports are not mapped within containers
Using 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.
Configuring Rule Sets
Some control specifications need configuration for your environment. The control specifications are represented by rule sets, edited from the policy’s Edit action in the Anchore Enterprise GUI (see Manage Policies).
The following rule sets must be configured before using the CIS policy:
- 4.2 Ensure that containers use only trusted base
- 4.3 Ensure that unnecessary packages are not installed in the container
- 5.8 Ensure privileged ports are not mapped within containers
4 - DoD
Current IronBank policy pack version: Anchore DoD Iron Bank v20250101
Current DISA policy pack version: Anchore DISA Image Creation and Hardening Guide v20250101
The DoD packs require the Anchore Enforce entitlement plus the DoD add-on. Contact Anchore Customer Success to request the latest versions.
Introduction
Anchore Enterprise provides two DoD policies:
- DISA Image Creation and Deployment Guide — provided by the Defense Information Systems Agency (DISA), the agency that supplies IT and communications support to the U.S. government and federal organizations. This policy provides security and compliance checks that align with specific NIST 800-53 and NIST 800-190 controls as described in the DoD Container Image Creation and Deployment Guide.
- IronBank — validates images against DoD security and compliance requirements in alignment with U.S. Air Force security standards at Platform One and IronBank, written in accordance with DoD Enterprise DevSecOps Reference Design documentation.
DISA
Anchore Enterprise checks for the following control specifications in the DISA policy:
- AC-6(10) Container Image Must Have Permissions Removed from Executables that Allow a User to Execute Software at Higher Privileges
- CM-6(b) Confidential Data Checks
- CM-7(1b) Network Port Exposure Checks
- CM-7(a) Container Image Build Content Checks
- IA-5(2a) Base Image Checks
- IA-5(7) Embedded Credentials
- RA-5 Software Vulnerability Checks
- SC-5 Image Checks
- SC-8(2) Base Image Checks
- SI-2(6) Image Software Update/Layer Checks
IronBank
The IronBank policy includes checks across the following areas:
Dockerfile, User, File, Istio, Software, Transfer Protocol, Node.js, Etcd, Snort, Jenkins, Grafana, UBI7, Chef, Sonarqube, Prometheus, Postgres, Nginx, OpenJDK, Twistlock, Keycloak, Fluentd, Elasticsearch, Kibana, Redis, Apache HTTP, and Apache Tomcat.
Using 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.
Configuring Rule Sets
The IronBank policy does not require rule set configuration. The DISA policy, however, requires configuration for certain specifications — the control specifications are represented by rule sets, edited from the policy’s Edit action in the Anchore Enterprise GUI (see Manage Policies).
The following rule sets must be configured before using the DISA policy:
- CM-6(b) Confidential Data Checks
- CM-7(1b) Network Port Exposure Checks
- CM-7(a) Container Image Build Content Checks
5 - Secure
The default Secure policy pack comes included (and enabled) in every fresh deployment of Anchore Enterprise.
Current Secure policy pack version: Anchore Enterprise - Secure v20250101
Introduction
Anchore Enterprise’s default Secure policy pack includes standard vulnerability and system-level checks and can be used against an image SBOM for policy compliance based on the policy actions configured in each rule. All the rules that are configured by default can (and should) be adjusted according to an organization’s security policy.
Anchore Enterprise checks for the following control specifications in the Secure policy:
- Feed Data not available Fail if feed data is unavailable
- Warn on low and moderate with fixes Warn when there are low and medium severity vulnerabilities found that also
have a fix present (Available for Containers, Sources, and SBOMs)
- Warn on week old Important Warn when there are important severity vulnerabilities found that are more than a week old (Available for Containers, Sources, and SBOMs)
“Important” indicates the severity of a vulnerability. By default, it is set to “High” but this can be configured in the policy rule set
- Fail on criticals Fail when there are critical severity vulnerabilities present (Available for Containers, Sources, and SBOMs)
6 - CMMC
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 that CMMC uses as its control set, and ships as a single bundle ready to import as a policy.
What’s in the Pack
- Pack name: Anchore CMMC — NIST 800-171r3
- Frameworks covered: CMMC compliance via NIST 800-171r3 controls
- Artifact coverage: container images and SBOMs. The pack ships rule sets for both, plus the mappings that bind each rule set to its artifact type.
- Rule set organization: rule sets are named by NIST 800-171r3 control identifier (for example
03.01.07 — Least Privilege), so the mapping from a bundle finding back to its underlying compliance control is direct.
The pack maps the 800-171r3 controls that are reachable from SBOM and image content into rule sets the policy engine can evaluate. Controls that depend on organizational process or physical environment — rather than artifact content — are out of scope for a container-image or SBOM policy and are not represented in the bundle.
How to 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.
7 - ASD Essential 8
The ASD Essential 8 policy pack maps the Australian Signals Directorate’s Essential Eight mitigation strategies to checks that the Anchore Enterprise policy engine can evaluate against container images. The pack covers Maturity Levels 1 through 3 and ships as a single bundle ready to import as a policy.
What’s in the Pack
- Pack name: Anchore ASD Essential 8 — Maturity Levels 1 to 3
- Frameworks covered: Australian Signals Directorate (ASD) Essential Eight, Maturity Levels 1–3
- Artifact coverage: container images and SBOMs. The pack ships rule sets for both, plus the mappings that bind each rule set to its artifact type.
- Rule set organization: rule sets are named by Essential Eight control identifier (for example
Patch OS ISM-1876), covering the subset of mitigation strategies that are reachable from artifact content.
The pack maps the Essential Eight controls that depend on artifact content — patching status, package version currency, configuration of distributed software — into rule sets the engine can evaluate. Controls that depend on organizational process, network configuration, or runtime posture are out of scope for a container-image or SBOM policy and are not represented in the bundle.
How to 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 ASD Essential 8 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.