The Federal Risk and Authorization Management Program (FedRAMP) 20x process changes what a cloud service provider (CSP) hands an assessor. Reviewers now expect evidence that’s machine-readable and validated continuously. A control narrative updated once a year won’t hold up.
If you own a Class C authorization package, you need to show that each container image met the requirement when it shipped, and that it’s been monitored every day since. The last scan before your third-party assessment organization (3PAO) visit won’t cover that.
The FedRAMP 20x policy for Anchore Enterprise automates that evidence at the container layer. It maps 11 FedRAMP 20x Key Security Indicators (KSIs) and Vulnerability Detection and Response (VDR) requirements to 23 automated image checks and 4 SBOM checks. It evaluates every image and every SBOM you bring in, whether Anchore Enterprise generated the SBOM or you imported it.
STOP, WARN, and GO decide the build
Every rule in the policy carries 1 of 3 actions. The image’s final action is the most severe action any rule triggered. A STOP fails the evaluation, and the build with it. WARN and GO let the image move to the next pipeline stage.
| Action | What it means | Evaluation result |
|---|---|---|
| STOP | The image or SBOM violates a requirement or policy and shouldn’t ship. A single STOP finding fails the evaluation unless an allowlist entry covers it. | Fail |
| WARN | The finding is recorded and visible, but it doesn’t block. Use it to track work you’re already remediating. | Pass |
| GO | No violation. | Pass |
What the policy checks
Each row maps a 20x requirement to the checks Anchore Enterprise runs against the image or SBOM.
| Requirement | What Anchore Enterprise enforces | Action |
|---|---|---|
| KSI-IAM-ELP | No SUID/SGID files; no root or docker effective user | STOP |
| KSI-IAM-APM | No embedded API keys, AWS keys, or passwords | STOP |
| KSI-SVC-ASM | No secrets in /etc/* or other directories | STOP |
| KSI-SVC-ACM | Java archive tag drift (packages added or removed) | STOP |
| KSI-CNA-DFP | No root user; block package | STOP |
| KSI-CNA-ULN / KSI-CNA-RNT | Only approved ports exposed in the Dockerfile | STOP |
| KSI-CNA-RVP | HEALTHCHECK instruction required | STOP |
| VDR-CSO-AKE | Known Exploited Vulnerabilities (KEV) that are unannotated or marked affected/under investigation | STOP |
| VDR-CSO-DET | Vulnerability feed data older than 15 days | STOP |
| VDR-CSO-DET, KSI-SCR-MIT | Fixable vulnerabilities at low severity and above | WARN |
Triage, exceptions, and third-party SBOMs
A KEV finding stays a STOP until your team annotates it as not affected via an update or mitigation. The decision, and the audit trail behind it, stay with the people who answer to the assessor along with evidence always in VEX annotations. The policy ships with an allowlist tied to VER-AGM-MAP, so every accepted risk carries an expiration date that lines up with your Plan of Action and Milestones (POA&M) instead of living forever.
The KEV and supply chain checks run against SBOMs, so third-party components you didn’t build still get evaluated against KSI-SCR-MIT and VDR-CSO-AKE.
Gate the build in CI
In your pipeline, analyze the image, then check it against the policy. With --fail-based-on-results, anchorectl image check exits with code 1 when the evaluation fails, so any STOP finding breaks the build before the image reaches your registry. WARN findings print in the --detail output without failing the job.
anchorectl image add ${IMAGE} --wait
anchorectl image check ${IMAGE} --detail --fail-based-on-resultsYou can set ANCHORECTL_FAIL_BASED_ON_RESULTS=true in your CI variables instead of passing the flag on every job.
Continuous monitoring after the image ships
New CVEs are published, and CISA adds entries to the KEV catalog after your image is already running. Anchore Enterprise keeps evaluating stored images and SBOMs against current vulnerability data, so a new KEV match turns a passing image into a STOP without a rebuild.
Subscriptions surface those changes to your team:
vuln_updatenotifies you when vulnerabilities are added, removed, or changed for a watched tag.policy_evalnotifies you when a tag’s evaluation flips from Pass to Fail, or back.alertsraises policy violations as alerts in the Anchore Enterprise UI, scoped to a single tag or an entire repository.
The stale feed rule backs this up. If vulnerability data hasn’t synced in 15 days, evaluations fail, so a broken feed can’t quietly turn continuous monitoring off two week old data .
Scope
This policy automates evidence for a defined set of image-level requirements. It supports your 20x authorization; it doesn’t replace your 3PAO assessment or cover KSIs outside the container layer.
Next step to roll it out: Import the FedRAMP 20x policy into Anchore Enterprise, map it to a non-production registry first, and review the STOP findings before you enforce it in CI. The docs are located here: https://docs.anchore.com/current/docs/compliance_management/policies/packs/fedramp/
Impact
In accordance with FedRAMP Notice NTC-0014, the Vulnerability Detection and Response (VDR) and Vulnerability Evaluation and Reporting (VER) rules become mandatory for every cloud service offering obtaining or maintaining FedRAMP Certification on December 7, 2026. Offerings that aren’t compliant by then can keep their certification through March 7, 2027 only under a corrective action plan (CAP), which FedRAMP shares with all agency customers. After March 7, 2027, FedRAMP revokes certification for any offering not following the rules.
Book time with us to see a live demo on our FedRAMP policy packs.
Want the 20x context behind this policy? Watch our panel with InfusionPoints on the KSI shift and what it means for teams still on the Rev5 path.
