DOD Plans Quicker, More Comprehensive Cybersecurity Standards for Contractors 

Defense IT contractors who can demonstrate an assured supply chain and secure coding practices will soon be able to get fast track approval to have their products operate on DOD networks, radically shortening a process that often takes months or years at present, Pentagon Chief Software Officer Rob Vietmeyer said April 10. 

The Defense Department will tell contractors, “if you want the fast path to get past these long [approval] cycles, if you want to demonstrate that your product is trustworthy and secure enough for these defense missions … demonstrate through independent testing that your products meet these types of controls, and we’ll get you on the fast test list,” he told an audience of industry executives at AFCEA Northern Virginia chapter’s Innovation IT day event in Herndon. 

He said the so-called “Swift Process” will build on the work done over nearly 15 years to build required system security standards into DOD contracts under the 7012 provision of the Defense Federal Acquisition Regulation Supplement, and then to require contractors to certify compliance with those standards under the Cybersecurity Maturity Model Certification program, which will come into full force later this year. 

But the Swift Process will be implemented much, much faster, he promised. 

“7012 was a seven-year process,” he pointed out, “Another seven years to get CMMC through the regulatory approval process, we can’t operate at those speeds anymore, right?” 

Despite being implemented more quickly, the Swift Process will also be more comprehensive than CMMC, he said, covering supply chain security and issues of foreign control or influence on the contractor and their suppliers, as well as incorporating the secure coding pipeline defined by the Cybersecurity and Infrastructure Security Agency (CISA). And it would apply, not to whole organizations, as CMMC does, but to specific products. 

“So what we’re looking at is defining a set of controls, and if industry [partners] can demonstrate that their products and their pipelines meet those controls, that removes from us the burden from going through months and months of Risk Management Framework assessments. It can get us to understanding, yes, this software meets our risk posture. … Because we built that trust with industry that if we install this software, it will not bring unacceptable risk into our environment,” he said. 

Speaking to Air & Space Forces Magazine after his address, he said the new process is “a high priority for the current administration,” and the launch is “imminent.” 

“We are working on some of the details right now internally,” he explained. “What we’re going to announce is the objectives for this effort, and a kind of high level framework, and then rapidly—so I think a few months, not years—engage with industry about it.” 

He said the engagement will begin by collecting feedback via Requests for Information. They will ask industry “What are the sets of controls we should establish for software products? For foreign influence and control? For software pipelines? The aim is to work with industry so that they can demonstrate that their products are trustworthy, and then we can, based on that trust, give them the fast pass into the defense [IT] environment.” 

He said the Swift Process is driven by two concerns. First is the need to get cutting edge capabilities into the hands of U.S. warfighters, and the second is the need to extend the Pentagon’s security perimeter into the contractors who make up the defense industrial base and beyond them, into their supply chains. 

“We know adversaries are going after the software supply chain with increasing frequency, right? Sophisticated attacks. We’ve got to get much smarter as a community on what it means to secure software.” That includes tracking and vetting components in including open-source software packages that might be riddled with vulnerabilities, or susceptible to being back-doored by foreign cyber-spies posing as open-source coding volunteers. 

Even contractors’ own code isn’t safe, he said. “Attackers are actually going after the [software development] pipeline,” as they did in the Solar Winds attack. “So we’re looking at everything from memory safe programming languages to how you’re securing your developer identities [and] your repositories,” he said.