SBOMs are already a great success!*

 

You may know that I’ve said on various occasions (although not often in this blog) that it’s disappointing that, while SBOMs are being heavily used today for vulnerability management purposes, that usage is almost entirely by software suppliers (i.e. developers), not by end users. While it’s good to see SBOMs have been so successful with suppliers, just about everything you read about them in the general press – and the whole purpose of Executive Order 14028 – is how end users need them to secure their networks. Well, it seems the end users didn’t get that memo, since – I’ll be honest – almost no non-developer organizations are regularly receiving or using SBOMs today.

So, the title of this post may make you wonder if I’ve gone crazy: Despite what I just said, I’m certain that SBOMs have already had a huge amount of success. How could that be?

To understand this, it is important to understand the fundamental purpose of SBOMs, in the supply chain cybersecurity use case. That purpose is not to empower end users to secure the software they operate by their own efforts; this is simply not possible. Truly securing software requires being able to patch vulnerabilities. Other than in exceptional cases, end users (i.e. non-developers) can’t develop their own patches for software they purchased or downloaded; having SBOMs doesn’t change this situation.

Then why do end users need SBOMs (or at least the data from them)? What good does it do to provide users with lots of information on what makes up the software they operate, if they can’t use that information to make the software more secure? And, even if the end user could secure their software if they used SBOMs, I just said they’re not using them. How can I say SBOMs are successful?

I stand by this statement. The fundamental purpose of distributing SBOMs to end users of software was never to empower them to fix software’s problems on their own. Instead, it was to empower them to put pressure on suppliers to fix the problems. Being able to identify components listed in an SBOM, and to learn about vulnerabilities applicable to those components, empowers the user not just to make general exhortations to a supplier to follow good development practices, but to ask them what they’re doing with respect to specific component vulnerabilities. That gives users a lot more power. You might call this, “security by being a pain in the ___”.

In a 2017 study, Veracode found, “A mere 52 percent of companies reported they provide security fixes to components when new security vulnerabilities are discovered. Despite an average of 71 vulnerabilities per application introduced through the use of third-party components, only 23 percent reported testing for vulnerabilities in components at every release.” These numbers are pathetic, as I’ll bet you understand.

This study alone might have helped bring about the FDA’s statement in 2017 (I believe) that they intended to start requiring SBOMs for medical devices, which itself led to the NTIA’s Software Component Transparency Initiative starting operation in 2018. That Initiative (which ended last year) was sparked by some large hospital organizations (“healthcare delivery organizations”, to be accurate) and some large medical device makers, who decided they wanted to get ahead of the curve and start producing and using SBOMs, long before the FDA’s order would come out (it will come out sometime this year).

To my knowledge, the Veracode study hasn’t been repeated, but there is quite tangible evidence that a large percentage of software suppliers have gotten religion on the matter of software security. This evidence is something I’ve already written about: the statement this spring by Steve Springett, founder of the OWASP Dependency-Track open source project (and co-leader of the CycloneDX project), that Dependency-Track was used 200 million times in a single month to query the OSS Index vulnerability database for vulnerabilities found in components in an SBOM (although that statement from April needs to be updated. Steve says the number of queries from Dependency-Track is now up 35% to 270 million per month. And that’s total queries. If you look at the number of individual components searched on, it’s at least 100 times that, since the average software product has more than 100 components. So, this represents about 27 billion individual searches every month – all based on SBOMs and all just from one product that utilizes SBOMs. There are a number of other tools – generally called software composition analysis or SCA – that do the same thing as Dependency-Track, although these usually aren’t free).

Of course, this usage is almost certainly due to suppliers, not end users. However, it makes my point very well: a large percentage of software suppliers are now actively tracking vulnerabilities in components in their products (both those under development and those already in use in the field), so they can be proactive about securing them. They’re not waiting for the customers to start banging on their doors, demanding to know when CVE-2022-12345, with a CVSS score of 10.0, will be patched in their product; they do this because they know that component X in the product is vulnerable to that CVE. Before the customers come calling, the supplier wants to know about important component vulnerabilities, and either patch them or replace the components.

You might wonder why I attribute this huge increase in supplier interest in vulnerability management to SBOMs, since I’ve just said they’re not being distributed to, or used by, end users to any degree (and I’m sure that’s because the end users aren’t asking for them. A lot of their suppliers already have SBOMs and would love to share them when they see demand for them). After all, there could be lots of other explanations for this. Maybe the suppliers were visited by a pillar of fire and heard a voice telling them to start managing vulnerabilities. Or maybe their spouses all started hammering them about vulnerability management. How am I sure one of these isn’t the explanation?

As with many economic effects in the real world, I think this has to do with expectations. The suppliers know that users will start requiring SBOMs in the near future (in fact, US federal agencies have been required to ask for them since August 10). Therefore, whatever may have been a supplier’s security posture previously, not taking a proactive approach to identifying component vulnerabilities in their software and mitigating them (either by patching or by replacing the component) is no longer an option. They need to do something; hence the 27 billion Dependency-Track vulnerability searches. SBOMs are already working!

* However, I will point out that this success will be limited if users can't easily learn about vulnerabilites found in components in the software they utilize. As of the moment, given the lack of easily-to-install-and-use open source or low-cost tools that will list and track component vulnerabilities, and the VEX documents (or real-time VEX notifications) required to make those usable, I have to admit that users can't do this in any significant way today. But I anticipate that the 8 or so major impediments that I've identified, which prevent widespread distribution and use of SBOMs, will be removed in a few years. I'm happy to say that I believe one of them is now on its way to being resolved within two years or less.

The ultimate success of SBOMs depends on their widespread adoption by organizations that use software. If that doesn't happen, the implicit threat to developers that their customers will immediately learn about vulnerabilities in their products and use that knowledge to make disadvantageous comparisons between them and their peers in this regard, will prove empty. I'm sure a lot of developers will continue to track and remediate component vulnerabilities anyway; but a lot won't. We'll be back in 2017.

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.