SBOMs are billed as a balm for supply chain risks. What’s the holdup?
Illustration: Si Weon Kim
The fallout of the Log4Shell vulnerability accelerated efforts to require a software bill of materials (SBOM) for the apps, libraries and other digital tools we rely on, but when it comes to generating and using this information, obstacles abound.
The average program is a black box, even for its own developers. Almost all (97%) applications use open-source code, with the average codebase consisting of 78% open-source software. They rely on dozens of dependencies — hundreds, for popular JavaScript frameworks — and import third-party commercial libraries with little transparency.
Yet most companies have little idea what ingredients make up their software. After the surprise disclosure of a critical vulnerability in the Log4J 2.0 Java library in December 2021, for example, companies scrambled to determine if their software included the open-source component and, if so, whether importing the code had put their own applications at risk. The vulnerable library was usually not included directly by developers but as a lower-level dependency — five levels down on average, according to a Google analysis.
If an enterprise knows even 70% of the software ingredients included in its applications, they are “best of breed,” SANS Institute director of emerging cybersecurity trends John Pescatore told README.
“The biggest thing missing is a bill of materials to tell us, at the very highest level, what software is being used,” he said. “From a security perspective, we really want to know, are there are any vulnerabilities in any of those ingredients, because components are updated constantly.”
Software bill of materials (SBOMs) have become increasingly popular. The concept has gradually taken form over the past decade with the National Telecommunications and Information Administration (NTIA) bringing together private industry and government agencies to define the basic components of an SBOM and collect specific implementations. When the Biden administration announced its Executive Order for Improving the Nation’s Cybersecurity in May, a key component was requiring all software purchased by the federal government to meet certain security standards, including providing an SBOM.
Yet, while many aspects of SBOMs are being hammered out by industry and government experts, the information relayed by the software manifests remain just that — informational. While software pipelines use lists of components during the build process, the software-artifact files lack specific information communicated by SBOMs. Python programs, for example, often use a requirements.txt file to create a list of needed software components and their versions, but that file does not have all the information necessary for it to be called an SBOM. Dockerfiles list the components used to create a machine image, but they lack some of the security features needed to qualify as an SBOM.
At a minimum, according to the NTIA, SBOMs must include the author, a timestamp, supplier, component name, a version string, a unique identifier, a cryptographic hash of the component and a list of relationships to other software and components.
There are currently three main specifications for SBOMs that are supported by NTIA: CycloneDX, SPDX and SWID. CycloneDX was created by the Open Web Applications Security Project (OWASP) in 2017 and is designed as a lightweight standard for communicating vulnerabilities, licenses information and component analysis. SPDX is another standard created by the Linux Foundation in 2010 that also covers security, licensing and package information. Finally, the Software Identification Tags (SWID) specification is part of a standard maintained by the International Standards Organization and supported by the National Institute of Standards and Technology that aims to help maintain software asset inventories.
So far, the development of SBOMs standards have been slow, starting over a decade ago. Yet, that evolution became turbo-charged following a number of software supply chain attacks, pollution of open-source projects and vulnerabilities in widely used libraries. Now suddenly people want SBOMs everywhere, and that’s not practical given the large set of interlocking ecosystems, Linux Foundation director of open-source supply chain security David A. Wheeler told README.
“Many organizations are trying to work towards a future where there are one or two common formats that everyone uses to provide SBOM information that works across ecosystems,” he said. “Then, when you get some software, you can also get a far more complete SBOM. … Some closed source suppliers may never provide full transparency into what their customers are consuming, though I hope they will.”
Making SBOMs functional
SBOMs need to move beyond being just informational to actually be useful, Wheeler told README.
“An SBOM by itself is useless unless someone does something with it,” he said, adding that supply chain security requires more than a single file listing the dependencies for a single piece of software. Every component and input into an application must have an SBOM, so that analysis tools can determine the various pieces of software on which the application relies. “Developers … aren’t the users of [SBOMs] — their downstream consumers are,” Wheeler said.
Turning SBOMs into a functional component of the software supply chain means enabling automation, and that means turning lists of software components into files that are machine-readable. Without proper tooling and a robust ecosystem, SBOMs are little more than a table of contents for an application, Jeff Martin, vice president of product at the Mend application security firm, told README.
“This is certainly the place to start, but they need to evolve beyond being just a list of software,” he said. “The long-term intent needs to be a conveyance to stakeholders of the inventory, risk profile and risk mitigations present in a piece of software.”
A strong ecosystem is necessary
Until the ecosystem develops, what can companies do? Development teams should create SBOMs for all their software, diving as deep as possible to create accurate lists of their components. One way to monitor software use is through software composition analysis or other tools.
In many cases, an SBOM-generating tool may be the only option, but the approach does not always work well in practice, Wheeler said.
“Imagine trying to hire chemists to determine how a breakfast cereal was made — it’s very hard — then compare that to asking a factory what ingredients go into a breakfast cereal,” he said. “It takes some effort, but the quality of a build SBOM is typically going to be far greater than an analysis SBOM.”
In a robust ecosystem, information about changes to software components would travel up the dependency chain, allowing upstream developers and users to be aware of any potential security issues.
In the end, companies need to know what ingredients are going into their applications. The ingredient list communicated by SBOMs is even more important to track dependencies that bubble up from the depths of imported code and those coming from commercial providers, which traditionally have been closed-mouthed about the provenance of their software, SANS’s Pescatore said.
“We need to apply the same security requirements for the software that we pay for, for the software we write and for the software we use as an open-source component,” he said. “In the past, enterprises and governments denied using open source, but they have stopped denying it and are now trying to manage it.”
