Making SBOMs Useful

Interview with Tom Alrich, well-known SBOM and supply chain security consultant.

Software bills of materials (SBOMs) are widely used by software suppliers to identify and remediate vulnerabilities in software products as part of their workflow output. However, software suppliers aren't regularly distributing SBOMs to their customers because the customers aren't asking for them, according to well-known SBOM expert Tom Alrich. 

Tom is a supply chain security consultant and founder of the SBOM Forum, an informal working group of software supply chain professionals. He is the author of Tom Alrich's Blog, which focuses on software supply chain security topics. In this interview, he explains the reasons why SBOMs aren’t yet being used to their full potential, and the efforts underway to support more active SBOM usage. 

Q: Tell us about the SBOM Forum and your involvement with it? 

It’s an informal working group that I started a little over a year ago, when I and others had begun to realize that SBOMs were not being adopted in the end user community to the degree we were expecting them to be. By that point, SBOMs were wildly successful with software developers, who were using tools like Dependency Track, an open source tool created by Steve Springett years before formalized SBOMs existed. Dependency Track looks up vulnerabilities for components listed in an SBOM. Today, Dependency Track alone is used over 300 million times a month by developers to look up vulnerabilities reported in components of an SBOM, and there are other similar tools. This shows how important SBOMs have become to developers today.  

Pro Tip: Generate SBOMs on binary files using GrammaTech’s free SBOM tool. 

Q: Given these advancements, why aren't SBOMS being widely used by software consumer organizations?

I see three problems. The first is there aren’t low cost and easy-to-use tools to perform all the functions required to process an SBOM. There are tools like Dependency-Track that ingest the SBOM and identify vulnerabilities, but a complete tool also needs to flag the component vulnerabilities that aren’t exploitable in the product itself, and which therefore shouldn’t be a concern for the user. 

Most software security professionals estimate that more than ninety percent of component vulnerabilities aren’t exploitable in the product in which the component is contained. If users can’t distinguish exploitable from non-exploitable component vulnerabilities, this will create lots of unnecessary work for them and for supplier help desks.

Q: You’ve been writing about the Vulnerability Exploitability eXchange (VEX), which CISA describes as a novel, machine-readable mechanism that allows both suppliers and users to focus on vulnerabilities that pose the most immediate risk, rather than wasting time on those that don’t pose any risk. Is this helping?

VEX documents are supposed to let users know about non-exploitable component vulnerabilities. However, they aren’t being utilized much by non-developers yet because the users don’t have tools to make use of them. I’ve been on the VEX working group since its second meeting in 2020, but I now realize that focusing exclusively on a document format for VEX was a mistake. The confusion over how to provide VEX information is the second big problem.

What’s needed to address the most important VEX use case is an API through which a software customer can receive from the supplier a list of every component vulnerability in a version of a product, as well as the status of each vulnerability – exploitable, not exploitable, or under investigation. This will be a much faster, easier, and especially more secure way to provide VEX information directly to the tools that will utilize it. Then the tool can provide the list of exploitable vulnerabilities to a vulnerability management tool like Qualys or IP360. I am anticipating the API will be developed and available later this year. 

Q: Are there other major problems that are preventing widespread distribution and use of SBOMs?

The third major problem that is preventing widespread distribution and use of SBOMs is the “naming problem” – the fact that software products can have many names in different contexts. Yet to learn about vulnerabilities found in components of a product, the supplier or user must know the exact name under which each component is listed in the vulnerability database they’re using. A huge percentage of component names in an SBOM can’t be found in a vulnerability database, because the names provided in the SBOM don’t match any name in the database. This defeats the main use case for SBOMs.

The SBOM Forum has developed a proposal for addressing the naming problem in the National Vulnerability Database (NVD). However, the huge market position of the NVD guarantees that even a partial solution to the naming problem in the NVD should have a big impact on the entire software supply chain community. 

Pro Tip: CISA’s VEX working group has published two good documents since moving to CISA: VEX Use Cases and Status Justifications. 

Q: How far are we from solving these three major problems?

The problem with lack of tools is mainly due to the VEX and naming problems. When they’re solved, tools will appear. I’m optimistic that both the VEX and naming problems will be mostly solved within the next two years. As I said, I think the VEX API will be developed this year; at that point, it will be easy to develop tools that utilize the API to identify the set of exploitable component vulnerabilities in a software product.

Very recently, we had an SBOM Forum meeting in which we unexpectedly identified a means by which the solution to the NVD naming problem could be mostly complete by next year, although I’d allow another year, since this requires government actions. It turns out that the issues, both technical and political, may not be as daunting as we thought they were.

The fact is that all three of these problems are taking a big economic toll on the software security community. The idea that it will take many years to solve the naming problem in particular, which was the default assumption of the NTIA Software Component Transparency Initiative just two years ago, is no longer acceptable to the community. This has to be solved soon. The solutions to these problems may involve both the government and private sectors, or they may involve only the private sector if government proves recalcitrant.

However, once these problems are addressed, I think it will be at least a few years before we see widespread use of SBOMs by end users. Instead, I think the huge economies of scale that can be realized by service providers will make them the default users of SBOMs. That is, they’ll do the required analysis based on SBOMs and VEX. and they’ll provide their results to the software users. This could easily happen this year, even today.

I also think that software suppliers should and ultimately will become financially responsible for the analysis required to manage software component cyber risks - even though the service providers will provide that analysis. Given that the suppliers are the main beneficiaries of the use of software components, they should be responsible for mitigating the risks entailed by this use.

Additional Resources: 

Click here for a Free SBOM from GrammaTech, and get started with your SBOMs. 

Read GrammaTech's blog on How SBOMs Reduce Software Procurement Risk And Improve Enterprise Security.