Webinar Description
Key Takeaways
- Case study examining how Operation Stormbreaker reduced DoD software deployment cycles from 18 months to 15 minutes using the Navy’s RAISE 2.0 framework
- Technical exploration of Continuous Authority to Operate (cATO) implementation within DevSecOps architectures
- Practical guidance on Zero Trust security, automated container hardening, and Software Bill of Materials generation
- Designed for federal program managers, DoD cybersecurity professionals, DevSecOps engineers, and defence contractors
- Addresses compliance automation challenges under DISA Container Hardening Process Guide requirements
Introduction
The U.S. Department of Defense faces a persistent tension between security compliance and operational agility. Traditional Authority to Operate processes, designed to ensure software meets rigorous security standards before deployment, have historically required months or even years to complete. For military operations requiring rapid capability deployment, this timeline creates significant operational risk. A case study presentation featuring the U.S. Marine Corps’ Operation Stormbreaker examines how one programme collapsed an 18-month deployment cycle to just 15 minutes while maintaining full compliance with federal security mandates.
This event brings together technical and operational experts from Stormbreaker, Raven Solutions, and Anchore to detail the architectural decisions and implementation strategies that enabled this transformation. The discussion centres on achieving Continuous Authority to Operate through the Navy’s RAISE 2.0 framework, offering defence organisations a replicable approach to secure, rapid software delivery.
About This Event
Structured as an architectural case study and panel discussion, this event provides a detailed examination of how Operation Stormbreaker operationalised continuous compliance within a DevSecOps environment. Rather than presenting theoretical frameworks, the session focuses on actual implementation decisions, technical configurations, and lessons learned from a live DoD programme.
Speakers from the Stormbreaker programme offer first-hand perspective on the operational requirements that drove architectural choices, while technical experts from Raven Solutions and Anchore explain the underlying platform capabilities and integration patterns. This combination of mission context and technical depth distinguishes the event from more general DevSecOps discussions.
From 18 Months to 15 Minutes: The cATO Transformation
The traditional Authority to Operate process requires comprehensive security assessment before software can be deployed to production environments. For DoD systems, this assessment must satisfy extensive documentation requirements, vulnerability analysis, and risk evaluation. When each application requires individual authorisation, deployment timelines extend dramatically, and any software modification potentially triggers reassessment.
Continuous Authority to Operate represents a fundamental shift in this model. Rather than authorising individual applications, cATO shifts authorisation to the platform layer. When the underlying platform maintains continuous compliance through automated controls, applications deployed on that platform inherit its security posture. This architectural change transforms authorisation from a gate that blocks deployment into a continuous process that runs alongside development.
Operation Stormbreaker’s implementation demonstrates this principle in practice. By leveraging the Navy’s RAISE 2.0 framework, the programme established a platform environment where security controls are continuously validated rather than periodically assessed. The 15-minute deployment cycle reflects not a reduction in security rigour but a redistribution of where and when security validation occurs.
DevSecOps Architecture for Regulated Environments
The technical architecture enabling this transformation integrates several complementary capabilities. At its foundation lies a shift-left philosophy that embeds security validation into the earliest stages of the development pipeline rather than treating it as a final checkpoint before deployment.
Policy-as-Code and CI/CD Integration
Compliance requirements in DoD environments are extensive and precisely defined. Manually verifying adherence to these requirements at deployment time creates bottlenecks and introduces human error. Policy-as-code approaches encode compliance requirements as machine-readable rules that execute automatically within CI/CD pipelines. When a developer commits code, the pipeline automatically validates that the resulting artefacts satisfy defined security policies before they can progress toward production.
This automation serves dual purposes. It accelerates the compliance verification process from days or weeks to minutes, and it creates an auditable record of every compliance check performed. For programmes operating under cATO, this continuous documentation provides the evidence trail that authorising officials require.
Container Hardening and SBOM Generation
Container-based deployment has become standard in modern software delivery, but containers introduce specific security considerations. The DISA Container Hardening Process Guide establishes requirements for securing container images before deployment to DoD systems. Automated container hardening processes apply these requirements consistently across all images, removing unnecessary components, configuring secure defaults, and validating compliance with hardening standards.
Software Bill of Materials generation addresses a related challenge: understanding exactly what components exist within deployed software. An SBOM provides a comprehensive inventory of all libraries, dependencies, and components included in a software package. When vulnerabilities are discovered in common libraries, organisations with accurate SBOMs can immediately identify which systems are affected. For defence environments where software supply chain attacks represent a significant threat vector, this visibility is essential.
Zero Trust and Software Supply Chain Security
The broader context for these technical capabilities is the DoD’s ongoing implementation of Zero Trust architecture. Zero Trust assumes that no user, device, or application should be automatically trusted, regardless of network location. Every access request must be continuously validated against current security policy.
Applied to software delivery, Zero Trust principles require that every component in the software supply chain be verified. Code must be validated at commit time. Dependencies must be scanned for known vulnerabilities. Container images must be signed and verified before deployment. Runtime behaviour must be monitored for anomalies. The DevSecOps architecture presented in this case study implements these principles through automated controls embedded throughout the delivery pipeline.
Software supply chain protection has gained particular urgency following high-profile incidents affecting both government and private sector organisations. Attackers who compromise development tools, build systems, or software repositories can inject malicious code that propagates to all downstream users. For defence systems, such compromises could have severe operational consequences. The architectural patterns discussed in this event address these risks through continuous validation and comprehensive visibility into software composition.
Who Should Attend
This event addresses professionals responsible for delivering or securing software within federal and defence environments. Federal programme managers will gain insight into how cATO implementation affects programme timelines and risk profiles. DoD IT and cybersecurity professionals will understand the technical architecture enabling continuous compliance. DevSecOps engineers and architects will learn specific implementation patterns applicable to their own environments.
Compliance officers will benefit from understanding how automated controls satisfy documentation and audit requirements. Industry partners working with federal agencies will see how these approaches affect their integration requirements and security expectations. Senior technical leaders in defence contracting organisations will gain perspective on where the DoD is heading with software delivery modernisation and what capabilities they should be developing.
The Operational Imperative
The transformation documented in this case study reflects broader pressures facing defence organisations. Adversaries operate at digital speed, exploiting vulnerabilities within hours of discovery. Mission requirements evolve rapidly in response to changing operational conditions. Software capabilities that take 18 months to deploy may be obsolete before they reach the field.
Continuous Authority to Operate addresses this mismatch by enabling defence organisations to deliver software at the pace operations require while maintaining the security posture that mission criticality demands. The Stormbreaker case study demonstrates that this balance is achievable with current technology and frameworks, providing a blueprint that other programmes can adapt to their own requirements.