Why SBOMs have become a vital element of supply chain risk management [Q&A]

In recent years, the software bill of materials (SBOM) has become a key element of software security and software supply chain risk management.

We spoke to Tim Mackey, head of software supply chain risk strategy at Synopsys to find out more about the benefits and challenges of SBOMs.

BN: What was the key realization that emerged as a result of the Log4shell vulnerability?

TM: The Log4Shell experience highlighted that open source usage was pervasive within organizations. Even commercial software was found to have open source components as dependencies. This brought into sharper focus that open source projects are created and maintained by external volunteers, and not their own employees or third-party commercial vendors. This meant IT lacked any controls over the use of open source software within commercial software -- even if they had mature open source governance processes for open source software they directly downloaded and used, or which was used within their custom software development efforts.

BN: What do organizations need to understand about open source in order to be better prepared to confront the unique challenges it brings?

TM: The first step is often just recognizing that you're using open source and from there you can define a workable governance workflow. Since open source teams don’t know who downloaded their code, you don't have a push mechanism for updates; you have a pull mechanism. So, when a project is effectively abandoned, or at the end of its maintained life, we would love for those maintainers to go and say, "Hey, I'm done with this project," and put a nice little notice on it saying there's not going to be any new updates, but that doesn't typically happen.

Now, being able to identify 'abandoned' versus 'done' projects is a separate problem. You can't make that determination if you're not engaged with the project, so if you didn't know that you’re using a project, go and start asking these questions. And that's really what the big first piece of the puzzle is -- accept that you've got open source, accept that it's managed differently and put in a place a process that includes being engaged with those projects.

Where things become particularly challenging is when you're say, three or four levels deep in the dependency or the supplier chain that you may not necessarily know that you have open source code running. That's one of the lessons of the whole Log4j experience, people didn't know that there was this thing called Log4j before the problem happened.

BN: What exactly is an SBOM?

TM: An SBOM is fundamentally a file listing the libraries used by an application. It is a key component of a governance plan that encompasses not only open source usage in a software supply chain, but also becomes an anchor point for other operational elements. The most common operational element being discussed today is the usage of SBOM to communicate vulnerability exposure within components in the software supply chain for the given application.

BN: Is an SBOM on its own enough to mitigate security and licensing risks of open Source?

TM: No. Because an SBOM was featured in an Executive Order there's been a lot of attention given to, 'I need to go and have an SBOM.' For practical purposes, a lot of organizations today are creating SBOMs and it's simply a bill of material saying, "I have these components that come from this spot, and this is the version of them."

It is actually a static thing. It represents what that piece of software looked like when it was shipped. It's fantastic in that respect, but it's not going to tell you whether it's more secure or less secure than something else. It's strictly telling you what that ingredient list looks like for that particular piece of software, and that's where people get a little bit tricked up. The SBOM that everyone talks about is not this magic unicorn -- it is part of a workflow that needs to be implemented inside of companies.

The 'SB' in SBOM doesn't mean Silver Bullet.

The problem is that SBOM data needs to go into a workflow. The people who are on the receiving end of the SBOM might be saying, "Here, I got this file that I don't know what to do with," and that's speaking to a workflow -- a set of processes that organizations need to figure out.

In other words, the knowledge provided by SBOMs is obviously valuable, but if your organization doesn’t have a process to consume it, then there is minimal benefit from having an SBOM and associated vulnerability information. It is this lack of process that is the biggest challenge as while procurement teams can request SBOMs from all their suppliers, if there isn’t a well-defined process to act upon the information in the SBOM, then all that’s happened is you’ve now got one more file in a directory.

BN: What might a successful, well-defined process look like in order to get value from SBOMs?

TM: All organizations have an IT department that is responsible for maintaining the patches in the software that's inside that organization. All software is built from components. We know from the Synopsys OSSRA report that open source usage within commercial software averages 78 percent. So, you know there are going to be components that are open source and that they are going to need to be updated. The SBOM communicates that information if it is attached to the asset that IT is managing.

Now, when the time comes that there's a new vulnerability disclosure, IT is in a position to go and query that SBOM management system and say, "A-ha -- I have this, but where does my patch come from?" The patch comes from the SBOM’s provenance information -- that's what the role of an SBOM is. It's not to tell you that you have a new vulnerability -- it's a document that describes exactly what's in that artifact that you're trying to run, and now you can do the right things if you have that workflow.

BN: What requirements must an SBOM meet?

TM: To be useful, an SBOM must be both accurate and complete, and those are two different problems but resolving one, is reliant on resolving the other.

To start, all external libraries packaged within an application must be logged in order for an SBOM to be complete, including open source software, commercial third party libraries and any software introduced through a third-party contract. Ideally, the SBOM would be drawn from an application’s source code, though this can be a difficult process depending on how the applications' build process is defined. For instance, you may need two different SBOMs when compiling an application for two different platforms; one for Windows, and one for Linux.

Equally, it is important that components are accurately identified, recognizing everything from its origin point to the version of it. A first-party SBOM, which pulls from the application’s source code, is most accurate but there are also third party SBOMs. In this case, the application and not the source code is scanned. This could result in some missing information as you lack the ability to determine the precise version of the library; thus, making this method suitable only if first-party SBOMs are unavailable or as a means of double-checking the first-party SBOM.

BN: What do you see for the future of SBOMs in addressing open source vulnerabilities and overall software supply chain risks?

TM: We are very early in the SBOM era. Most vendors are still working to create SBOMs and that will continue for the foreseeable future. Nevertheless, while a vendor being able to provide an SBOM is an indicator of open source security acumen, it isn't the only indicator. Importantly if an organization requests an SBOM from a vendor but doesn’t have a workflow to process that SBOM and derive value from it, then having a vendor provide SBOMs adds cost without benefit.

Interestingly, many have failed to notice that the security use cases for SBOMs often align with what Software Composition Analysis (SCA) solutions already provide. SBOMs are most useful as part of an overall risk mitigation strategy. This then implies that there are processes in place to measure risk conveyed through an SBOM and then some process to mitigate that risk.

Image credit: Momius/depositphotos.com