Enable breadcrumbs token at /includes/pageheader.html.twig

DOD Culture Still Impedes Rapid Development

The department continues to refine DevSecOps.

The U.S. Defense Department is in the process of implementing its software modernization strategy, which starts with the goal of delivering new capability directly into the hands of the warfighter and addresses both the technical and nontechnical obstacles to that vision. Still, the department faces challenges in rapidly developing and fielding technologies, according to Danielle Metz, the department’s acting deputy chief information officer for information enterprise.

Those challenges are both cultural and institutional. “The first is how we look at hardware and software, and the second is the rapid delivery of small amounts of capability into production," Metz said during the final keynote presentation of the December 1-3 AFCEA TechNet Cyber virtual conference. 

Separating the software from the underlying hardware is common practice in the commercial world where cellphones, TVs and even automobiles can receive software updates over the air, she noted. “Within DOD, where we buy things as integrated systems, this concept is relatively new. We need the ability to look at our weapons platforms and treat them not as fixed, integrated hardware and software units. Instead, we need the hardware to be the platform we can continuously push new capability to, allowing us to be really agile in response to the future threat.” 

The second cultural challenge, Metz indicated, is “tightly coupled to the first.” It is the “rapid delivery of small amounts of capability to production.” It is another common practice commercially, where a rapid and agile software development process known as Development Security Operations, or DevSecOps, is the norm. 

While the Defense Department has attempted to adopt DevSecOps practices, it has not yet caught up to industry. “When DOD teams try to adopt modern software development practices into their normal business processes, they run into other institutional and cultural roadblocks. An uncomfortable reality is that nearly all of the processes within the Department of Defense push back on the idea of the rapid delivery of small amounts of capability into production,” Metz asserted.

That’s because the department’s processes are more tailored toward the procurement of large weapon systems than rapidly changing software capabilities. “These processes have been refined throughout the decades of building big hardware-intensive platforms. Obviously, not everything is an aircraft carrier or a bomber or a satellite constellation, but those things are such a big part of the business of DOD that the language and expectations for building large weapon systems intrude into all kinds of development efforts,” Metz explained. “We find this in the way we budget two years ahead of time, the way we build requirements, the way we structure acquisitions, the way we measure programs, the way we test and accredit. All of these processes need to be transformed to deliver more agility.”

Implementing DevSecOps efficiently is one of the challenges. “What we see is programs building DevSecOps infrastructure. They’re not actually pushing code to production because they’re all doing the meta work of building and maintaining software factories,” she said. “Today, we have several DevSecOps platforms operational across DOD. The challenge now is to determine the right number for the department,” Metz pointed out. 

Those redundancies introduce inefficiencies. “Standing up and operating a DevSecOps platform is complex and expensive. We need to find the balance of having enough without having too many. The focus is not on the DevSecOps platform but the mission applications that are built quickly and securely using the platforms. This is precisely what is delivering speed of capability to the warfighters.”

Those software factory redundancies can be an issue within the industrial supply base as well. Metz explained that a major program with one prime contractor and multiple subcontractors may have several of those contractors building their own, independent software pipelines. “We’ve worked together with the office of acquisition and sustainment on this issue to include language and policy for software acquisitions, encouraging the use of enterprise service when companies are bidding DOD software work,” she reported. “The DOD CIO will identify the first of several mature software factories to be designated as enterprise service. This doesn’t mean programs are mandated to use one platform, but it does encourage bidders to use available services first before building new ones.”

She added that, “It also allows acquisition programs to use this as an evaluation criteria when considering bidders.” 

It also can be a challenge to convince security teams to implement DevSecOps. “We should have our security teams begging development teams to move to DevSecOps for all the increased visibility it will provide them, yet they often feel that DevSecOps or cloud or zero trust is something that’s happening to them, that it is a way for developers to ask them to accept additional risk in order to go fast,” Metz stated. “The compliance-based approach to risk management is in the DNA of the department, and we must reach, collaborate and educate the thousands of rank and file control assessors that DevSecOps teams encounter.”

The DOD CIO office is attempting to improve the situation. “We have written a continuous authorization guidance to address this gap, and once the guidance is approved, the next step will be to develop and deliver the training to help the risk assessment community understand how to assess and authorize DevSecOps platforms and software,” she said.