So, what can you do with SBOMs after you get them?

Last week, I put up a post about a webinar on SBOMs that Fortress Information Security will present next Friday, May 13, titled “Software Bill of Materials Overview”. While that title doesn’t tell you a lot in itself, the first sentence of the description of the webinar reads

Fortress VP Tony Turner will be presenting key use cases for any software consumers looking to get started using SBOMs for procurement, vulnerability management, (incident) response, and software assurance activities.

In my post, I commented that “Fortress has put together what looks like it will be the first webinar describing how people like you and I can use SBOMs to make our organizations more secure.” In other words, I was saying this will be the first webinar that discusses using SBOMs to secure your organization from vulnerabilities and risks found in the software you use.

This idea was similar to what I said in a post a month ago, after Fortress posted an important white paper on SBOMs. I said the paper, for the first time, “provides a comprehensive narrative of what an end user organization needs to do to obtain SBOMs and VEX documents and use them for the purpose of reducing the cybersecurity risks their organization faces – specifically risks due to components found in the software they utilize to achieve their mission.”

When I put up the above-linked post on LinkedIn last week, Ron Brash of aDolus (another organization very involved with SBOMs) took exception to my assertion that this would be the first webinar that describes how to use SBOMs to make your organization more secure. He pointed to two webinars that aDolus presented last year (one with Industrial Defender and one with Verve), that were both aimed at consumers. I had attended one of these (and took notes, which I just reread); I just watched the other.

Both were excellent webinars, and I recommend you watch at least one of them (they were both presented around the same time, so the subjects were similar). And I’ll agree that both of them were intended for use by software consumers, not software producers. But I stand by my original statement that neither webinar discussed how organizations can use SBOMs to make themselves more secure, although I’ll point out below that such an omission is the rule, not the exception, in SBOM messaging so far.

To understand why I say that, look at the topics discussed (and addressed very thoroughly) in the two webinars. They include:

1.      The National Vulnerability Database (NVD) doesn’t usually identify vulnerabilities found in components of a product, but just in the product itself. This is because the NVD has no way of knowing what components are included in a product. Of course, this is why you need an SBOM, since that tells you the components in the product and you can – in theory – look each component up in the NVD, in order to learn of the risks it poses.

2.      But it isn’t easy to find vulnerabilities for the products themselves in the NVD, let alone for the components. You really need to know the CPE (Common Platform Enumeration) name for the product, and there are a lot of problems with that (this is the “naming problem”, which I pointed out in 2020 is one of the two or three most serious problems preventing widespread use of SBOMs. It still is, although a group of people, which includes both me and Eric Byres of aDolus, has very recently resolved to understand the causes of the problems – which are actually not complex - and develop a suggestion for NIST to fix the problems moving forward. Of course, that in itself won’t fix the problematic data found in the NVD today, but doing that isn’t technically hard, either – once the revised structure is agreed upon).

3.      A big component (so to speak) of the naming problem is the fact that the supplier and name of a product change frequently, primarily due to mergers and acquisitions but also due to marketing changes, efforts to harmonize product lines, etc.

4.      SBOMs don’t normally provide information on open vulnerabilities in components. To learn about those, you need to look up the components in the NVD (or another vulnerability database), where – of course – you’ll once again run into the naming problem.

I agree that all of these are problems. However, these aren’t in themselves consumer issues – they’re supplier issues. In my opinion, the software supplier needs to take responsibility for addressing each of these problems as part of fulfilling their responsibility to produce SBOMs, and to alert users to vulnerabilities that are due to components in the product.

Why is this the supplier’s responsibility? Because they chose the components to include in their product. Including components (especially open source ones) in their software saves suppliers a lot of time and money, as opposed to having to develop or purchase the code themselves. But these components also bring risks to the users of the software – as we know all too well from Heartbleed, Apache Struts, Ripple20, Log4j, etc. While users have a role to play in managing those risks, the primary responsibility is the supplier’s, starting with creating and updating SBOMs for their products.

Since the four items listed above (and others) are the supplier’s responsibility, what are the users responsible for doing, to reduce the risk posed by components of the software they use? That’s exactly what – I believe – will be discussed in the webinar next Friday. However, you can get a preview of the webinar discussion in the white paper that I mentioned. Here are some of the topics addressed in that paper (I’m sure some of these will be discussed in the webinar as well):

·        SBOM USE CASES FOR VULNERABILITY MANAGEMENT  

·        UNDERSTANDING UNVERIFIED TRUST

·        PRODUCT VS. COMPONENT VULNERABILITIES

·        SBOM SOLUTION PROVIDERS AND VULNERABILITY MANAGEMENT  

·        NEW COMPONENT VULNERABILITIES  

·        NON-EXPLOITABLE COMPONENT VULNERABILITIES  

·        USING SBOMS IN PROCUREMENT  

·        CONSIDERATIONS BEFORE RECEIVING SBOMS

·        WHAT TO DO WITH SBOMS AFTER RECEIPT?  

·        WHEN SHOULD SBOMS BE UPDATED?  

·        COMPONENT MODIFICATIONS AND SOFTWARE PEDIGREE  

These are the topics that, in retrospect, should have been addressed in the two aDolus webinars more than a year ago, given that their focus was intended to be on software consumers, not suppliers. However, I certainly find it understandable that aDolus focused on problems that were really supplier issues, in a webinar that was intended to be for end users. When I say that there’s been no previous document that’s addressed how to use SBOMs, I’m including two government-published documents that were also supposed to address use of SBOMs by end users who aren’t also software developers (the developers’ use case for SBOMs is to evaluate risks posed by components they’ve included in their products. As I wrote a couple of weeks ago, there’s now ample proof that developers are already putting SBOMs to work, in a huge way, to help them reduce their own software development risks. So the developers don’t need much guidance on using SBOMs anymore – it’s the consumers who do):

1.      Before it shut down last year, the NTIA Software Component Transparency Initiative published a “Software Consumers Playbook”. It’s well-written (although the language will be hard to understand by non-developers, its intended audience), but it focuses almost entirely on how SBOMs should be produced – which, of course, has nothing to do with the question of how a consumer can use SBOMs after they’ve received them.

2.      In December, NIST put out preliminary guidelines for implementation of Section 4(e) of Executive Order 14028; this section includes the two or three provisions that mention SBOMs. In the post I wrote on the guidelines, I pointed out that, in the approximately four pages of guidance regarding SBOMs, there are only two sentences that even mention how software using organizations (i.e. the federal agencies that are subject to the EO, very few of which are in the primary business of developing software) can use SBOMs for component vulnerability risk management purposes. They are:

Develop risk monitoring and scoring components to dynamically monitor the impact of SBOMs’ vulnerability disclosures to the acquiring organization. Align with asset inventories for further risk exposure and criticality calculations.

Regarding those two sentences, I pointed out immediately below them, “…this is the only requirement in the entire SBOM section that relates to the agencies using the SBOMs. Every other requirement specifies something that the agency needs to ask their suppliers to do or provide. I hope NIST doesn’t expect the agency to simply drop an SBOM in the bit bucket as soon as they receive it – they need guidelines for how they will use it.”

Unfortunately, up until Fortress released their white paper last month, those two sentences constituted the entirety of the guidance available – from either public or private sources - on making use of SBOMs for software component vulnerability risk management purposes, at least that I know of. If anybody knows of other previous guidance, I would love to hear about it and will publish it.

Does this mean that I don’t think software users need to know anything about the various challenges that arise in developing SBOMS? No. That’s why I recommended that you watch at least one of the aDolus webinars. I also recommend that you try to at least skim through every document found here.

But as you do that, and you hear about the many problems developers face in preparing SBOMs, you need to keep in mind that these aren’t your problems. Your problem is what you do with that nice, shiny SBOM you just received. And keep in mind that there’s no good way to utilize SBOMs (or VEX documents) for risk management purposes, except through automation – either a tool that you run on-prem, or a third-party service that runs their own tools and provides you with the results; those results should include a continually-updated list of exploitable component vulnerabilities found in each of the software products used by your organization.

As of today, there’s no tool or third-party service (other than hourly consulting services, which aren’t scalable), that will ingest both SBOMs and VEXes and produce that continually-updated list for you. And don’t fool yourself into thinking that you could do that on your own, given enough time and effort and YouTube videos. There are probably products on your desktop today that have literally thousands of components (the average software product contains close to 150 components); are you really going to go through the steps shown in the video for every one of those components, especially since new SBOMs may, for some products with lots of components, arrive daily?

Sure, you can try looking up a few components from an SBOM in the NVD; you might even succeed in learning about a few vulnerabilities that apply to those components. But don’t mistake doing this for actually using SBOMs for vulnerability management purposes. If you want to learn about that, read the white paper and sign up for the Fortress webinar on Friday the 13^th.

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com.