DevSecOps for FedRAMP Moderate: a 2026 controls-as-code playbook

Why FedRAMP Moderate Is a Different Kind of DevSecOps Problem

Most DevSecOps programs target a “reasonable” control set — OWASP Top 10, CIS Benchmarks, some SOC 2 CC overlap, maybe CIS Critical Controls. FedRAMP Moderate is different. The baseline is NIST SP 800-53 rev 5, Moderate impact, approximately 325 controls. The assessment is performed by an accredited Third-Party Assessment Organization (3PAO) against a documented System Security Plan (SSP). The authorization is granted by a sponsoring agency or the Joint Authorization Board (JAB). The timeline from “we would like to sell to the federal government” to “we have an Authority to Operate (ATO)” is realistically 12–18 months and sometimes longer.

Traditional DevSecOps toolchains — SAST, DAST, SCA, IaC scanning, SBOM generation, runtime security — cover roughly 60% of the Moderate baseline out of the box, mostly in the SI (System and Information Integrity), CM (Configuration Management), and AU (Audit and Accountability) control families. The remaining 40% — AC (Access Control), IA (Identification and Authentication), CP (Contingency Planning), IR (Incident Response), RA (Risk Assessment), PE (Physical and Environmental), and the operational controls — require purpose-built automation. That gap is where most first-time FedRAMP efforts stall.

This post is a 2026 playbook for closing that gap with controls-as-code. It targets engineering leaders who are not yet on the FedRAMP Marketplace, have made the commercial decision to pursue ATO, and want to understand what the DevSecOps discipline actually looks like at FedRAMP Moderate.

The FedRAMP Boundary: The First Architectural Decision

The single most consequential decision in a FedRAMP program is the authorization boundary. The boundary defines which systems, services, and data flows are inside the ATO and which are outside. A tight, well-drawn boundary reduces the control surface by 30–50%; a sloppy boundary drags in everything the company runs and turns the ATO into a multi-year project.

The 2026 pattern that works:

• A dedicated FedRAMP boundary VPC (or GCP project, or Azure subscription) separate from commercial workloads. FedRAMP production data never leaves this boundary. Cross-boundary traffic is explicitly brokered through a documented interconnection agreement.
• Inheritance from a FedRAMP Moderate-authorized cloud provider — AWS GovCloud, Azure Government, or Google Cloud for Government. The cloud provider’s ATO covers 100+ controls automatically; your SSP inherits and references them.
• A dedicated identity plane. Okta Workforce, Microsoft Entra, or a government-boundary IdP. No shared identity with commercial workloads.
• A dedicated CI/CD pipeline inside the boundary or with controlled egress only. Building FedRAMP artifacts from a commercial pipeline fails the boundary test.
• A dedicated observability stack. Splunk Cloud Government, Elastic’s FedRAMP offering, or a self-hosted stack inside the boundary. Logs never leave the boundary.

A tight boundary is the prerequisite for any 2026 controls-as-code effort. Without it, the control mappings have no anchor.

Control Inheritance: The 100-Control Shortcut

AWS GovCloud, Azure Government, and Google Cloud for Government all publish Customer Responsibility Matrices (CRMs) showing which FedRAMP Moderate controls they provide, which are shared, and which are fully the customer’s responsibility. A 2026 first step for any team pursuing FedRAMP Moderate:

1. Select the cloud provider with the closest existing CRM to the architecture the team is building.
2. Pull the CRM from the provider’s FedRAMP Marketplace listing.
3. Accept inheritance for the controls marked “Provider” — typically 100–130 out of 325.
4. Accept inheritance with implementation obligations for the “Shared” controls — typically 80–100.
5. Fully implement the remaining “Customer” controls — typically 90–120.

This reduces the in-scope control count from ~325 to ~170–220. Those remaining controls are where the DevSecOps discipline goes to work.

See the IAN team run on your cloud. We connect to your AWS account via a scoped read-only role, run the Observe-tier agents, and leave you with a concrete audit report — cost waste, security exposure, compliance gaps, and a labor-offset estimate. You keep the findings regardless of next steps. Get a free infrastructure audit →

Controls-as-Code: Mapping NIST 800-53 to CI/CD Artifacts

Controls-as-code is the 2026 discipline of expressing every FedRAMP control as a machine-verifiable artifact produced by the CI/CD pipeline. The mapping is not one-to-one — a single control may require multiple artifacts, and a single artifact may satisfy multiple controls — but the principle is that every control must have a primary artifact that the 3PAO can inspect without a screenshot.

A representative mapping across the major control families:

• AC-2 Account Management → SCIM provisioning logs from the IdP, exported nightly, checked into an immutable store.
• AC-3 Access Enforcement → Terraform IAM policies, OPA policies evaluated in CI, and a nightly drift scan.
• AU-2 Event Logging → Terraform for the CloudTrail/CloudWatch configuration + a log-pipeline health check in CI.
• AU-6 Audit Review → SIEM detection rules as code, reviewed quarterly, PR history as evidence of the review.
• CM-2 Baseline Configuration → Terraform state snapshots + Golden AMI definitions + the Packer build pipeline.
• CM-6 Configuration Settings → CIS Benchmark scans via Chef InSpec, Prowler, or Scout Suite, run nightly.
• CP-9 System Backup → Automated backup configuration in Terraform + a restore-test CI job that runs monthly.
• IA-2 Identification and Authentication → IdP configuration + MFA enforcement policy + the authentication-event export.
• IR-4 Incident Handling → Incident-response runbooks in the repo + a tabletop-exercise CI job that replays a historical incident.
• RA-5 Vulnerability Monitoring and Scanning → SAST + DAST + SCA + container scans in CI, with results piped to the vulnerability-management system.
• SA-11 Developer Testing and Evaluation → The test-suite coverage report + the SAST findings + the penetration test report artifact.
• SC-7 Boundary Protection → Terraform for the VPC, security groups, and network ACLs + a boundary-drift scan in CI.
• SC-8 Transmission Confidentiality → TLS policy enforced in the load balancer configuration + the cert-expiry monitor.
• SI-2 Flaw Remediation → Dependency-update automation (Dependabot, Renovate) + the patch-cadence SLA report.
• SI-4 System Monitoring → SIEM + EDR configuration as code + detection-rule coverage metrics.

Across 170–220 in-scope controls, roughly 140–180 can be expressed as controls-as-code with 2026 tooling. The remaining 20–40 are operational (tabletop exercises, personnel security, physical security for non-cloud components) and require documented process plus evidence of execution — still automatable, just not pure CI/CD artifacts.

The 2026 Toolchain

A representative 2026 FedRAMP Moderate DevSecOps stack:

• Cloud — AWS GovCloud (most common), Azure Government, or Google Cloud for Government.
• Identity — Okta Workforce Identity (FedRAMP Moderate authorized), Microsoft Entra Government, or a government-boundary Keycloak deployment.
• IaC — Terraform or OpenTofu with a Terraform Cloud Government or Env0 Government backend. Chef InSpec, Sentinel, or OPA for policy-as-code.
• SAST/SCA/IaC scanning — Semgrep Pro (FedRAMP roadmap), Snyk Government, GitHub Advanced Security, or Checkmarx. Open-source options: Semgrep Community, OWASP Dependency-Check, Trivy, Checkov.
• Container and runtime — Wiz (FedRAMP Moderate authorized), Prisma Cloud Government, Orca Government, or Falco + KubeArmor for open-source.
• SIEM and observability — Splunk Cloud Government, Elastic’s FedRAMP offering, Chronicle (Google Cloud for Government), or a self-hosted Grafana + Loki + Mimir stack inside the boundary.
• Compliance automation and evidence — Palantir Foundry for some programs, Puppet (Perforce) for configuration compliance, stackArmor for the advisory layer, and Paramify, Atlasity, or Rizkly for the FedRAMP evidence-management workflow itself. Vanta, Drata, Secureframe, and Thoropass are all advancing FedRAMP support in 2026.
• CI/CD — GitLab Ultimate Dedicated for Government (StateRAMP/FedRAMP in progress), GitHub Enterprise Cloud with the Government tier, Harness Government, or a self-hosted Jenkins inside the boundary.

The 2026 buy-vs-build split: buy the cloud, identity, SIEM, and the compliance-evidence workflow. Build the controls-as-code mapping, the drift-detection layer, and the evidence-aggregation pipeline. Buying a GRC tool does not produce an ATO; the team still has to do the controls-as-code work.

The 3PAO Relationship

The 3PAO is not the adversary. A good 3PAO will pre-audit the SSP, flag the weak control statements before they become findings, and help shape the evidence package so it can be assessed efficiently. The 2026 pattern:

1. Select the 3PAO during the SSP drafting phase, not after.
2. Share the in-progress SSP and get feedback on the control-implementation statements.
3. Walk through the controls-as-code pipeline with the 3PAO assessor. They should be able to query the evidence artifacts directly.
4. Run a readiness assessment 30–60 days before the full SAR (Security Assessment Report) engagement.
5. During the SAR engagement, provide evidence artifacts via API or shared read-only access, not PDFs.

Teams that treat the 3PAO as an auditor-only role generate larger POA&Ms (Plans of Action and Milestones) and longer authorization timelines. Teams that treat the 3PAO as a partner from the SSP drafting stage onward compress the authorization timeline by 3–6 months.

Continuous ATO: The 2026 Endgame

The 2025 FedRAMP reform effort (the Authorization Act and the associated OMB guidance) pushed the FedRAMP PMO toward “continuous ATO” — where the authorization is maintained continuously based on live evidence rather than renewed annually via a full SAR. 2026 is the first full year of the new Rev 5 baseline plus the Authorization Act guidance. Teams that design for continuous ATO from day one avoid the trap of optimizing for a one-shot authorization.

The controls-as-code discipline is a prerequisite. Continuous ATO requires live evidence streams for all in-scope controls, a continuous-monitoring dashboard the sponsoring agency can inspect, and a change-management workflow that classifies changes as significant or not-significant with automated evidence for each. Teams running the 2026 DevSecOps toolchain described above can achieve this within 3–6 months after initial ATO; teams running screenshot-and-PDF evidence cannot.

Three-Phase Rollout

Phase 1 — Boundary and inheritance (months 1–3). Define the authorization boundary. Provision the government-cloud environment. Accept inheritance via the cloud provider’s CRM. Stand up the dedicated identity plane and the dedicated CI/CD pipeline. Begin the SSP drafting.

Phase 2 — Controls-as-code (months 4–9). Implement the controls-as-code mapping for all in-scope controls. Wire the evidence-aggregation pipeline. Deploy the SIEM and the detection-rule coverage. Run the first readiness assessment with the 3PAO. Expect 20–40 findings; remediate through the POA&M workflow.

Phase 3 — SAR and continuous monitoring (months 10–15). Execute the full SAR with the 3PAO. Receive the authorization recommendation. Work through agency sponsorship or JAB review. Stand up the continuous-monitoring dashboard and the monthly POA&M cadence. Target continuous ATO status within 6 months of initial authorization.

Total timeline: 12–18 months for a disciplined team starting from a standing engineering organization with no FedRAMP experience. Shorter for teams who reuse an existing FedRAMP-boundary pattern from a parent company. Longer for teams who discover the boundary problem mid-project.

How IAN Helps

IAN produces controls-as-code artifacts out of the box for AC, CM, AU, CP, RA, SA, SC, and SI family controls — the families that map most cleanly to CI/CD pipeline work. The drift-detection layer runs continuously and produces evidence artifacts for CM-2, CM-3, and CM-6. The audit-log pipeline integrates with Splunk Cloud Government and Elastic’s FedRAMP offering to feed AU-2, AU-6, and AU-12. The vulnerability-monitoring integration feeds RA-5 and SI-2.

For teams pursuing FedRAMP Moderate in 2026, IAN reduces the controls-as-code implementation effort for the CI/CD-adjacent controls — the 140–180 controls that account for most of the engineering time — to configuration and review rather than greenfield tooling. The remaining operational controls still require the team’s own process work, but the engineering-heavy part of the ATO effort compresses meaningfully.

Get a free infrastructure audit → | See pricing →