This comprehensive guide addresses Department of Defense (DoD) Impact Level certification for cloud-native products. The framework encompasses 622 controls across 20 families spanning four impact levels, with 11 steps required to achieve Provisional Authorization.
The largest jumps occur at IL5:
Other significant families include Access Control (65 controls across all levels) and Audit & Accountability (37 controls at IL6).
CSP DevSecOps Environment:
Agency-Owned Infrastructure:
Your Product (Cloud Service Offering):
Cross-Infrastructure Security:
Continuous Monitoring:
Ten binary pass/fail requirements evaluated before formal control assessment:
| Requirement | IL2 | IL4 | IL5 | IL6 |
|---|---|---|---|---|
| Privileged Access | Tier 1/NACI | Tier 3/MBI | Tier 3/Secret | Tier 5/TS/SCI |
| Non-Privileged | N/A | Tier 1 | Tier 3/Secret | Tier 5/TS/SCI |
| Citizenship | Not required | U.S. Citizens | U.S. Citizens | U.S. Citizens |
| Data Location | Any | CONUS | CONUS | CONUS |
Beyond baseline controls, systems handling specific data types face additional overlay requirements:
An IL5 system processing combined CUI and PHI could require 588 baseline controls plus overlay additions.
DoD cloud authorization represents a foundational product architecture decision rather than a post-development compliance exercise. The IL4-to-IL5 transition particularly marks a discontinuous jump in requirements, infrastructure complexity, and operational overhead. Successful authorization demands early planning, sustained stakeholder coordination, and architecture decisions embedded from inception.
]]>This framework extends MIT’s Dual-Use Readiness Levels by introducing a sixth dimension: authorization to operate (ATO). The article presents “Authorization Readiness Levels (ARL),” which maps five distinct government authorization pathways across nine progression levels each.
FARL (FedRAMP Authorization): Federal civilian cloud authorization under Rev 5 and the emerging 20x continuous validation pathway, managed by GSA’s FedRAMP PMO.
RARL (DoD RMF Authorization): The Department of Defense Risk Management Framework pathway through eMASS, governed by NIST 800-53 and DISA STIGs.
IARL (Impact Level Authorization): The DoD Cloud Computing Security Requirements Guide pathway to IL4, IL5, and IL6 Provisional Authorizations, managed by DISA.
CARL (Continuous ATO): A DevSecOps-native pathway aligned with DoD Enterprise DevSecOps Reference Design and the Software Fast Track initiative.
CMRL (CMMC Certification): The Cybersecurity Maturity Model Certification pathway protecting Controlled Unclassified Information across the defense industrial base, affecting approximately 80,000+ contractors.
Every pathway follows this progression:
Levels 1-3 focus on discovery and planning; 4-6 involve building and assessment; 7-9 address authorization and scaling operations.
The framework emphasizes designing for authorization from inception, treating Authorizing Officials as mission customers, and budgeting authorization as a market-unlocking product feature. A $1.5M FedRAMP investment that unlocks $50M in addressable government revenue represents significant leverage.
Authorization stages typically align with specific Technology Readiness Levels (TRL) and other MIT dual-use dimensions, with architecture decisions at TRL 3-5 being the most cost-effective time for compliance design.
]]>This article addresses a fundamental challenge for federal government contractors: operating modern CI/CD pipelines using external tools like GitHub or GitLab while maintaining FedRAMP, DoD Impact Level, or agency-specific ATO compliance.
The proposed three-stage pipeline follows this pattern:
The architecture maps to specific controls:
Monthly deliverables include vulnerability scan reports, POA&M updates, and integrity assessments. Quarterly privilege reviews verify developer access controls. Annual submissions cover SSP updates, CM plans, and penetration testing results.
Using non-authorized external SCM requires documented risk acceptance or POA&M entries. Organizations unable to tolerate this risk may deploy GitLab self-hosted, AWS CodeCommit on GovCloud, or GitHub Enterprise within the authorization boundary — particularly appropriate for DoD IL5 environments where DISA scrutiny is heightened.
]]>This article examines how the Authority to Operate (ATO) process, designed to manage risk in federal systems, has become a bureaucratic obstacle extending 12-18 months rather than an efficient security decision.
The System Security Plan (SSP) typically consists of hundreds of pages describing control implementation in narrative form. The document is a snapshot of a conversation, not an audit of a system. This creates rework cycles as assessors find inconsistencies between documentation and actual configurations.
Organizations gather compliance evidence through screenshots, scanner exports, and policy documents — a time-consuming, stale, and inconsistent approach. This manual process incentivizes “compliance theater” where teams optimize for appearance rather than genuine security.
NIST 800-53 controls’ abstract language creates different interpretations across assessors and agencies, making authorization targets unpredictable.
Authorization, assessment, and Authorizing Official review queues often represent the longest elapsed time blocks — factors outside the development team’s control.
The ATO bottleneck is not fundamentally a documentation problem or a process problem. It is an information quality problem. Authorizing Officials make critical risk decisions based on stale, static documents rather than current system evidence, forcing risk-averse approvers to delay decisions.
Rather than point-in-time authorization, systems provide live compliance dashboards enabling ongoing Authorizing Official oversight and faster risk decisions.
Organizations need “GRC engineers” — hybrid professionals bridging compliance and engineering expertise. The shared responsibility model in cloud environments creates additional complexity requiring clear control inheritance matrices.
Future authorization challenges include AI/ML system frameworks, post-quantum cryptography migration, and supply chain assurance through continuous dependency monitoring.
The framework itself is sound, but the gap between how we build systems and how we prove they are secure requires closure through automated telemetry and live evidence rather than static documentation.
]]>This post examines the practical challenges of implementing FedRAMP 20x, despite its conceptual promise to modernize federal cloud authorization processes.
FedRAMP 20x shifts from documentation-heavy assessments to automation-driven validation. Rather than submitting extensive narratives covering 325+ NIST 800-53 controls, providers now demonstrate security through machine-readable evidence and continuous telemetry from infrastructure, identity systems, and scanning tools.
FedRAMP 20x does not reduce the total work required to achieve authorization. It changes who does the work and what skills they need to do it. The compliance burden moves from GRC analysts to engineering teams who must build telemetry pipelines and integrations across heterogeneous environments — often more difficult than traditional documentation work.
DISA, which manages defense cloud authorizations, has not adopted the 20x framework. DoD providers still must produce traditional documentation alongside any 20x artifacts, effectively doubling compliance work rather than reducing it.
Larger agencies with mature cloud programs may embrace 20x early, while smaller agencies with limited IT security staff face steeper implementation challenges. Individual agency Authorizing Officials may remain skeptical of automated evidence models.
Third-party assessors lack the infrastructure engineering expertise needed to evaluate automated validation logic and telemetry pipelines. This skills gap will slow adoption and create inconsistent assessment quality during transition periods.
Middleware platforms positioning themselves for 20x cannot serve all federal environments equally. Integration challenges persist across multi-cloud, hybrid deployments with diverse security tools.
The IC operates under separate authorization frameworks and will adopt 20x-aligned approaches on its own timeline, distinct from civilian and defense schedules.
FedRAMP 20x is not a silver bullet. The framework is strategically sound, but full implementation across federal agencies will require years. Success depends on navigating both the new technical requirements and existing institutional realities across multiple government sectors.
]]>The Authority to Operate (ATO) represents formal approval that a system meets acceptable risk levels for federal government use. Standard timelines stretch 12-18 months, but this duration is incompatible with modern software delivery practices. Organizations embedding compliance into engineering workflows from inception can compress timelines to weeks rather than months.
System Security Plans written after development concludes often contain inconsistencies between actual implementations and documented controls. Architecture diagrams become outdated, and shared responsibility boundaries remain unclear.
Screenshots, configuration exports, and policy documents require extensive manual gathering. This evidence frequently becomes stale before reaching assessors.
Security testing deferred until assessment phases uncovers critical vulnerabilities at the worst moment, triggering remediation cycles and rescans.
Cloud-hosted systems can inherit numerous controls from infrastructure providers, but poorly documented inheritance creates duplication or gaps that assessors flag.
Coordination between engineering, security, compliance, and leadership introduces calendar delays beyond technical factors.
Building on known-good security foundations eliminates vulnerabilities before assessment begins:
This foundation dramatically reduces assessment findings and shortens Plan of Action and Milestones (POA&M) documentation.
Generate compliance evidence as operational byproducts rather than separate exercises:
This transforms evidence gathering from week-long exercises into API calls or log queries, producing higher-quality, current documentation.
FedRAMP-authorized cloud environments cover over 100 controls that systems can fully or partially inherit. Create a clear control responsibility matrix documenting whether each NIST 800-53 control is:
Referencing the cloud provider’s Customer Responsibility Matrix and mapping to System Security Plan descriptions reduces implementation burden and provides assessment traceability.
Embedding security testing in development pipelines catches vulnerabilities during normal workflows rather than under assessment pressure:
Systems reaching assessment are already clean, eliminating high-pressure remediation cycles.
Ongoing monitoring programs provide real-time security visibility and support continuous ATO (cATO) approaches:
Continuous monitoring shortens reauthorization cycles and builds authorizing official trust.
Each strategy shares a common thread: eliminating manual overhead through automation. The difference between 14-month and 14-week timelines involves automating rigorous processes rather than skipping steps.
The organizations that move fastest through ATO are not the ones that take shortcuts — they are the ones that automate the rigor. Accelerating ATO does not lower security standards; it builds engineering discipline to meet standards from the beginning.
]]>The software supply chain has transitioned from a niche security topic to executive-level priority remarkably quickly. Executive Order 14028, signed in May 2021, mandated that organizations selling software to the federal government must provide a Software Bill of Materials. However, creating an SBOM and using it effectively for risk reduction are distinct challenges. Nearly five years later, many organizations generate SBOMs purely for compliance purposes while failing to leverage them as operational security tools.
Executive Order 14028, titled “Improving the Nation’s Cybersecurity,” tasked NIST with establishing SBOM guidelines and software supply chain security standards. Key requirements include:
A crucial distinction is that the executive order treats SBOMs not as static compliance documents, but as operational security tools. The intent enables agencies to ingest SBOMs, cross-reference vulnerabilities, and make informed procurement decisions.
Generating an SBOM involves significant challenges across different software ecosystems. The two dominant formats serve different purposes:
Popular tools include syft, trivy, cdxgen, and Microsoft’s sbom-tool, each with different approaches:
The practical recommendation is employing multiple tools simultaneously and merging outputs for comprehensive coverage.
Four pillars support an effective SBOM program:
SBOM generation should be automated within build pipelines, placed after dependency resolution but before artifact publication.
Cross-referencing SBOM components against vulnerability databases transforms the document into a security tool. Platforms like Dependency-Track enable continuous CVE matching against NVD, OSV, and vendor feeds. Configuration should suppress false positives and route critical findings to ticketing systems.
SBOMs contain license information for every component. Copyleft licenses like GPL-3.0 and AGPL can conflict with proprietary distribution models. Automated policy gates should flag restricted or unknown licenses before builds complete.
Comparing SBOMs across releases reveals unexpected component inventory changes. Drift detection identifies version jumps, unvetted new components, and reappearance of patched vulnerabilities — catching supply chain anomalies that vulnerability scanning alone might miss.
The distinction between snapshot and continuously maintained SBOMs is the difference between compliance theater and actual security. Living SBOMs require:
Federal requirements increasingly demand VEX documents alongside SBOMs, particularly in defense and intelligence sectors.
SBOMs transcend compliance requirements when organizations integrate them throughout development and security operations, enabling continuous vulnerability tracking and supply chain visibility. The gap between generating JSON files and running mature SBOM programs spans tooling, CI/CD integration, vulnerability correlation, license enforcement, drift detection, and continuous evaluation.
Organizations should start with CI/CD integration, add vulnerability correlation, and expand from there. Those investing in SBOM operationalization now will be best positioned to respond when supply chain incidents demand immediate answers.
]]>The Department of Defense is rapidly integrating artificial intelligence across military operations — from autonomous surveillance to predictive logistics and intelligence analysis. While this transformation offers significant advantages, it introduces novel security vulnerabilities that differ fundamentally from traditional software threats.
Military AI systems face unique pressures: failures carry catastrophic consequences, adversaries are nation-state actors with dedicated research programs, and deployment occurs in contested environments with limited connectivity. The attack surface spans the entire lifecycle, from training data through deployment.
Crafted inputs designed to fool models while appearing normal to humans. Researchers have demonstrated adversarial patches that, when printed and applied to real-world objects, consistently fool state-of-the-art classifiers. These attacks exploit transferability — adversarial examples work across multiple models.
Malicious samples injected into training datasets create hidden backdoors. Poisoning can be extremely subtle, affecting less than one percent of training data while embedding reliable trigger behaviors.
Attackers reconstruct models through repeated queries, gaining understanding of capabilities and enabling development of countermeasures. This poses particular risks given classified training data in defense contexts.
Malicious instructions embedded in data cause language models to deviate from intended behavior. “Indirect prompt injection,” where attacks hide in external data sources, represents special danger because analysts may trust processed output without reviewing raw sources.
Compromised ML frameworks, trojaned pre-trained models, and tainted datasets create systemic vulnerabilities. ML supply chain attacks can be functionally invisible since malicious behavior lives in model weights rather than analyzable code.
MITRE’s ATLAS framework provides structured taxonomy of adversarial tactics across the AI lifecycle. Defense organizations should integrate ATLAS into threat modeling, red teaming, detection engineering, and stakeholder communication.
Dedicated AI red teams should conduct structured assessments using MITRE ATLAS, with automated adversarial testing in CI/CD pipelines and manual exercises at regular intervals.
Establish continuous monitoring for:
Apply critical infrastructure security to data ingestion, model training, validation, deployment, artifact storage, and serving configurations.
Align with the NIST AI Risk Management Framework’s four functions: Govern, Map, Measure, and Manage. Integrate requirements into existing ATO processes.
The security of AI systems cannot be treated as an afterthought or a separate workstream but must be embedded throughout the entire lifecycle. Defense organizations must develop specialized AI security capabilities before adversaries fully exploit these emerging vulnerabilities.
]]>Q1 2026 represents a major milestone for Optimal’s platform, delivering capabilities security teams and developers have requested. The update spans runtime monitoring, compliance automation, and supply chain visibility, benefiting security engineers, compliance leaders, and developers integrating security into CI/CD pipelines.
Optimal introduces real-time runtime threat detection for Kubernetes and containerized workloads. Built on eBPF technology, the runtime agent operates at the kernel level, monitoring system calls, network connections, and file access patterns with minimal performance impact.
The distinguishing factor is integration with existing Optimal modules. When the agent detects anomalous behavior — unexpected network connections, privilege escalation, or unusual binary execution — it correlates findings with vulnerability data in your workspace.
Key capabilities:
SBOM management advances with interactive dependency graph visualizations. The new view renders your software supply chain as a navigable, zoomable tree structure. Direct dependencies appear at the top level, with transitive dependencies expanding beneath them. Nodes are color-coded by risk: green for components without known vulnerabilities, amber for medium-severity issues, and red for critical or high-severity CVEs.
Key capabilities:
STIG compliance automation receives substantial enhancements reducing time and effort for ATO assessments and DISA benchmark remediation.
Benchmarking speed improved by 3x through parallelized assessments and optimized evaluation logic. Systems that previously required 45 minutes for assessment across 50 targets now complete in under 15 minutes.
Auto-remediation scripts now address over 200 common STIG findings across Windows and Linux.
Key capabilities:
As LLM and generative AI adoption accelerates, Optimal’s AI security module addresses emerging threats. The NVIDIA Garak integration has been significantly enhanced, with results automatically mapped to the OWASP AI Security Verification Standard (AISVS) framework.
Key capabilities:
The Optimal CLI has been rewritten in Rust for faster startup and execution. GitHub users benefit from an official GitHub Actions integration running Optimal scans in pull request workflows.
Key capabilities:
Q2 2026 priorities include: