Thursday, December 23, 2021

Will having SBOMs prolong your life? Absolutely!


There’s been a lot written about the role of SBOMs (software bills of materials) in addressing widespread vulnerabilities like log4j (not that there have been many vulnerabilities as serious as log4j). It runs the gamut from “If you had SBOMs, you’d know in ten seconds whether any of the 10,000 software products running on your network contains log4j, as well as any of their components, components of components, components of components of components…yea verily, unto the 20th degree of component” to “SBOMs will be quite helpful in finding log4j. An SBOM and $4.70 will get you a tall no-foam latte. That will keep you awake as you look for instances of log4j.”

What’s common to just about all of these statements is they’re written in the subjunctive mood: “IF we had SBOMs….” Because we simply don’t have SBOMs now, to any degree that would be very helpful in researching the simplest vulnerability, let alone as widespread a vulnerability as log4j.

I’d like to suggest that it’s not useful to speculate about what SBOMs could or could not do in this or any other case, any more than it’s useful to speculate about whether, if there is a multiverse, there’s a universe in which the Pope is Jewish.[i] What’s much more useful is to ask a question like, “What are the use cases in which SBOMs will help me, and what do I need in order to make those use cases real?”

SBOMs aren’t an all-or-nothing proposition, where you either have SBOMs for all of your software, or you have nothing. It would of course be nice to have a current SBOM for all software that you own (or rent in the cloud), but right now, you’ll be way ahead of the game if you have an up-to-date SBOM for even five software products on your network. After all, that’s probably five more SBOMs than you had last year.

What can you expect to have at the end of 2022?  Executive Order 14028’s mandate for federal government agencies to require SBOMs from their “critical software” suppliers kicks in next August. Even if you’re not a government agency, it’s likely your suppliers will be able to provide SBOMs, since they’re already producing them for the agencies. You should at the minimum start asking for them from your suppliers. And you should especially start asking for a recent SBOM whenever you’re purchasing software.

But the bigger question is what you do with the SBOMs when you get them. While there is a use case for SBOMs for software license management (in fact, that was the first use case), that is mostly applicable to software developers. The SBOM use case for the overwhelming number of users (and the only use case addressed in the EO) is software vulnerability management. I break that down into three types:

The first is responding to emergency vulnerability notices like log4j and Ripple 20, in which the vulnerability (or vulnerabilities) isn’t applicable to particular final products, but to components of final products. While it would be good for you to have an SBOM for each product so that you know which ones contain log4j, what’s even more important is that you lean on your supplier to tell you whether or not log4j is a “first-level” component of their software, and also whether it’s a component of any of their first-level components (i.e. it’s a second-level component). But they shouldn’t just tell you this; they should issue a patch (or patches) to fix the problem.

Of course, if you had an SBOM that included both the first-level components and SBOMs for each of those components, you would then know whether the product is affected by log4j, down to the second level of components. That would be quite helpful, but it’s also unlikely that the supplier will give you an SBOM for each of the first-level components, since they often won’t be available from the second-level suppliers (most of which are probably open source communities). Again, something is better than nothing. Having the first-level SBOM and even a few second-level SBOMs is better than what you have now for almost all of your software: no SBOMs at all.

The second use case is reducing procurement risk – i.e. reducing the risk that you will purchase a product whose supplier doesn’t have a good program for vulnerability management. Notice that I don’t say “a product that is free of vulnerabilities”. Yes, it’s a good idea to ask for an SBOM for a product you’re considering for purchase, then check each of the components in the NVD, to see if there are any serious open vulnerabilities applicable to them (you can define “serious” as you like, but a CVSS score of 7.0 or higher counts as serious in my book. And there could be lower scores that still might be considered serious, if accompanied by other risk factors. If you decide to purchase the product, you should require the vendor, in the purchase contract, to patch any serious component vulnerabilities, unless they say that the vulnerability isn’t exploitable.

However, vulnerabilities appear all the time. Just because you buy a product that’s free of serious vulnerabilities on Monday, this doesn’t mean that on Tuesday, five serious vulnerabilities in components won’t be identified. Often, this is because a researcher just discovered that a certain string of code, previously thought to be perfectly safe, can be exploited in a particular way so that bad things happen – and five of the components of the product happen to have that same code.

What’s most important for procuring secure software is the track record of the supplier. If you can get a current SBOM for the product (and hopefully at least a few previous SBOMs, say at least one for every six months), you can answer questions like:

1.      Does this supplier let components in their product get very long in the tooth before replacing them? If there are a lot of components that are 2-3 years old, or maybe five or six versions behind the current version, this should be cause for concern.

2.      If a serious vulnerability is identified in a component, on average how long does it take the supplier to replace it (this question might be hard to answer, unless you have an SBOM for every 2-3 months in the past. You may not get those, but it certainly wouldn’t hurt to ask for them)?

3.      Are there any open source components that are effectively end of life, since the community that supports the component is no longer providing patches or updates? This is a big problem. Unfortunately, there’s no gun that goes off to let you know that an open source component is EOL. To learn this, somebody (and there are services that do this) needs to watch activity in the project and raise a flag when there’s been no new activity for say six months. Another indicator is that there are serious vulnerabilities that haven’t been patched, months after they were identified.

4.      Does an important open source component suffer from the “Nebraska problem”, described by this famous cartoon? The cartoon illustrates the risk posed by an important open source project that is now dependent on a “single maintainer”. Again, there are services that will do this, but you can also check for “commits” to the project on GitHub. If only one person has committed for say six months or more, you should at least have a conversation with the supplier about this. You might also put a term in the contract that they will replace this component within say six months.

There are lots of other questions you can ask as well, that having SBOMs will help you answer when doing your due diligence for procurement.

The third use case is probably the most important: ongoing vulnerability management for software operated by your organization. This includes a) getting regular SBOMs from your suppliers (say, at least for every major new version, and hopefully every time there has been any change in the software, including just applying a patch); b) keeping a running list of the components in each product; c) regularly checking in the NVD for vulnerabilities that apply to those components; d) adjusting the list of vulnerabilities for any notifications received from a supplier that a component vulnerability isn’t exploitable in the product itself (i.e. the type of notification that a VEX would provide); e) asking the supplier when they’re going to patch any serious component vulnerabilities that are exploitable in the product; and f) confirming that the supplier keeps any promises they make regarding patches.

This is obviously the most time-consuming use case, since it needs to be conducted day in and day out, for as long as your organization operates software (i.e. up until the day you decide computers aren’t worth it, and just buy a bunch of typewriters and postage stamps. At that point - but only then - you can bid farewell to SBOMs). However, this is also the use case for which you’ll be able to find service vendors that will perform these tasks for you, as well as perhaps other risk management tasks that you hadn’t thought of.

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. Nor are they shared by the CISA’s Software Component Transparency Initiative, for which I volunteer as co-leader of the Energy SBOM Proof of Concept. 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.


[i] Of course, the answer to that question is “Definitely!” If there are an infinite number of universes (which is always the assumption with multiverses, since there would be no way to limit the number according to any scientific principle. After all, the laws of physics will be different in each universe in the multiverse, so you could never identify a constraint on their number), then there’s definitely one in which the Pope is Jewish, in which I’m rich, in which Covid-19 never appeared (now, that would be nice!), etc.

No comments:

Post a Comment