This post first appeared on Federal News Network. Read the original article.
The rise of DevSecOps across the government over the last few years has shown agencies why they have to think differently about how they secure their supply chains.
It’s clear, especially over the last two plus years, managing and mitigating risks to your supply chain is a national security issue.
What agencies need are the proper controls to manage and secure their DevSecOps processes, especially as they use more open source software.
Having this discipline will open the door a bit wider to innovation as well.
Vice President, Product Innovation, Sonatype
The move toward open source isn’t new. If you remember, in 2016, OMB issued the federal source code policy that created a standard to support open source software. Agencies were on the hook for using open source software for at least 20 percent of all new custom develop code.
But despite decades of use — the Defense Department’s first open source policy came out in the late 1990s — agencies still have some concerns about open source software and, some have trouble moving away from the desire to build and control their own software.
DoD’s most recent memo came last January where it outlined two concerns about open source and how the services and defense agencies should mitigate them. First, DoD says open source software requires a supply chain risk management (SCRM) approach, which must meet the same rigorous standards around testing as any other product.
Second, DoD says, the services and agencies must manage the risk of potential innovation disclosure by using a modular, open-systems approach (MOSA), which let systems benefit from open source software while protecting critical, innovative components as separate modules.
Vice President, Product Innovation, Sonatype
Angel Phaneuf, the chief information security officer at the Army Software Factory, said creating a successful software development process involves several different pieces that must come together as one.
“The first factor is to ensure that we don’t already have a tool that already fits your need or use case because digital sprawl is a problem and it can get out of control really quick,” Phaneuf said during the discussion Secure development of federal software supply chains. “Another factor is understanding the licensing model and the ability to scale even though some software is only requested by a single team or a single person, we have to make sure that we take into account the possibility that the entire organization is going to adopt this. We’ve gone through several cycles of determining what is the right way to do it as someone comes in and uses a new tool.”
A third important factor, she said, is documentation. This includes everything from feedback from developers, engineers and security experts to a ratings system to ensure the product meets the controls and rigors the Army demands.
The Navy’s Black Pearl effort, which is more of a DevSecOps tools and assistance provider than a software factory, is less prescriptive about how software is developed and implemented.
Manuel Gauto, the chief engineer of Black Pearl for the Department of the Navy, said security, user experience and overall integration are the leading factors that make up their successful software process.
“What we’re trying to do with Black Pearl is connect not just the high-performing entities within the traditional defense industrial base, but also bring in folks that have novel capability on the commercial side that we can just buy as a self-encapsulated capability, and then build a simpler interface to the rest of the ecosystem that we’re trying to build,” he said. “At the end of the day, the Department of Navy is not in the business of building source code scanners or artifact scanners. We build capabilities that are warfighting capabilities that go on a submarine or warship so we’re constantly trying to allocate our resources as intelligently as possible.”
This means for the Army, the Navy and even for the State Department using open source code to help accelerate certain capabilities.
Landon Van Dyke, the senior technology advisor for the State Department, said there are specific security and oversight tools needed to make sure open source software is as safe as possible.
“At the enterprise level when we’re looking at evaluating a company or a product, we’re actually evaluating the company themselves. We do start with the procurement process. We look to see what their financial health looks like what they’re doing in the market, who their partners are. Obviously if it’s overseas that matters especially for the State Department,” Van Dyke said. “One of the things that we’re really looking at for software is the source code. We’re looking at things like injection, authentication and session management. That does require a little bit of sophistication in the evaluation by artificial intelligence tools. “
Vice President, Product Innovation, Sonatype
Dr. Stephen Magill, the vice president of product innovation at Sonatype, said as agencies move more toward the DevSecOps model, they must understand there are two kind of vulnerabilities—the mistakes made in code development and the intentional vulnerabilities like zero days such as Log4j.
“Having a good inventory is important because knowing what you’re using can be remarkably difficult. And when you’re operating at the level of scale that the government does and that larger companies do, then for the new style of attacks, things like malicious codes, that’s the most challenging but it’s also where the innovation is happening in the industry right now,” Magill said. “There are products out there, like we have a product called Firewall, which sits at the boundary of your network and will quarantine things that you pull in if we’ve detected malicious commits. Basically, it’s like a different type of monitoring.”
He said agencies need to rely on vulnerability reports and constantly assess the trustworthiness of their development teams, processes and contributors.