Here’s the REAL reason why software users aren’t requesting SBOMs

My last post discussed the fact that software users clearly aren’t demanding SBOMs from their suppliers now; the post described my idea for why that’s the case. While I still agree with that post, I have to admit that Tony Turner stated in four sentences (which Tony placed as a comment on my post in LinkedIn) a much more compelling reason than mine – and he did it using about 100 fewer sentences than I used!

I had stated that the reason users aren’t requesting SBOMs is that they don’t see much chance of success when they get one, because of a combination of three low probabilities:

1.      The probability that they’ll be able to find any particular component in the NVD when they look for vulnerabilities. This is currently very low, although many software suppliers and service providers have developed various ad hoc tools to improve their odds in this regard;

2.      The probability that any given component vulnerability is exploitable in the product itself (probably around 5%); and

3.      The probability that there will be VEX documents quickly available from the supplier of the software described in an SBOM, to let the user know of all unexploitable component vulnerabilities. This is currently 0%, since no suppliers are producing VEXes now. It presumably won’t always be zero, but the VEX model depends on suppliers regularly producing lots of VEXes, perhaps hundreds for every SBOM released; I now have strong doubts that will ever happen. My proposal for real-time VEX should substantially increase this probability by making VEX notifications almost trivially easy for suppliers, and not requiring blizzards of VEX documents to be distributed to hundreds of thousands of software-using organizations every day.

Of course, probabilities need to be combined by multiplying them, and multiplying three low percentages will result in an even lower total percentage; the combination of these percentages will be not far from zero. In other words, I’m saying that software users aren’t demanding SBOMs because they think that having them won’t improve their security posture enough to justify the time and effort that will be required for them to analyze them.

While Tony didn’t disagree with what I said, he doesn’t think that’s the main reason. And to be honest, I think he’s right. Tony said:

The biggest issue is they are still struggling to handle all the scanner vulnerabilities and SBOMs just pour salt into the wound. Just operationalizing all of this is a huge undertaking. So yes, it’s lack of SBOM tools, but it’s not just that. It’s a core vulnerability management pain point.

What’s the solution to this problem? Obviously, it’s certainly not a great situation if software users ignore an entire class of vulnerabilities – those that are due to third-party components included in software products they use – simply because they’re too busy handling another (perhaps smaller) class of vulnerabilities, namely those that are due to the “first-party” code written by the suppliers of the software.

The best situation would be if users could take a holistic view of all vulnerabilities, including both those due to first-party code (which they learn about through vulnerability notifications from the supplier or from looking up the product in the NVD) and those due to third-party components (which they learn about from receiving SBOMs and finding component vulnerabilities in the NVD). They would then allocate their limited time and resources to identifying the most important vulnerabilities of either type and mitigating those. They wouldn’t feel they have to ignore half of the vulnerabilities in their software, because they don’t even have time to learn about them.

So, the question becomes how software users can prioritize their time addressing vulnerabilities in order that they mitigate the maximum amount of software risk possible. The answer needs to take into account the fact that they don’t have unlimited time or unlimited funds available for that effort.

I know some people will answer this by saying, “That’s simple. The user should just find the CVSS score for each exploitable vulnerability and rank the vulnerabilities based on their scores. Then they should start by mitigating the vulnerabilities with the highest scores. When they have exhausted their vulnerability management budget for the year, they should stop and do something else.”

But I also know other people who will say that CVSS score is an almost meaningless number, so it should never be used to prioritize vulnerabilities to mitigate. If so, what’s the solution? Is it another score like EPSS? Is it no score at all, but a different way of ranking software vulnerability risk?

I honestly don’t know. I’d love to hear your ideas.

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.