DOD looks to scale DevSecOps, container use across department

The Department of Defense has issued a reference design architecture for DevSecOps in hopes of scaling the agile, open-source software development framework across the military.

The department made the lengthy description public earlier this month as a formal blueprint for how software teams across the department should adopt DevSecOps for “developing new capabilities and to sustaining existing capabilities in both business and weapons systems software, including business transactions, [command and control], embedded systems, big data, and Artificial Intelligence.” DevSecOps is a tech industry term for the front-end and continuous integration of development, security and operations teams in the building of software.

“The main purpose of this document is to provide a logical description of the key design components and processes to provide a repeatable reference design that can be used to instantiate a DoD DevSecOps software factory,” the reference architecture reads.

DOD further explains that its interest in DevSecOps is “to improve customer outcomes and mission value by automating, monitoring, and applying security at all phases of the software lifecycle: plan, develop, build, test, release, deliver, deploy, operate, and monitor. Practicing DevSecOps provides demonstrable quality and security improvements over the traditional software lifecycle.”

Within days, there will be a memo issued by the DOD CIO and the department’s head of acquisition announcing the reference architecture and guiding the department on how to use it, said Nicolas Chaillan, a co-lead on DOD’s Enterprise DevSecOps Initiative and the Air Force‘s chief software officer. The DOD initiative is based on the successful work the Air Force has done with its DevSecOps software factories, beginning with Kessel Run.

The goal, Chaillan said Friday at the DEF Conference, is to “make sure we’re not getting locked into any cloud provider, any platform” and give software teams authorized, vetted open source tools to serve as the foundation for any of their needs. As such, it will be much easier and quicker — weeks rather than double-digit months — to obtain a “continuous” authority to operate (ATO) for software by using those common elements instead of having to go through the entire FedRAMP process.

The entire framework, Chaillan said, is built around containers — an open source software development concept that securely packages software and all of its dependencies for use across multiple computing environments. There are already dozens of containers in DOD’s central repository ready for use, Chaillan said. With that, DOD is using Kubernetes, an automated container orchestration system, to bring everything together.

“Everything we do is open source,” he said. “The entire code and the entire infrastructure as code is open to the public.”

The open source containers and Kubernetes orchestration are templates for development, sort of the metaphorical part of the iceberg you can’t see below the water. But on top of that — the tiny tip sticking out of the ocean — “you can, of course, pick whatever product you want to use,” Chaillan said.

So what does this mean to program officials within the DOD?

“We are bringing cloud at scale,” Chaillan said. “You can instantiate a DevSecOps stack in a week with an ATO. That’s pretty game-changing… Of course, you’ll be able to get rapid prtotyping going and continuous feedback. And then you’ll see…baked-in security, fixing containers in days if not minutes and be able to push it across DOD. So instead of having to do patching and vulnerability management of all these tools, your entire [continuous integration/continuous delivery] stack is automated and using our containers.”