The FedRAMP policy packs map the FedRAMP Rev 5 vulnerability scanning requirements and the FedRAMP 20x Key Security Indicators to checks that the Anchore Enterprise policy engine can evaluate against container images and SBOMs.
Current FedRAMP policy pack versions: Anchore FedRAMP v5 Checks v2026.3 and Anchore FedRAMP 20x v2026.2
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.
FedRAMP Rev 5
Anchore Enterprise’s FedRAMP Rev 5 policy checks for the following specifications. Rule sets marked Required in the Configuration column must be configured for your environment before the policy is used. See Configure Rule Sets.
| Control family | Control | Check | Configuration |
|---|---|---|---|
| Access Control (AC) | AC-6(10) | Prevent non-privileged users from executing privileged functions | |
| Configuration Management (CM) | CM-2(2), CM-3(1), CM-6 | Baseline configuration: configure systems and components for high-risk areas | Required |
| Configuration Management (CM) | CM-5(5) | Access restrictions for change: privilege limitation for production and operation | Required |
| Configuration Management (CM) | CM-7(1) | Least functionality: network port exposure checks | Required |
| Configuration Management (CM) | CM-7(5), CM-8(3) | Least functionality: container image build content checks | Required |
| Configuration Management (CM) | CM-10 | Software usage restrictions | Required |
| Identification and Authentication (IA) | IA-05(7) | Authenticator management: no embedded unencrypted static authenticators | |
| Risk Assessment (RA) | RA-5, SI-02(2) | Vulnerability monitoring and scanning | |
| System and Communications Protection (SC) | SC-5 | Denial-of-service protection |
An RA-5 SI-02 vulnerability scan remediation rule set is bound to the SBOM mapping, so the RA-5 vulnerability checks apply to imported SBOMs as well as scanned images. The remaining rule sets evaluate image content and are bound to the container mapping only.
The RA-5 SI-02(2) RISK ASSESSMENT rule set is VEX-aware: its vulnerability rules are split so that un-annotated findings and findings annotated affected or under_investigation both match, while findings annotated not_affected or fixed match neither. See Annotations and VEX.
FedRAMP 20x
FedRAMP 20x replaces the Rev 5 control-by-control narrative with Key Security Indicators (KSIs), outcome statements a cloud service offering must demonstrate, and a Vulnerability Detection and Response (VDR) standard governing how providers find and act on vulnerabilities. The Anchore FedRAMP 20x pack implements the Class C indicators that are reachable from container and SBOM content.
| Indicator | Rule set | Anchore role |
|---|---|---|
| Identity and access management | KSI-IAM-ELP | Fail images whose effective user is root or docker, or that contain setuid or setgid binaries |
| Identity and access management | KSI-IAM-APM | Fail images carrying embedded API keys, AWS credentials, or passwords |
| Cloud native architecture | KSI-CNA-RNT | Fail images that expose ports outside the allowed list, or that expose a denied port |
| Cloud native architecture | KSI-CNA-ULN | Fail images whose Dockerfile exposes ports outside the allowed list |
| Cloud native architecture | KSI-CNA-DFP | Fail images running as root or containing sshd |
| Cloud native architecture | KSI-CNA-RVP | Fail images with no HEALTHCHECK instruction in the Dockerfile |
| Cloud native architecture | KSI-CNA-MAT | Fail on vulnerabilities listed on the CISA Known Exploited Vulnerabilities (KEV) catalog |
| Service configuration | KSI-SVC-ACM | Fail when Java archives are added to or removed from a tag between builds |
| Service configuration | KSI-SVC-ASM | Fail images where a secret is found under /etc |
| Vulnerability detection and response | VDR-CSO-DET | Warn on vendor-reported vulnerabilities and on vulnerabilities with a fix available; fail when vulnerability data is unavailable or the feed has not synced in 15 days |
| Vulnerability detection and response | VDR-CSO-AKE | Fail on KEV-listed vulnerabilities, which providers must not deploy on new resources |
Two rule sets are bound to the SBOM mapping: VDR-CSO-AKE SBOM, which applies the KEV gate to imported SBOMs, and KSI-SCR-MIT - SBOM, which fails supply chain findings that have a fix available or appear on the KEV catalog.
VEX Annotations
The VDR rule sets act on VEX annotation state, as described in Annotations and VEX. They match findings annotated affected or under_investigation, so a finding assessed as not_affected or fixed drops out of the evaluation as soon as the annotation is saved.
This pairing matters more under 20x than under Rev 5: the VDR standard expects a provider to show a continuous detection and response process, and an annotation records the assessment and its justification as evidence rather than simply muting the finding. The KSI rule sets, which evaluate image configuration rather than vulnerabilities, 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 control specifications marked Required in the table above 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).