RFC mapping: how Efterlev's outputs map to FedRAMP 20x standards¶
A reviewer-ready table showing exactly which Efterlev artifact satisfies which FedRAMP RFC / standard requirement. Updated 2026-05-19 based on the May 2026 research dive into program state.
Purpose: 3PAO conversations move faster when the reviewer can see "Efterlev's POA&M maps to RFC-0017 §required; Efterlev's VDR maps to RFC-0012 §required" without having to reverse-engineer it themselves. This is that table.
Status badge meanings:
| Badge | Meaning |
|---|---|
| 🟢 Shipped | Efterlev produces the artifact in a default report run. |
| 🟡 Shipped opt-in | Available behind a flag or separate command. |
| 🔵 Planned | On the roadmap; named release version below. |
| ⚪ N/A | Out of scope for Efterlev (e.g., agency-side, runtime, or policy-level). |
FRMR catalog state¶
| Field | Value |
|---|---|
| Live FRMR version | v0.9.43-beta (2026-04-08) |
| Vendored copy | Same; SHA-pinned in src/efterlev/paths.py |
| Drift CI gate | .github/workflows/frmr-drift.yml (daily cron + PR-trigger; v0.1.164) |
| KSI count | 60 across 11 themes (AFR=10, CMT=4, CNA=8, CED=4, IAM=7, INR=3, MLA=5, PIY=5, RPL=4, SVC=8, SCR=2) |
| Source of truth | https://github.com/FedRAMP/docs/blob/main/FRMR.documentation.json |
| Per-theme cross-check | Verified against https://www.fedramp.gov/docs/20x/key-security-indicators/ 2026-05-19 |
RFC-by-RFC mapping¶
RFC-0012 — Continuous Vulnerability Management Standard (VDR)¶
Status (FedRAMP): Closed for public comment 2025-08-21; expected in 2026
Consolidated Rules. Applies to FedRAMP 20x primarily.
Status (Efterlev): 🟢 Shipped in v0.1.162 (standalone command) +
v0.1.163 (default-on in report run + CVE harvest from Security Hub
findings).
| RFC requirement | Efterlev artifact | Code location |
|---|---|---|
| Internal identifier per finding | VdrEntry.internal_id (VDR-<KSI>-<idx>) |
src/efterlev/primitives/generate/generate_vdr_report.py |
| CVE IDs | VdrEntry.cve_ids (harvested from Evidence.content["cve_ids"]; populated by Security Hub ASFF Vulnerabilities[] parser) |
src/efterlev/imports/security_hub/parser.py |
| Detection timestamp | VdrEntry.detection_timestamp (scan time) |
(same primitive) |
| Mitigation / remediation deadlines | VdrEntry.mitigation_deadline + remediation_deadline; heuristic 7d/21d default, basis field spells out 3d-tightening rule per RFC |
(same primitive) |
| Internet-reachable status | VdrEntry.internet_reachable (defaults REVIEW — IaC scanners can't reliably infer; reviewer marks) |
(same primitive) |
| Exploitability + impact | VdrEntry.exploitability (DRAFT) + VdrEntry.impact (derived from severity) |
(same primitive) |
| Mitigation + remediation plans | DRAFT placeholders; reviewer fills | (same primitive) |
| Actions taken | VdrEntry.actions_taken list (starts empty) |
(same primitive) |
| Status | VdrEntry.status (open / in_progress / mitigated / remediated) |
(same primitive) |
| Machine-readable + human-readable formats | JSON + markdown, both emitted side-by-side | efterlev vdr CLI |
| Schema version pin | vdr_schema_version: "0.1.0-draft-rfc-0012" so consumers detect breaking changes when RFC finalizes |
(same primitive) |
Output paths:
- efterlev-out/reports/vdr/vdr-<ts>.json
- efterlev-out/reports/vdr/vdr-<ts>.md
Coverage gap: deadlines + internet-reachable + exploitability ship as heuristic DRAFTs. Reviewer must adjust before submission — the IaC layer can't determine these. Documented in the artifact itself.
RFC-0017 — Persistent Validation and Assessment Standard (PVA)¶
Status (FedRAMP): Closed for public comment 2025-11-17; foundational for 20x. Status (Efterlev): 🟢 Shipped across multiple releases. v0.1.164 closed the last item (consolidated resource inventory).
PVA requires 5 items per KSI:
| RFC §required item | Efterlev artifact | Code location |
|---|---|---|
| 1. Implementation goal with pass/fail criteria | KSI catalog itself (FRMR vendored copy); pass/fail emerges from detector findings + Gap Agent classification | catalogs/frmr/ + src/efterlev/agents/gap.py |
| 2. Consolidated resource inventory | 🟢 efterlev inventory (v0.1.164) — JSON + HTML, grouped by resource_type, with ksi_coverage + boundary_state per resource |
src/efterlev/primitives/generate/generate_inventory.py |
| 3. Automated validation processes + cadence | [cadence] machine_validation_cadence in workspace config + .github/workflows/pr-compliance-scan.yml (per-PR scan) |
src/efterlev/config.py + templates/pr-compliance-scan.yml |
| 4. Human validation processes + cadence | [cadence] non_machine_validation_cadence + Evidence Manifests under .efterlev/manifests/*.yml with per-manifest next_review date |
src/efterlev/config.py + src/efterlev/primitives/evidence/load_evidence_manifests.py |
| 5. Current status + clarifications | FRMR attestation JSON + Documentation Agent narratives | src/efterlev/agents/documentation.py |
Per-KSI deliverables RFC-0017 wants:
| RFC requirement | Efterlev artifact |
|---|---|
| High-level summary per KSI | FRMR attestation (attestation-<ts>.json); Documentation Agent's per-KSI narrative |
| Assessment results from 3PAOs | Submission package zip provides one deliverable; 3PAO assessment is human-side |
| Documentation of significant changes | Reserved for RFC-0031 (SCN) integration — not yet built |
| Vulnerability reports for validation failures | VDR + POA&M (covered above) |
Output paths:
- efterlev-out/reports/inventory/inventory-<ts>.{json,html}
- efterlev-out/reports/attestation-<ts>.json
- efterlev-out/reports/documentation-<ts>.{html,json}
Cadence semantics match RFC-0017 exactly:
- Moderate: machine validation every 3 days (we run per-PR + on-save); human every 3 months (per-manifest next_review)
- Low: machine every 7 days; human every 3 months
RFC-0024 — Machine-Readable Packages (OSCAL)¶
Status (FedRAMP): Closed for public comment 2026-03-11. Applies to Rev5 only — explicitly NOT 20x per the RFC text. 20x deliberately keeps room for non-OSCAL formats. Status (Efterlev): 🟢 Shipped in v0.1.105–v0.1.111. Over-deliver for 20x; exactly-right for Rev5 customers.
| RFC requirement | Efterlev artifact | Code location |
|---|---|---|
| Machine-readable POA&M | OSCAL 1.0.4 POA&M JSON | src/efterlev/primitives/generate/generate_poam_oscal.py |
| Machine-readable Component-Definition | OSCAL 1.0.4 Component-Definition JSON | src/efterlev/primitives/generate/generate_component_definition_oscal.py |
| Schema validation | NIST oscal-cli + Python rules layer + JSON Schema gates in CI | src/efterlev/primitives/validate/validate_oscal_*.py + .github/workflows/oscal-cli-conformance.yml |
Output paths:
- efterlev-out/reports/oscal/poam-<ts>.json
- efterlev-out/reports/oscal/component-definition-<ts>.json
RFC-0016 — Collaborative Continuous Monitoring (CCM)¶
Status (FedRAMP): Closed 2025-11-17; foundational for 20x ConMon. Status (Efterlev): 🔵 Planned for v0.1.165–166 (Arc 3 of the May 2026 research plan).
| RFC requirement | Efterlev artifact | Status |
|---|---|---|
| Streaming event log per validation cycle | efterlev conmon append — NDJSON event stream, one event per report run |
Planned v0.1.165 |
| Trigger-frequency view per KSI | efterlev conmon report --since <window> |
Planned v0.1.166 |
| Scheduled-run GitHub Action | Bundled workflow template | Planned v0.1.166 |
Note: today's posture (per-PR scan via the bundled workflow) meets RFC-0017's 3-day Moderate cadence; CCM's streaming framing is the next-shape-up.
RFC-0026 — CA-7 Continuous Monitoring Expectations (Rev5)¶
Status (FedRAMP): Closed 2026-04-22. Rev5-only. Effective upon publication; grace through 2026-12-31; enforcement 2027-01-01. Status (Efterlev): 🟢 Shipped via VDR + planned CCM (both covered above). Customers can opt into either traditional CA-7 paths or the VDR/CCM improvement releases that RFC-0026 explicitly accepts as alternative pathways.
RFC-0030 — Rev5 Baseline Update (RA/SA/SC/SI/SR)¶
Status (FedRAMP): Closed 2026-04-22. Rev5-only. Will be in 2026 Consolidated Rules. Status (Efterlev): Mostly already covered by existing detectors; RA-05 vulnerability-monitoring pathway aligns with our VDR (covered above). No new detector work required from the v0.1.164 baseline.
RFC-0031 — Incident Communications Procedures¶
Status (FedRAMP): Closed 2026-05-12. Both Rev5 and 20x. Effective
2027-01-01 for most requirements.
Status (Efterlev): 🟡 Procedural — partially covered today via
the KSI-AFR-ICP evidence manifest (govnotes-demo has one). The
quantitative requirements (impact-rating N1-N5, status-page, 15-min
notification SLA for Class D/N5) are operational, not scanner-able;
covered via Evidence Manifests on the customer side.
| RFC requirement | Coverage |
|---|---|
| Documented incident-communication playbook | Evidence Manifest for KSI-AFR-ICP (customer-authored) |
| Status-page presence (Class C/D MUST) | ⚪ N/A — operational artifact, not IaC |
| Impact-rating + notification SLA | ⚪ N/A — operational policy |
| Initial/Ongoing/Final incident reports | ⚪ N/A — reporting workflow |
RFC-0020 / RFC-0021 — Authorization Designations + Marketplace¶
Status (FedRAMP): Released 2026-01-13. Program-structural. Status (Efterlev): ⚪ N/A — these change FedRAMP's authorization classification system (Class A pilot / B Low / C Moderate / D High) and Marketplace UX. Efterlev produces the same artifacts regardless of which class a customer pursues; no code changes needed.
Coverage matrix summary¶
| Standard / RFC | Applicability | Efterlev today | Gap |
|---|---|---|---|
| FRMR KSI catalog (v0.9.43-beta, 60 KSIs) | 20x | 🟢 Vendored + drift gate | None |
| RFC-0012 (VDR) | 20x | 🟢 v0.1.163 default-on | Internet-reachable + exploitability are DRAFT (reviewer fills) |
| RFC-0017 (PVA — 5 items per KSI) | 20x | 🟢 All 5 items covered (inventory closed last gap at v0.1.164) | SCN integration (RFC-0031) pending |
| RFC-0024 (OSCAL Rev5) | Rev5 | 🟢 v0.1.105–111 (over-deliver for 20x) | None |
| RFC-0016 (CCM) | 20x | 🔵 Planned v0.1.165-166 | Streaming event shape |
| RFC-0026 (Rev5 CA-7) | Rev5 | 🟢 Via VDR + planned CCM | None |
| RFC-0030 (Rev5 baseline) | Rev5 | 🟢 Existing detectors + VDR | None |
| RFC-0031 (Incident Comms) | Both | 🟡 Procedural manifest | Operational artifacts (status page, SLA timing) ⚪ N/A |
| RFC-0020 / 0021 (designations / marketplace) | Program | ⚪ N/A | None |
Things to know if you're a 3PAO reviewing Efterlev output¶
-
VDR is ahead-of-RFC-0012-finalization. We pin
vdr_schema_versionso a downstream consumer detects the shape change when the RFC standardizes and we revise. -
Inventory uses
inventory_schema_versionfor the same reason. RFC-0017 doesn't lock the field-name convention; we'll revise alongside any final-RFC change. -
OSCAL output validates against three independent gates: NIST OSCAL 1.0.4 JSON Schema (
validate_oscal_*), Python-native FedRAMP rule layer (validate_oscal_fedramp_rules), and the official NIST oscal-cli (Java; runs in CI via theoscal-cli-conformance.ymlworkflow). -
Every artifact carries a DRAFT marker at the type level. The
requires_review: Literal[True]field on Claim is not a string, not a flag — there's no path to a non-DRAFT artifact through the tool. A human reviewer is the only path to "ready for submission." -
Cadence semantics match RFC-0017 exactly. Moderate = machine every 3 days, human every 3 months. We meet the machine cadence via per-PR scans; the human cadence via per-manifest
next_review. -
The KSI catalog is content-addressed and hash-verified. Any tampering with the vendored FRMR raises
CatalogLoadErroron init.
Maintenance¶
Update this file when: - A new RFC closes or finalizes - An Efterlev release adds a new artifact or changes an existing one - The KSI catalog count or per-theme breakdown changes - A new gap surfaces from a customer interaction
The drift gate at scripts/check_frmr_ksi_count.py catches FRMR
catalog bumps; the rest is manual but small.