You don’t need SBOMs! You don’t need VEXes!

There has been much written about software bills of materials and how they will do wonderful things for users – everything from curing asthma to finding lost car keys. However, a great deal of what has been written, including (truth be told) some of my posts on SBOMs, has focused mostly on the ultimate benefits of having SBOMs:

• You’ll be able to find and remediate every instance of the next log4j or Ripple20 vulnerabilities that comes down the pike.
• When you’re purchasing new software or intelligent devices, you’ll be able to instantly determine which of the products you’re considering are “safe” and which aren’t.
• As you use software, you’ll be able to learn immediately of any critical new vulnerability in one of the components of a product you use, so that you can immediately bug your supplier to get it patched.

I can promise you’ll be able to do all of these things and more…within the next 5-10 years. But what about the near term? And if you work for a federal agency, what will you be able to do next August, with all of the SBOMs that your suppliers will be required to start pushing your way? After all, an SBOM just lists components. By itself, it doesn’t give you any information about the risks that apply to those components, the most important being the risks due to vulnerabilities found in the components.

Of course, when you have the SBOMs, you’ll then need to go to the National Vulnerability Database (NVD) and find all of the vulnerabilities that apply to components. Without a low-cost or open source tool or service to do this for you, you’ll find this involves a huge amount of drudge work, since you will often have to search for the CPE names of the components and since the average product has 135 components and lots of products have thousands of components. Plus, you should really repeat this exercise at least once a week and hopefully more often, for every software product or intelligent device on your network.

Fortunately, there is one open source tool that will do this for you now: Dependency-Track. In addition, there will be at least one or two low-cost services available in the next few months, to do what that tool does. And if open source isn’t your cup of tea, there are commercial tools that will do this, ranging from not-too-expensive to quite expensive.

However, there’s another thing that’s needed: Because the great majority of component vulnerabilities aren’t exploitable in the software product itself, you’ll waste a lot of time (and you’ll waste the supplier’s time) trying to find component vulnerabilities that aren’t really there, even though the NVD swears up and down that they’re in the components. You need to learn which component vulnerabilities aren’t in fact exploitable in the full product.

This is what VEX documents will do. They will be available by this summer, but you’ll need to have a tool or service that will be able to ingest and interpret them (and don’t even think about processing VEXes manually. You’ll go mad), then prune the list of component vulnerabilities in the products that you use down to the 5-10% that are exploitable.

This list is what you really need. How many tools (whether open source or commercial) or low-cost services will do all of this for you today? Zero, although I know there will be at least one service and at least one open source tool (Dependency-Track, again) that will do that by the summer, when SBOMs should start being more available, thanks to Executive Order 14028.

What’s the moral of this story? The big need now isn’t for SBOMs. Software suppliers are already producing them in large quantities for their own component risk management purposes (the suppliers know how valuable they are!). But at the moment, they’re not sharing them with their customers, because the customers aren’t asking for them. And why aren’t the customers asking for them? It’s probably because they don’t have tools or services available to make use of them.

So the SBOMs and VEXes themselves do you no good. They’re merely steppingstones to what you really need: a list of exploitable component vulnerabilities in the software you use. Both the services and the tools will get you that list, without your even having to see an SBOM or VEX, let alone manipulate it in some way.

Now, I’ll be the first to admit that it will be years before you have a complete, daily-updated list of all the exploitable component vulnerabilities in all of the software you use. On the other hand, the list you do have – say - six months or a year from now will be a lot more useful than the empty list you currently have.

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.