The concepts of software security and supply chain security have become intertwined and something of an overnight sensation on Capitol Hill, thanks mainly to the SolarWinds breach and its continuing fallout. That intrusion, which had repercussions across the technology industry and federal government, brought to the public’s attention something that people in the software and security fields have known for a long time: Most buyers have no idea what goes into the software they’re using.
For the most part, software products, especially enterprise-grade applications, are black boxes, and intentionally so. Much of the inherent value of commercial software is the proprietary code that each application is based on, and most vendors guard that code fiercely and share the details with few outsiders. As a result, even the most sophisticated buyers have no real visibility into what exactly is in the code that’s running their networks. Part of the Biden administration’s response to the SolarWinds intrusion and other recent major attacks is the executive order that the president signed two weeks ago, an order that includes a wide range of new initiatives for federal agencies to address the issue of software supply chain risk. One of the requirements in the order is that the National Institute of Standards and Technology (NIST) issue guidelines for “identifying practices that enhance the security of the software supply chain.”
Among the components of the NIST guidance, which is set to be released in July, is the requirement that every vendor selling apps to federal agencies provide a software bill of materials (SBOM) for each app. SBOMs are meant to give prospective buyers a clear picture of the components that are in a given application, and because many commercial apps use third-party libraries and open source components, they can provide a view of the potential attack surface of the software, too. During a hearing of the House Committee on Science, Space and Technology’s Subcommittee on Investigations and Oversight and Research and Technology Tuesday, lawmakers touted the inclusion of SBOMs as a major key to improving the security of the software supply chain, but security experts worry about the details of how the guidance will be implemented.
“The SBOM requirement has yet to be defined and adopted even in some of the largest organizations, and like rolling out Multifactor Authentication (MFA) across the federal government and its suppliers, it will be a huge, industry-wide undertaking. Unlike the ambitious timelines for MFA adoption, SBOM does not have a well-understood model for the people, process, and technology needed for a successful rollout,” Katie Moussouris, CEO and founder of Luta Security, said in her written testimony for the hearing.
There existing tools and templates for producing SBOMs and major software vendors generally understand how to do so, but seeing a list of what code components and libraries are in a piece of software does not tell the whole story. It doesn’t explain, for example, how a given library is used or whether the known vulnerable part of an open source component in the application is ever accessed. The risk profile can change considerably in those cases.
“That’s the one thing we need to work out is how vendors can put statements in SBOMs to say we know this is vulnerable but we don't use it."
“A vulnerable library doesn’t automatically make the software vulnerable, because people don't use every function or library in an application. You have naive consumers asking if you’re using the vulnerable version, and if so when you’re going to patch it,” said Chris Wysopal, CTO and co-founder of Veracode, a security firm that performs automated testing for applications.
“That’s the one thing we need to work out is how vendors can put statements in SBOMs to say we know this is vulnerable but we don't use it. This is why vendors don’t want to give customers a lot of information. The information may not be at the precision level that rules something in or out as vulnerable.”
Moussouris agreed, saying that even if vulnerable code is present in a piece of software, that doesn't mean it’s reachable or even exploitable by an attacker.
“An ingredient list of software alone is not useful to determine risk quickly without additional analysis. Neither is the addition of vulnerability data, which would at a minimum include what known vulnerabilities affected each software ingredient. This is because from a technical standpoint, a bug in a software ingredient may not be exploitable in all products that contain that software ingredient,” she said.
“Exploitability would be determined in what code paths are taken via the product, and what other countermeasures may be in place in the overall product that obviate or mitigate the underlying software supply chain vulnerability.”
The appetite in Washington for change and improvement in software supply chain security is real and growing, and Biden’s executive order is just the start of what will likely be a years-long effort. How quickly those improvements start to take effect will be a function not just of the technical or process changes, but also of the amount of money and personnel applied to the problem.
“The NIST framework is a good starting point but we obviously have a long way to go and a lot of work to do. We cannot continue to allow foreign adversaries and criminals, often working together, to take advantage of weaknesses in our software supply chains,” said Rep. Haley Stevens (D-Mich.).