Using a Software Bill of Materials to Unveil Vulnerabilities

Having a detailed description of the software components in any software-based product is necessary to identify cyber vulnerabilities and ultimately help reduce cybersecurity risks, officials say. The National Telecommunications and Information Administration, working with industry stakeholders, is pursuing the advent of a so-called software bill of materials to apply to digital products that identifies and lists the pieces of software, information about those components and supply chain relationships between them, the agency specifies.

“The biggest challenge that we’re facing today is that there are very few organizations in the entire world that can quickly and easily answer, ‘Are we affected by this recently discovered software vulnerability?’” says Allan Friedman, director, Cybersecurity Initiatives, Office of Policy Analysis and Development, National Telecommunications and Information Administration (NTIA). “And that lack of transparency means we are not resilient. We can’t prevent all flaws from happening, but once we know about a flaw, it is—how quickly can we understand whether or not we need to act, how to act, and the course towards action? Transparency in the supply chain allows us to have that resiliency for software vulnerabilities.”

The problem is amplified by the complex nature of intermingled source code. Coders commonly pull from various software libraries, reusing lines of existing code. Long gone are the days when developers wrote unique software. “Today, no one makes software themselves,” Friedman stresses. “Software is not hewn out of alabaster marble by a monk in solitude in the Greek islands. Most of us make software from third-party components. And there is a very complex nested supply chain. You can think of it as a tree, and the challenge is how do we know that the software components we are using are up to date or if the vulnerabilities have been addressed.”

In addition to being the president’s advisor on telecommunications and Internet policy issues, the NTIA’s role, as part of the Department of the Commerce, is to safeguard and promote the digital economy. With cybersecurity and transparency not inherently addressed in the software supply chain, the NTIA sees this as a gap in the market, leading the agency to act on defining a software bill of materials platform. “In cybersecurity, we often talk about market failures,” he states. “And this is an area where while software is a big part of the economy for a variety of reasons, the market isn’t working quite as well as we think it should.”

For the past year and a half, the NTIA has worked in conjunction with government and industry stakeholders, through four open working groups—Framing; Use Cases; Formats; and Healthcare—meeting weekly or biweekly to create a framework and draft key documents, information or practices around the use of software bill of materials. According to NTIA, the parties are guided by the goal of “exploring how manufacturers and vendors can communicate useful and actionable information about the third-party and embedded software components that comprise modern software and Internet of Things devices, and how this data can be used by enterprises to foster better security decisions and practices.”

The Framing working group created the Framing Software Component Transparency document, which defines a minimum viable software bill of materials to guide parties that make, select and operate software.

“The value of quickly gathering this minimum set of baseline information for a majority of software components will significantly improve the ability for each industry to better manage the components that they use,” the document states. “Starting with a baseline set of information allows this process to be adopted by a variety of stakeholders quickly and then be built upon over time. This is one of the major drivers for establishing such a basic set of information as a starting point, rather than requiring a more robust set of data elements that may require more time and resources to collect and maintain.”

The Use Case working group published the report, Roles and Benefits for Software Bill of Materials Across the Supply Chain, which examines existing use cases of software bill of materials, identifies how those cases could be improved and produces an understanding of how existing software practices could be enhanced by greater implementation of a software bill of materials. Meanwhile, the Formats working group, which issued the report, Survey of Existing Software Bill of Materials Formats and Standards, is considering how its use can be automated for greater efficiency.

“These documents that we have cover the basics of the what, why and how of SBOM [software bill of materials] and we’ve got a demonstration that SBOM is not just feasible but beneficial as well,” Friedman continues. That feasibility demonstration started successfully in the healthcare industry, through the Healthcare working group, which published the Healthcare Proof of Concept Report, Friedman explains.

“The healthcare industry was very far behind from a cybersecurity perspective, and there was a lot of money being poured into digital health but relatively little attention being paid to security at the time, especially in the supply chain,” Friedman notes. “All of the attention was focused on HIPAA regulation and things like that.

The U.S. Food and Drug Administration, or FDA, which is responsible for regulating the use of medical devices, was also interested in a software bill of materials. “They told industry that they were probably going to require its use at some point in the future, but intentionally did not declare exactly what that looked like,” Friedman explains. “Instead, they pointed the medical device community towards the NTIA. We’ve worked with the FDA in the past, and they viewed us as a trusted convener that could bring the industry together. They have the regulatory teeth, but it also means that they’re limited in the type of partnerships they can have with industry.”

As part of the demonstration effort, medical device manufacturers—such as Siemens, Phillips, Abbott, and Medtronic—organized together with some of the major hospitals in America, including the Mayo Clinic, Cedars-Sinai and New York Presbyterian, and tested out the software bill of materials concept. They were able to show it was possible to generate software bill of materials data and that the data could be used by the hospitals against predefined use cases around their security and operations management. “Everyone was able to show, that ‘we can do this,’” Friedman reports.

Building on that demonstration success, NTIA is working with the medical parties on how to automate the use of a software bill of materials. The agency also is meeting with senior officials in the Defense Department and intelligence community (IC) to examine how a software bill of materials could be applied in those sectors. “There is a lot of interest from DOD and the IC in SBOM,” he offers.

Friedman suggests that the government, the military or any other entity purchasing software or software services demand to know what is a part of the digital code, and they ask for a software bill of materials from their suppliers. “Software powers our entire world, everything and everyone is involved in the software world,” he notes. “If you make cars, well that’s a software product. You make tanks; it’s a software product. And now it is about pushing a market demand for good quality software components upstream. So that the organization, whether it’s government or private sector, can ask its software suppliers, ‘Hey, are you using the freshest ingredients or are you using toxic ingredients?’ That’s really what we’re trying to do is drive the demand for better, higher-quality software ingredients in the supply chain.”

The director also advises software companies to have a clear understanding of the software they produce. “If you make software, do you know what you ship?” he asks. “In 2020, every organization that makes software should have a fairly real-time awareness of what components they’re shipping, what version those components are, so that when there is a risk discovered, they can react quickly and readily. And if your organization uses software, can you ask that question of your supplier? ‘Hey, what’s under the hood? We don’t need to know the recipe, but we need to know the ingredient list.’ If you make software, or if you buy software, get ready. This is going to be coming. And if anyone wants to get involved, this is their chance to weigh-in and actually shape this small but critical part of the future of software supply chain security.”