FedRAMP (Federal Risk and Authorization Management Program) is the government-wide standard for cloud security. It's the gate through which any software sold to federal agencies must pass: DoD, DHS, GSA, Intelligence Community, you name it.
In March 2025, the FedRAMP program announced the biggest modernization in its decade-long history. The new framework — FedRAMP 20x — moves away from narrative documentation and toward Key Security Indicators (KSIs) — machine-readable, automatically verifiable security evidence. KSIs themselves were defined later in subsequent RFCs (RFC-0006 for the Phase One Low pilot, RFC-0014 for Phase Two Moderate); the current published KSI document is v0.9.0-beta dated 4 February 2026.
For software teams using autonomous coding agents, this changes everything. Instead of submitting a 500-page security package describing your build process, you're now submitting cryptographically signed attestations proving compliance. And SBOM is a Key Security Indicator — which means your SBOM must be accurate, complete, and reflective of what's actually shipping.
FedRAMP Timeline and Status
Before March 2025
- Agencies submit System Security Plans (SSPs) — 400+ pages of narrative documentation
- FedRAMP reviews over 6-12 months
- Slow, expensive, document-heavy
March 2025: FedRAMP 20x Announced
- New authorization approach announced: machine-readable evidence over narrative docs
- Continuous monitoring positioned as the centrepiece (continuous monitoring itself has always been part of FedRAMP — the change is the move to machine-readable KSI evidence rather than narrative attestation)
- The March 2025 announcement itself does not yet name "Key Security Indicators"; KSIs were introduced in RFC-0006 (Phase One Low pilot)
KSI Definition and Phase One Pilot (late 2025 — September 2026)
- RFC-0006 defined the Phase One KSIs for FedRAMP Low
- KSI document v0.9.0-beta published 4 February 2026 on
fedramp.gov/docs/20x/key-security-indicators - Phase One pilot completed September 2026, with participating CSPs granted conditional FedRAMP Low authorization
Status Today (April 2026)
- KSI documentation is published in beta and operational (no longer "not yet published")
- Phase One (Low impact) pilot is in progress; conditional authorizations expected at pilot close in September 2026
- Phase Two (Moderate impact) is in progress per RFC-0014
- New Low-impact applications should assume FedRAMP 20x KSI requirements
Future (2027+)
- FedRAMP 20x expected to become the standard authorization path as Moderate-impact KSIs stabilise
- Legacy FedRAMP pathways enter a transition period
Note: FedRAMP 20x is the official program name (not "informal"). The KSI specification is in beta — engage with the program directly via the RFC process and the FedRAMP roadmap.
Key Security Indicators (KSIs)
FedRAMP 20x shifts from "describe your security controls" to "prove your controls are working." KSIs are the proof.
Examples of KSIs:
| Category | Legacy Approach | KSI Approach |
|---|---|---|
| Build Security | "We have secure build practices" (narrative) | Signed SLSA provenance attestation + SBOM (machine-readable) |
| Dependency Management | "We track dependencies" (narrative) | Machine-readable SBOM with vulnerability scan results |
| Code Review | "Code is reviewed before merge" (narrative) | Audit log showing review approval + automated metrics |
| Testing | "We conduct security testing" (narrative) | SCA/SAST scan results, coverage percentages, remediation timelines |
| Patch Management | "We patch within X days" (narrative) | Automated CVE-to-patch tracking with evidence of deployment |
For each KSI, agencies can query compliance continuously — not once a year, but in real time.
SBOM as a Key Security Indicator
Under FedRAMP 20x, SBOM is elevated from "nice to have" to mandatory Key Security Indicator.
What must be in the SBOM:
Following CISA 2025 Minimum Elements, every SBOM must contain:
| Element | Why It Matters for FedRAMP |
|---|---|
| Supplier Name | Establishes chain of custody |
| Component Name + Version | Enables CVE tracking |
| Unique Identifier (PURL) | Enables automation (CVE lookup, vulnerability scan correlation) |
| Dependency Relationships | Enables "blast radius" assessment — which deployments affected by a CVE? |
| License Info | Establishes export control and legal compliance |
| Timestamp | Proves when SBOM was generated |
| Tool that created it | Proves SBOM is machine-generated, not manually assembled |
For AI-coded software, no published KSI yet requires AI attribution metadata in the SBOM. Crash Override recommends adding it as a forward-looking best practice:
- AI Attribution Metadata — Which components were generated or modified by AI agents (Crash Override-recommended schema, not a current KSI requirement)
Why? Because if a vulnerability is found in your code and it turns out an agent generated the vulnerable patch, federal auditors will ask:
- "What was the agent's prompt?"
- "Was the patch reviewed before deployment?"
- "If reviewed and the vulnerability was missed, what's your remediation?"
Having AI attribution metadata in the SBOM lets you answer these questions automatically. Without it, every vulnerability becomes a security incident investigation.
Authorization Timeline Under FedRAMP 20x
Phase 1: Intake (Month 1)
- Submit application with KSIs (not narrative SSP)
- Include SBOM (CycloneDX or SPDX format)
- Include signed SLSA provenance attestations
- Include SCA/SAST scan results
- Include code review metrics
Phase 2: Initial Assessment (Months 2–3)
- FedRAMP verifies KSIs are accurate
- Automated verification where possible (SBOM validation, signature verification)
- If KSIs show compliance: "In Process" granted (90–180 days)
- If gaps found: Request additional evidence or remediations
Phase 3: Continuous Monitoring (Months 4+)
- You continuously update SBOMs and KSIs as you release updates
- FedRAMP continuously monitors for compliance drift via the KSI evidence stream
- KSIs change how continuous monitoring is evidenced (machine-readable signals rather than narrative reports) — they do not abolish FedRAMP's authorization decision or its periodic reauthorization process. Continuous monitoring has always been a FedRAMP requirement; the move under 20x is to make it auditable from the evidence stream itself.
- If a vulnerability is discovered in your software, FedRAMP monitors your response (CISA KEV catalog integration)
Timeline benefit: Early applicants reporting clean KSIs are getting "In Process" within 90 days, vs. 6–12 months under legacy FedRAMP.
AI-Generated Code and FedRAMP Authorization
FedRAMP doesn't explicitly prohibit AI-generated code. It does require provenance. Here's what that means:
For Agent-Generated Code in Non-Critical Paths
What you must prove:
- Code was generated by [specific agent + version]
- Code was reviewed before merge (review record + reviewer name required)
- Code passed same testing as human code
How to prove it (example of a Crash Override-recommended schema — not a FedRAMP-defined format):
{
"commit": "abc123...",
"author": "copilot-agent",
"author_type": "autonomous-ai",
"model": "copilot/coding-agent/2026-q1-v4",
"reviewed_by": "[email protected]",
"review_timestamp": "2026-04-29T10:00:00Z",
"testing": {
"coverage": 89,
"sast_issues_found": 2,
"sast_issues_resolved": 2
}
}
Add this to your SBOM metadata as AI-attribution tags.
For Agent-Generated Code in Critical Paths
The items in this section are Crash Override recommendations, not published FedRAMP requirements. No current KSI mandates dual reviewers, 100% coverage, or federal-employee-only reviewers for AI-generated code. Treat them as a defensible internal standard you can justify to a 3PAO, not as compliance text.
What we recommend you prove:
- Code was generated by [specific agent + version]
- Code was reviewed by two independent reviewers (internal control — not a FedRAMP rule)
- Code has 100% test coverage on the affected critical path (internal control)
- Code underwent additional security analysis (e.g., manual code review by a security specialist)
- A human takes explicit accountability for this code in production
How to evidence it:
- Dual reviewer signatures captured in your code-review system
- Coverage metrics showing 100% on the critical path
- Security review sign-off document
- Audit log showing who deployed and when
Recommendation: Avoid agent-generated code in critical authentication, cryptographic, and access control paths. If you must use it, the internal review burden — and the explanatory burden with your 3PAO — is substantial.
What FedRAMP Does NOT Accept
- Agent-generated code with no human review
- Unsigned SBOMs
- SBOMs missing transitive dependencies
- SBOMs older than the current release
- Agent commits with no audit trail
- Automatic merges (FedRAMP now requires code review approval records)
Practical Checklist: FedRAMP 20x Readiness
Before You Apply
- SBOM generated at build time for every release
- SBOM includes all direct and transitive dependencies
- SBOM uses CycloneDX 1.6+ or SPDX 2.3+
- SBOM is signed with Sigstore or equivalent
- AI-attribution metadata added to SBOM for agent-generated components
- SLSA provenance attestation generated for every build artifact
- Code review records available (digital approval signatures)
- SCA/SAST scan results available (with agent-code flagged separately)
- Patch management process documented (CVE response timeline)
- Audit logs available (who deployed what, when)
Application Package
- SBOM (in
.well-known/sbom/folder) - SLSA provenance attestations (signed, with AI metadata)
- SCA/SAST reports (latest scan for current release)
- Code review metrics (X% of code reviewed before merge, Y% reviewed by 2+ reviewers)
- Test coverage report (overall and by component type)
- Build system documentation (how builds are authorized, who can release)
- Security policy document (how you handle vulnerabilities, agent governance)
Continuous Compliance (Post-Authorization)
- Monthly SBOM updates as releases ship
- Vulnerability notification subscriptions (CISA KEV, Sonatype, GitHub)
- Patch deployment tracked and reported to FedRAMP
- Audit logs retained (minimum 5 years)
- Annual compliance verification (FedRAMP spot checks)
Integration with NIST and CISA
FedRAMP 20x aligns with:
- NIST SP 800-218 (SSDF v1.1) — SSDF self-attestation aligns directly with FedRAMP KSI evidence (SSDF has no maturity levels — federal procurement uses the CISA SSDF Self-Attestation Form). Pair with SP 800-218A for AI-relevant practices.
- CISA 2025 SBOM Minimum Elements — Use these as the baseline for your SBOM
- CISA KEV Catalog — FedRAMP now integrates KEV into continuous monitoring
- Executive Order 14028 — The mandate that started this whole chain
If you're already SSDF-compliant, you have most of the KSIs FedRAMP needs.
Timeline Recommendations
If you're targeting FedRAMP authorization:
- Now (April 2026): Audit SBOM generation. Implement Sigstore signing. Tag agent-code in commits.
- Q2 2026: Set up continuous SCA/SAST scanning. Document code review process.
- Q3 2026: Implement FedRAMP 20x KSIs. Validate SBOM accuracy. Get legal review of AI-generated code liability.
- Q4 2026: Submit FedRAMP application under 20x pathway.
Expected outcome: "In Process" within 90 days if KSIs are clean.
References
- FedRAMP Modernization Announcement (March 2025) — Original 20x announcement
- FedRAMP 20x Key Security Indicators (v0.9.0-beta, 4 Feb 2026) — Current KSI document
- FedRAMP RFC-0006 — Phase One (Low) KSIs — KSI definitions for the Low pilot
- FedRAMP RFC-0014 — Phase Two (Moderate) KSIs — Moderate-impact KSIs
- FedRAMP roadmap (GitHub) — Live program tracking
- CISA 2025 SBOM Minimum Elements (Draft for Comment, comment period closed Oct 2025) — Baseline for SBOM content
- NIST SP 800-218 — Secure Software Development Framework v1.1 — Aligns with FedRAMP KSIs
- NIST SP 800-218A — SSDF Generative AI / Dual-Use Foundation Model Profile — AI-relevant SSDF extension (July 2024)
- SLSA Framework — Build provenance standard
- Sigstore Documentation — Keyless signing for attestations