Wednesday, April 20, 2022

Hmm…It seems SBOMs might become big one of these days…

I’ve written about Steve Springett before. As leader or co-leader of the OWASP CycloneDX and Dependency-Track projects, but even more importantly as a real innovator, I rank him as one of the two most important people (along with Allan Friedman) in the SBOM “movement”. I’ve written about him a number of times, including recently in this post and this one.

One of Steve’s traits is that he’s quite unassuming. So I was completely blown away when, during a small meeting with other SBOM fans last week, he repeated a number he had heard from a representative of Sonatype recently. Sonatype is probably one of the three most important companies in the SBOM community. They are one of the leading software composition analysis (SCA) tool vendors – but they also operate OSS Index, the leading database of vulnerabilities in open source software.

I’ve written about Steve’s Dependency-Track project several times. He initiated it in 2012, years before the term SBOM started to be used. It was the first – and still is the leading – open source tool that will a) parse an SBOM for a software product and identify the components; b) search in a database like the National Vulnerability Database (NVD) or OSS Index for vulnerabilities that apply to those components; and c) track and update that list as often as needed. And while there are certainly other software risk analysis use cases for SBOMs, this is IMHO the most important one.

Back to the story. Last week, Steve was talking to a person from Sonatype about a different subject and wondered out loud how many inquiries Dependency-Track initiates to OSS Index every month; I believe this was the first time he’d even asked this question of Sonatype. Since DT is an open source project, he just knows how many times it’s been downloaded, but not now many copies are being used, or how often they’re being used.

The person checked and emailed him later: In the previous 30 days, instances of Dependency-Track initiated 202 million requests to OSS Index.

Note from Tom Sept. 25: Steve reported new numbers from Sonatype for a recent month (I think it's August, but maybe July). The number of requests from Dependency-Track instances to OSS Index has grown from 202 million to 270 million per month - which is an increase of close to one third since March. If requests continue to grow at that rate, they'll double every year and a half.

Using the same estimate of 100 components per request (since a request from D-T is usually for all of the open source components in an SBOM), this means D-T instances are requesting information on vulnerabilities found in 27 billion components per month.

Does this mean there are 202 million users of Dependency-Track? No. Steve says the average DT system makes a few hundred requests to OSS Index every day. If we assume 250 requests/day over 30 days, we get around 27,000 users. That’s a good number, but what’s most impressive is how much the average system is being used. Even though most of the queries are generated automatically, this shows that somebody finds the analysis that DT performs to be very useful. And BTW, DT isn’t the only tool that does this. Sonatype and the other SCA tools almost certainly generate more requests every day than does DT by itself. It’s a safe bet that there are at least 50,000 organizations that are using SBOMs for vulnerability management purposes today.

Who are those users? Steve and I agree that the great majority of them are developers. Of course, they use DT because they want to know about vulnerabilities found in the components in their products. Armed with this information, the supplier can patch the serious vulnerabilities. Moreover, if a component seems especially prone to vulnerabilities or if the component supplier is slow about issuing patches themselves, they can replace the component altogether.

But Steve says DT has a small but growing number of what I call “pure” end user organizations. I use that adjective not because I think those organizations are without sin, but because they aren’t primarily in the business of developing software. Instead, they sell insurance, fly airplanes, mine copper, build houses…you know, the rest of us. Of course, I don’t think there are too many organizations nowadays - other than maybe my neighborhood dry cleaners - that don’t develop software in one way or another. But it’s safe to say that the great majority of software products that these organizations buy or download are used to help them achieve whatever their mission is, not as components of products that they provide to other organizations or to individual consumers.

Currently, end user organizations use SBOMs very little. The immediate reason for that is their suppliers aren’t offering them SBOMS. And the reason for that is the end users aren’t asking for them. Why aren’t they asking for them? It’s in large part because there are only a handful of low cost or open source tools or services currently available, that allow them to easily utilize SBOMs for component vulnerability management.

Dependency-Track is by far the best of the open source tools, but for some of us, installing and maintaining an open source tool is a challenge. And there’s another drawback at the moment: neither DT nor any other SBOM consumption tool today can ingest VEX documents. As you may know, VEXes will make the vulnerability tracking process much more manageable; this is because VEXes will ultimately remove the need to track component vulnerabilities that aren’t actually exploitable in the product itself. Steve says DT will be able to ingest VEX documents by this summer, and I know that at least one “SBOM processing” cloud service also plans to do that by this summer. I’m sure many more tools and services will follow, even if they’re not ready that soon.

But this will change. In August, every US federal agency will be required, per Executive Order 14028 from last May, to start asking their software suppliers for SBOMs. And they’ll get them, since – as we’ve just seen – huge numbers of suppliers are already producing SBOMs so they can make their own software more secure (and probably some are also trying out SBOMs in order to learn how to produce them, in preparation for compliance with the EO). The suppliers will make their SBOMs available in August, although VEX documents won’t be available in any sort of volume until the fall at the earliest.

I’ll be honest: I really don’t see SBOMs being utilized much by “pure” end users, outside of tests and proofs of concept, until early 2023. But they will be utilized, and ultimately in huge volumes. I say this because of Steve’s number: at least 27,000 organizations making 202 million inquiries a month, using just one tool, to one of the two major vulnerability databases. These numbers show that suppliers aren’t just testing the waters with SBOMs; they’re using them in volume because they’ve found they really are useful for managing software vulnerabilities. When the consumer tools and services are available (as well as VEX documents and more written guidance), the end users will certainly jump in – although not all at once.

What happens when the end users start jumping in, and how many of them will there be? First, what do you think is the ratio between software suppliers and pure end user organizations? Doing a little internet checking, I’m going to guess it’s on the order of at least 1 to 50. So at a minimum, there will be 50,000 * 50 = 2.5 million organizations using SBOMs for software risk management in the US alone in the next say 5-10 years. But even that number could be low. As an old Danish proverb says, “Prediction is difficult, especially about the future.”

So the SBOM/VEX “market” will be a huge one. Can we just sit back and wait for it to materialize? No, there are a number of obstacles that need to be removed (the lack of consumer tooling and services is just one of the largest of these). But do you remember – or maybe you don’t – that people like me said this about the internet in the early 1990s? “Oh, there are so many obstacles: It’s so difficult to use, with all of these IP addresses you have to remember...I haven’t heard of anything I need the internet for…loading a web page with even a top-of-the-line 56K modem is sooo slow…If you want real internet access (not AOL), you have to deal with strange, geeky companies and learn almost a whole new language…etc.

Believe me, I said every one of those things – because they were real problems, and they were certainly obstacles for my adopting the internet (not that I needed obstacles, since I’m slow to adopt any new technology. I believe I was the last person in the western hemisphere to get a cell phone). But in 1995, the Netscape IPO changed my and a lot of people’s minds. It showed there were a lot of possibilities that people like me just didn’t realize, and that the obstacles were being removed because – dare I say it? – there was real money to be made. And so it’s turned out. I’m fairly sure that, within the next 12 months, a similar financing event – IPO or otherwise – will convince a lot of the skeptics that SBOMs are real as well (in fact, an announcement today isn't exactly the Netscape IPO, but it shows SBOMs are no longer just something for geeks to play with. Congratulations, Fortress team!).

Because SBOMs are real, and now Steve has the numbers to prove it. To quote him, “I think this proves that 1) SBOMs are useful, and 2) they can be operationalized at massive scale.”

Amen, Brother Steve!

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


No comments:

Post a Comment