Conventional software processes no longer make sense in an age where technology changes overnight and sensors and software systems either keep pace or fail. But trying to adapt modern commercial software practices to legacy applications and contracting is no easy task.
“We’ve got rules and regulations, and you have got to check all these boxes,” said Airman-turned-bureaucracy hacker Bryon Kroger, Founder and CEO of Rise8, a software development house specializing in mission-critical software applications.
As an Air Force intelligence officer operating in combat zones, Kroger observed the tragic results of the failure to fix known software flaws. Later, as an acquisition officer and pioneer with the Air Force’s Kessel Run software factory, he helped deliver the kind of rapid software updates he wished he’d had in combat.
Now he’s dedicating himself to ensuring future warfighters get the updates they need at the speed of relevance.
“Our ability to conduct future warfare will be about how quickly we can respond to the enemy with new software,” Kroger said. “Not just offensive and defensive cyber, but new software capabilities to run the war.”
The idea of rapid software updates can be scary for those who grew up in a conventional development environment, where it takes years to gather requirements, code to those requirements, and then test the finished product before an Authority to Operate (ATO) is granted.
But speed does not have to mean eliminating all those safeguards. “The military lives in a world where we say: ‘Well, we want to make sure that what you’re delivering works,’” Kroger said.
That’s still necessary. But there are ways to ensure software is secure and reliable without having to wait a year or more for an ATO.
It was at Kessel Run that Kroger first pursued the concept of a continuous ATO (cATO). It’s a secure and reliable means for ensuring that software updates can be pushed into production quickly, relying on software “containers” to narrow the scope of what needs to be tested and proven before software goes live. Automation ensures that code is tested and complies with all requirements.
In a peer conflict, Kroger said, “we’re going to find out very quickly that our software is not up to the task.” That’s to be expected. The challenge is how fast can fixes be put into action.
Speed, Stability, and Security Are Interlinked
In conventional software development, requirements are compiled and lumped together such that an update may take years to complete. Pushing some of those components into production sooner entails risk.
“Commanders do have a lot of leeway to accept risk, but not very many people want to get crosswise with the law and find themselves on the floor of Congress explaining why there was a major cybersecurity breach,” Kroger said.
But in a modern, agile software development context, developers work more closely with operators and break down the requirements into more digestible pieces that can be completed in a matter of hours, days, weeks, or months instead of years. These “sprints” define the pace of development.
Called DevOps or DevSecOps, this more rapid process can accelerate capability to the warfighter—but only if the software, once developed, can be cleared for use in production. That requires an initial ATO.
The continuous ATO (cATO) eliminates the delays that come with leaving testing and certification to the end. By doing those things in parallel time is saved and mission effectiveness improved, Kroger said.
Case in point: “In Ukraine, where Starlink was getting jammed, they deployed a software update to the Starlink system and stopped the jamming immediately,” Kroger said.
To deliver results like that, DOD needs to modernize its authorization processes.
In May, the Pentagon published evaluation criteria for obtaining a cATO. “DOD must respond quickly to rapidly changing threats through the continuous integration and
delivery of capabilities, cybersecurity, resiliency, and survivability,” the document states. “To allow software delivery organizations to deploy more secure software faster, the Department will implement a new approach to system authorizations: Continuous Authorization to Operate (cATO).”
Those “organizations that want to move faster and are willing to adopt the necessary culture change… [must make the shift from] a document-based, point-in-time
technical security assessment approach … to a continuous risk determination and authorization concept by continuously assessing, monitoring, and managing risk.”
What’s more, the document concludes, “cATO raises the security standard over a traditional Authorization to Operate (ATO) and provides the ability to deploy software more rapidly to the field while improving security.”
Accelerating Software While Avoiding Risk
Suppose for example a defense agency wants a web-based application deployed in the cloud. Before starting, “you should have the cloud in place, the platform that the app’s going to run on, and the path to get there,” Kroger said.
The path to production depends on a level of trust. Ideally, “the authorizing officials should all trust each other,” Kroger said. Achieving that level of trust requires “government and industry coming together to establish enterprise-level paths to production that are relatively consistent across the services and maybe even the agencies.”
Such a clear production pipeline won’t solve every authorization-related problem, Kroger admits. “But it will solve probably 80 percent of the use cases.”
Once the bulk of cases are covered, the remainder can be dealt with more effectively. One ATO—or cATO—at a time.