DoD CIO Considers Update to DevSecOps Guidance
The U.S. Defense Department’s Chief Information Office is reconsidering guidance issued about a year ago for required and preferred activities that should be involved in the development of secure software, known as DevSecOps, according to Rob Vietmeyer, chief software officer for the deputy chief information officer for information enterprise.
Vietmeyer made the comments while serving on a panel at AFCEA’s TechNet Indo-Pacific conference in Honolulu, November 7-9.
“We published more than a year ago some DevSecOps guidance where we identified a set of required and preferred activities for what should be incorporated in the DevSecOps pipeline. We're now re-looking at that given the some of these attacks and trying to update our guidance to help people navigate through some of these mechanisms because it is a complex environment right now.”
During the panel discussion entitled, “The Evolving Cloud Native Threat Landscape: From Software Supply Chain to Run Time Protection,” the panelists described a wide range of sophisticated attacks that can affect software development pipelines, including pipeline poisoning, typosquatting and backdoors.
“We're also seeing beyond those that are sort of very specific, just standard RMF [risk management framework] control weaknesses wrapped around identity management and access control …,” Vietmeyer noted, adding that without protective actions being implemented, “attackers are going to get in.”
“We're looking at attackers that are getting access to open source projects that are then making malicious contributions that get inherited into downstream processes,” he said.
That led to a discussion of the inability of the RMF to keep up with rapidly advancing threats. Aaron Weis, managing director, Google public sector, joked that he got post-traumatic stress disorder at the mention of RMF. “RMF is proof positive of why this kind of mindset shift, in terms of left of boom, intercepting these bad code injections into a pipeline are so critical. And it's never going to be addressed through RMF, right? There's no amount of spreadsheets and checklists that are going to overtake the dynamic nature of the problem that we're trying to solve for,” Weiss asserted.
We're looking at attackers that are getting access to open source projects that are then making malicious contributions that get inherited into downstream processes.
Youssef Takhssaiti, director, Aqua Security, agreed the RMF controls cannot keep up but said it is not the fault of those working on RMF. “The technology itself is moving much, much faster than those RMF controls. And those, those lovely folks over there, I mean, they're doing a great job, but they're not updating guidance and controls fast enough, unfortunately.”
He added that DevSecOps—which builds in security from the beginning of software development—may be hard for coders to adopt. “Old fashioned coders and programmers, they've gotten used to traditional sense of DevOps. Getting them to move to a DevSecOps model to ensure that as in-cloud native applications, there are several stages where the application could be exploited, and that gets pushed down the stream. Just moving from a traditional DevOps model to a DevSecOps model, I think will definitely improve those areas and ensure better outcomes,” Takhssaiti said.