At the recent Carahsoft DevSecOps Conference Dave Raley, Chief Digital Services Officer at Operation StormBreaker , challenged a familiar assumption in federal technology that moving faster necessarily means accepting greater security risk. In his view, agencies are asking the wrong questions about the relationship between speed and security. With threats evolving continuously and mission requirements changing just as quickly, the greater risk may be relying on point-in-time compliance processes that can take months or years to complete. The path forward, Raley argues, is to make security continuous, embedded it into software development and threat compliance as a means to achieving the mission, not the mission itself.
Compliance is Not the Mission
One of the most persistent misconceptions surrounding the Authority to Operate (ATO) process is that completing the authorization process is the security outcome. Raley believes agencies need to make a sharper distinction between compliance and mission success. “The goal should be the mission outcome, [delivered] securely and in compliance,” he said.
A comprehensive authorization package can demonstrate that an organization completed a particular process, but it does not necessarily demonstrate the current security posture of that software. When an assessment takes months to complete, the environment may already have changed by the time the authorization is approved. New vulnerabilities can emerge, dependencies can change, and adversaries can develop new attack techniques while documentation remains frozen in time.
“Just because your package looks good doesn’t mean your system is secure,” Raley said. “Before the ink is dry, your package is already outdated.” That distinction is reflected in new federal policy and guidance. 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. Its Software Modernization Strategy likewise emphasizes DevSecOps and delivering software capabilities at the “speed of relevance.”
Continuous Authorization Can Strengthen Security
The promise of DevSecOps is often framed around speed, but Raley sees an equally important security benefit. Embedding security controls throughout the development pipeline allows teams to identify vulnerabilities earlier and respond continuously, rather than discovering problems at the end of a lengthy development cycle.
Modern development environments can incorporate code analysis, software composition analysis, secret scanning, container security, and software bills of materials into the development process. Each build can generate additional evidence about the software’s security posture, giving developers, security teams, and authorizing officials a more current picture of risk. This shifts the focus from documenting that security happened to continuously demonstrating the security posture of the system.
That makes the traditional question of how agencies can move faster without increasing risk, the wrong one. “How can you afford not to do this because of all the risks you already have?” Raley asked. When security is integrated into the development process, faster delivery and stronger security can become complementary rather than competing objectives.
The Real Risk May Be Cycle Time
For Department of War (DoW) organizations, slow software delivery is more than an efficiency problem. Threats change dramatically between the time a requirement is written, and the time a capability reaches an operational environment, making the ability to respond quickly an important component of mission readiness. “How quickly can we recognize a need and put it into production, or recognize a change from the adversary, iterate, and re-release?” Raley asked. “Fifteen minutes is probably getting close to good enough from a speed perspective, but four years and five years is not.”
That imperative is played out across the DoW. In a recent Federal News Network interview, former Army CIO Leo Garciga discussed the Army’s progress with cATO, including a pipeline that expanded from supporting two simultaneous development efforts to 23 while reducing delivery time from roughly 30-45 days to about a week. Garciga described the goal as improving “the ability to deliver capabilities that really matter.”
Achieving that kind of cycle time requires more than implementing containers or CI/CD pipelines. Agencies also must reconsider how they define requirements and manage development. Rayle argues that organizations cannot take waterfall processes, divide them into sprints, and call the result Agile. When teams are expected to define every feature years in advance, they lose the ability to learn from the people actually using the capability. “The design team didn’t know exactly what the user needed,” Raley said. “They never do.”
From Requirements to Results
Operation StormBreaker, the software factory capability Raley established, provides a practical example of this approach. One effort involved developing digital capabilities to support the Presidential Fitness Test, beginning with a mission need rather than a lengthy set of predetermined software requirements.
According to Raley, the team moved from the initial need to a working proof of concept, and then into operational testing within weeks. The significance is not simply the timeline; it is the iterative model behind it. The team built an initial capability, put it in front of users, learned from the results, and continued refining the system based on real-world feedback. That approach allows mission value to be delivered along the way rather than requiring users to wait until a large, fully specified program is complete. As Raley described it, the goal is to “iteratively build, release, and produce mission value.”
The example illustrates why continuous authorization and agile development are interconnected. If security and compliance are built into the development environment, teams can iterate without treating every change as a reason to restart a lengthy authorization process. Instead, each iteration can produce new evidence about the system and its risk posture.
Rethinking the ATO for the Speed of Need
DoW software factories and continuous authorization environments have moved beyond being technology demonstration environments; they are now mission-critical infrastructure that enables agencies to develop, secure, and deploy capabilities at the speed of need.
To continue to foster a DevSecOps culture will require leaders to challenge the processes surrounding ATO and distinguish between what policy actually requires and what organizational habit has added over time. It may also require greater use of external partners that can provide mature platforms, security expertise, and automation without forcing every mission organization to build the same capabilities from scratch.
For organizations beginning their own journey, Raley’s advice is straightforward: “Don’t settle the status quo.” Leaders should examine where security can be automated, where evidence can be collected continuously, and where legacy processes may be adding time without meaningfully reducing risk.
The federal government does not need to choose between security and speed. It needs to build environments in which the two reinforce one another. When security is embedded into development, risk is continuously evaluated and mission owners can iterate based on real-world feedback; faster delivery can mean better-informed risk, stronger security, and faster mission outcomes. The policy direction is increasingly clear. The next step is making this model the normal way government delivers software.