What Is DevSecOps, Anyway?

When the Government Accountability Office looked at nearly two dozen major weapons programs that attempted to use Agile software development practices, they found slower deployments, reduced system security, and higher costs — nearly the opposite of the benefits that have converted much of the tech world to “Agile.” No doubt the GAO was correct about these programs, and yet our experience with an Air Force cybersecurity project suggests that Agile can lead to almost-startling success in DoD efforts.

In 2019, the U.S. Air Force hired Technica to maintain and upgrade its Cyberspace Vulnerability Assessment/Hunter system, which helps airmen hunt and fix network vulnerabilities. The service aimed to consolidate three related contracts and to shift from the “waterfall” process to an Agile approach. At the heart of the mission was a desire to bridge the divides — both technological and human — that stood between the status quo and improved operability. The path forward resulted in helping USAF build a new operational model — one that spanned the unique needs and perspectives of DevOps and Security and, in doing so, created a DevSecOps culture.

Let’s take a look at what it took to get there.

From the outset, the challenge revolved around what might be called a cultural divide between two teams: DevOps, or software developers and IT engineers; and specialized security engineers. In summary, developers want the tools they develop to be faster, go farther, do more. They focus on features and functionality, and find that security considerations often inhibit the innovation and agility they strive to bring to life. Security teams, for their part, will tell you they value innovation and agility just as much as DevOps, but not at the expense of ignoring protection and compliance. For them, mitigating risk is always Job No. 1. The resulting disconnect — of two equally important assets working at what is sometimes cross purposes — serves no one and can even jeopardize the mission. A transformation was needed.

Step one was building a foundation for a new culture that could foster strong, cooperative relationships and incorporate Agile practices. Central to this transformation was the idea that security is not a retrofit, nor an impediment to innovation and agility. By incorporating security early in the development process, it was possible to expose and remediate weaknesses soon enough that developers can address them without having to sacrifice features and functionality. The trust and rapport achieved from frequent engagement and collaboration between DevOps and Security teams have resulted in cost savings, improved operations, and diminished security threats.

Next, we needed to drill down on the way the USAF has been defining and deploying its team assets. Like most organizations, development work had been divided among functional teams. Under this model, each team completes a task and then passes it to the next. There was little communication between the groups—the problem being that communications, however well intended, can result in confusion and conflict and, thereby, slow delivery, or introduce vulnerability into final products. It’s easy to understand how and why this model came to be. However, with shorter delivery timeframes, waiting until the last minute to ensure an application is safe to deploy disrupts the entire delivery lifecycle. It’s just not a sustainable model of operation. 

A DevSecOps operational model was the answer. By including security policies in the workflow from the beginning, we created a more robust, efficient, and resilient process. Building compliance controls into the release pipeline, coupled with an automated approach to find and resolve bugs, increased deployment efficiency and consistency with a lower risk of security flaws. Vulnerabilities decreased and velocity increased, producing a better, more secure product faster.

By replacing a waterfall culture with a DevSecOps culture, the Air Force’s CVA/H DANS effort combined three independent contracts—feature development, product delivery, and sustaining fielded systems—and merged them into one unified work structure. The program, which had released just two new versions in three years of waterfall operations, released four versions in its first year as a DevSecOps effort.

All in all, this experience reminded us of a simple, but important point: just calling a program Agile doesn’t make it Agile, but when it’s done right, Agile paired with DevSecOps gets the job done in some pretty impressive ways.

Gerry Morelli is director of programs at Technica Corporation.