"Just because your package looks good doesn’t mean your system is secure," Dave Raley told attendees at the Carahsoft DevSecOps Conference, cutting to the heart of how federal technology teams are rethinking the relationship between speed and security.
Dave Raley and Operation StormBreaker
Raley, Chief Digital Services Officer at Operation StormBreaker, argued that the long‑standing assumption — that moving faster requires accepting greater security risk — is backward. He said agencies are asking the wrong questions and should treat compliance as a means to an end rather than the end itself. "The goal should be the mission outcome, [delivered] securely and in compliance," Raley said, adding that paperwork-heavy authorization packages often capture a past process rather than a current security posture: "Before the ink is dry, your package is already outdated."
Department of War cATO guidance and Software Modernization Strategy
Raley’s remarks align with written federal direction cited at the conference. The Department of War’s continuous Authority to Operate (cATO) guidance calls for moving beyond traditional, point‑in‑time authorization toward continuous risk determination, monitoring, and management. The DoW’s Software Modernization Strategy similarly emphasizes DevSecOps and delivering software capabilities at the "speed of relevance." These policy signals frame continuous authorization as an official move away from static, months‑long compliance cycles.
Audit-ready is a season. It shouldn't be.
Evidence in spreadsheets, controls drifting between audits, frameworks multiplying on flat headcount. Nubivance runs continuous compliance on Rapid7 Cyber GRC - SOC 2, HIPAA, ISO 27001, PCI, CMMC.
End the scrambleContinuous authorization inside DevSecOps pipelines
The security benefit of DevSecOps, Raley said, is not only speed but continual evidence of security. Modern development environments can incorporate code analysis, software composition analysis, secret scanning, container security, and software bills of materials into the build process. Each build can generate fresh evidence about security posture, giving developers, security teams, and authorizing officials a current picture of risk rather than a frozen assessment produced at one point in time. That model reframes the question from "How can we move faster without increasing risk?" to Raley’s challenge: "How can you afford not to do this because of all the risks you already have?"
Cycle time: the Army example and operational speed
Slow delivery is more than an efficiency problem, Raley warned — it is a mission risk. Threats and requirements can change dramatically between a written requirement and an operational capability, making rapid iteration a component of readiness. Raley suggested that "fifteen minutes is probably getting close to good enough from a speed perspective, but four years and five years is not." The point is illustrated by a Federal News Network interview cited at the conference in which former Army CIO Leo Garciga described an Army cATO pipeline that expanded from supporting two simultaneous development efforts to 23 and reduced delivery time from roughly 30–45 days to about a week. According to Raley, meeting those kinds of cycle times requires more than containers or CI/CD; it requires rethinking how requirements are defined and how development is managed so teams can learn from users rather than trying to specify every feature years in advance.
Operation StormBreaker's Presidential Fitness Test example
Operation StormBreaker provided a concrete case study. Raley described a project to develop digital capabilities for the Presidential Fitness Test that began from a mission need rather than exhaustive, predetermined requirements. The team moved from need to a working proof of concept and into operational testing within weeks. The value, Raley said, was not simply speed but the iterative learning model: build an initial capability, put it in front of users, learn, and refine. That approach lets teams "iteratively build, release, and produce mission value" instead of waiting for a large, fully specified program to conclude before delivering benefits.
What this means for technologists, authorizing officials, and mission owners
- Technologists and security teams: embed code analysis, software composition analysis, secret scanning, container security, and SBOMs into CI/CD so each build produces evidence about security posture and enables continuous response.
- Authorizing officials and policymakers: follow the cATO guidance’s shift from point‑in‑time authorization to continuous risk determination, monitoring, and management, and separate policy requirements from organizational habits that add time without reducing risk.
- Mission owners and users: favor iterative delivery that begins with a mission need and moves rapidly to proofs of concept and operational testing, allowing real‑world feedback to inform subsequent releases.
Raley’s closing admonition to leaders at the conference was blunt and specific: "Don’t settle the status quo." Federal policy directions — including the DoW’s cATO guidance and Software Modernization Strategy — are now aligned with that view. The remaining task, he said, is operational: embed security into development pipelines so continuous authorization and rapid delivery reinforce one another and make faster releases both safer and more relevant to mission needs.
