Face it: SBOMs will never be regulated into use

There haven’t been a huge number of startup companies providing services and/or tools to the SBOM community (at least I’ve heard of fewer than I expected to by now, although I’m certainly not in a position to learn about all or even most of them).  However, I understand from what a lot of these entrepreneurs have said that they’re expecting to get a big push from regulations, in some way.

What are these regulations? Some of the ideas I’ve heard are:

1.      Some entrepreneurs think they’re helping software suppliers comply with “NTIA regulations” for SBOMs. However, the NTIA doesn’t do regulations, period. Never has, never will. NTIA’s goal is to get members of an industry together to discuss guidelines that will enable a new technology to take off (one technology they did this for – without writing a single regulation – was DNS, for which NTIA was the first domain registrar. The last time I checked, perhaps five seconds ago, DNS is up and running quite well, thank you). The NTIA Software Component Transparency Initiative ran from 2018 through the end of 2021, and it produced a number of documents of mostly good quality. However, they were produced by different groups at different times, and they focused almost entirely on the needs of software and intelligent device suppliers (which isn’t surprising, given that over 95% of the participants, as far as I could see, were from that side of the industry). The Initiative was quite successful in spurring production and use of SBOMs by suppliers for their own component vulnerability management purposes, but everyone agrees the focus now has to be on the consumer side – i.e. the 99+ percent of organizations (public and private) whose primary business isn’t developing software but…you know, using software to provide insurance, build cars, provide cybersecurity consulting services, etc. That is, the rest of us.

2.      Other entrepreneurs have pointed to the SBOM provisions in Section 4(e) of Executive Order 14028. Those entrepreneurs say they’re helping federal agencies comply with the EO (although they’re all sure that whatever they do for the agencies will end up being demanded by private industry as well). However, all the EO requires is that agencies start asking for an SBOM from each supplier of “critical software”. The supplier could tell them to go pound sand, but the agency would still be in compliance.

3.      The EO called for NIST (really the NTIA) to develop a list of “minimum elements” for an SBOM. The NTIA did that, but most of the statements in that document are written as “may” or “should”. There are some that use “must”, including this one: “..all top-level dependencies must be listed with enough detail to seek out the transitive dependencies recursively..” This means that all “top-level” components in an SBOM need to have detail on each of their components. But guess what? I doubt any supplier will do this for a while. For example:

a.      There are some products with thousands or tens of thousands of “top-level” components (and BTW, the concept of levels doesn’t have any formal meaning in an SBOM, since Component A can be a dependency of Component B, while at the same time Component B can be a dependency of Component A in the same product. However, there’s a general understanding of what it means). Let’s assume a product contains 1,000 top-level components (dependencies). Each of those will normally have at least 140 sub-components (which is what’s meant by transitive dependencies, although that term applies to all the levels “below” sub-component). This means the supplier of this product will have to contact 140,000 suppliers of sub-components (90% of which will be open source projects, from which the supplier will usually not get any response) to ask for an SBOM, for just one of the supplier’s products. How many of these “second-tier” SBOMs are they likely to get? My guess is they’ll be lucky to get five. So that means our luckless supplier will have 139,995 instances of non-compliance. Talk about a bad day!

b.      For probably at least 95% of the components the supplier lists in their SBOM, the component name originally produced by the tool that created the SBOM won’t be searchable in any major vulnerability database, meaning the supplier will have to use AI, fuzzy logic and other tricks to find it – and in many cases, they may never find the component in a vulnerability database. This is the famous “naming problem”. Thus, just producing a single usable SBOM could be a major project, again for a not-unusual product with hundreds or thousands of just “top-level” components.

4.      The EO required NIST to develop “guidelines” for SBOM production and use by February 6 of this year. NIST did put out a document on that date, but it mainly referred to other documents, produced by NIST and others. There was no set of guidelines in NIST’s document. This wasn’t a surprise to people who understand that NIST doesn’t produce guidelines (let alone regulations) for anything having to do with cybersecurity. NIST – very properly, in my opinion – understands that cybersecurity is a risk management exercise. 

All NIST’s cybersecurity documents provide a framework for managing a particular type of cyber risk, but none of them have ever prescribed certain actions – nor will they ever do that. Sure enough, the documents NIST put out early this year – SP800-161r1 and NIST800-218 (aka the Secure Software Development Framework) - had nice things to say about how SBOMs fit into their framework, but nothing else in terms of prescriptive requirements, or even guidance. I’ve just learned that NIST asked to be removed from EO 14028 compliance responsibilities earlier this year, so perhaps they found this episode a little too traumatizing for their taste.

5.      The most recent dashed regulation hope was the US House version of the National Defense Authorization Act (NDAA) of 2023. A stiff requirement that software suppliers to the US armed services provide SBOMs was removed last week, right before the bill was passed by the House (the bill now needs to be passed by the Senate, which of course is very unlikely to add SBOMs back into it).

There was one more hope of the regulation buffs: The Office of Management and Budget (OMB), which was charged with implementing the EO, had set August 10, 2022 as the date when federal agencies would need to start requesting SBOMs from their suppliers. That date passed without any formal guidance being issued, but “guidance” did come on September 14, in the form of Memorandum M-22-18. Surely, that document set out some concrete requirements for SBOMs, right?

‘Fraid not. The OMB simply said:

A Software Bill of Materials (SBOMs) may be required by the agency in solicitation requirements, based on the criticality of the software as defined in M-21-30, or as determined by the agency. (my emphasis)

 It followed that up by saying:

SBOMs must be generated in one of the data formats defined in the National Telecommunications and Information Administration (NTIA) report “The Minimum Elements for a Software Bill of Materials (SBOM)”. (since just above every SBOM I’ve seen in the past couple of years is in either SPDX or CycloneDX format, it’s clear the market is already requiring this. No government statement was needed).

In other words, any entrepreneur who believes that existing regulations, or coming regulations, will make them rich in the SBOM “marketplace” had better recalibrate their business plan, so it doesn’t depend on regulations at all.

But guess what? I’m quite optimistic that it won’t be hard for these entrepreneurs to recalibrate their plans, since I think an initial wave of SBOM use – which I’ll admit I thought, until this spring, would occur when Section 4(e) of the EO became mandatory on August 10 – is definitely coming. But I’d say the ETA for this initial wave is 2-4 years from now (although I’m sure that at least a few major suppliers will start producing SBOMs with some regularity next year).

My optimism is mainly due to one piece of evidence: In March, Steve Springett, leader of the team that created and maintains the Dependency-Track open source SBOM analysis tool (which is now ten years old) as well as co-leader of the CycloneDX team, learned to his surprise that DT was being used 202 million times a month to look up the components in an SBOM in the OSS Index open source software vulnerability database. Moreover, in September he found out that number had jumped to 270 million (he estimates it’s at least 300 million now, which I don’t doubt). This amounts to at least a 50% annual growth rate. In case you don’t know, that’s a lot (and this isn’t individual component lookups – this is just looking up all the components in one SBOM. If you assume that the average SBOM has 100 components - a low estimate - this means there are now 30 billion monthly queries to OSS Index, which are produced by just one software tool (there are a number of other tools that do what DT does).

Dependency-Track has always been aimed primarily at software developers, and while Steve Springett is sure that at least some non-developer software consuming organizations (i.e., any organization whose primary purpose isn’t developing software) are using it to manage component vulnerabilities in third-party software that they operate, he’s also sure there aren’t many such cases.

However, given the rate at which developers are increasing their use of Dependency-Track, it seems to me inevitable that their customers (i.e. users) will want to get into the action as well. After all, if the software gets attacked, they’ll be the ones that pay the price (and speaking of price, what do you think the SolarWinds attacks, which resulted in a number of large federal departments and agencies being compromised for many months, cost the US economy? I have no idea either, but it has to be huge – and we probably still don’t know everything that happened during the many months that the agencies were essentially owned by the Russians).

My feeling is that if Dependency-Track, a supplier tool that could fairly easily be turned into an end user tool, is experiencing such heavy – and rapidly-growing – usage now, it’s inevitable that users will soon say, “Hey, I want some of that.” They’ll start asking for SBOMs from their suppliers (which they’re not usually doing now, unless they’re subject to the EO). When some suppliers start providing SBOMs to their customers, those same customers will ask all their software suppliers to do the same. Soon, we’ll have what’s known in the military as a “self-licking ice cream cone”: a process that sustains itself by its very existence.

When that happens, do I think that SBOMs will start flowing out to end users like water on a desert? They will flow out, but mostly not to end users. I don’t know of a single complete end user tool for consuming SBOMs today - and certainly not one that’s free or low-cost. I doubt this situation will change in the next few years, either. Since I’m sure that end users will need an almost completely automated tool to perform all the steps required for software component vulnerability management, I don’t see them being at all interested in performing these steps themselves (or even stringing together a bunch of open source tools), until such an automated tool is available to them.

But this doesn’t mean that software consumers won’t want to learn about exploitable vulnerabilities in the software they depend on, or that they have to wait for a tool to do this. Rather, I think the initial 2-3 years of SBOM utilization by end-user organizations will occur mostly through engagement of third party service providers, who will provide subscription-based services for SBOM/VEX-based software component vulnerability management. Those few providers will be able to spread out the cost of developing these services over a large number of customers, just like Henry Ford was able to spread the cost of building cars over a much larger number of customers than his competitors could, by implementing efficient assembly lines.

As a matter of fact, I really don’t think that end users should even have to pay the service providers’ bills for identifying and tracking exploitable software component vulnerabilities; this should be the supplier’s responsibility. After all, they’re the primary beneficiaries of the huge increase in use of software components in the last maybe 20 years. Why shouldn’t they also be primarily responsible for mitigating the additional risk introduced by this practice? More importantly, why should every one of a supplier’s say 10,000 customers have to perform exactly the same analysis, to learn about exploitable vulnerabilities in the software they use, when the supplier should already have performed this analysis and could easily share the results with all of them? And if the supplier hasn't performed this analysis, shame on them. All the more reason for them to start performing it themselves or paying a third party to do it for them.

There’s another big advantage to having third party service providers perform this analysis: the need for the biggest use case for VEX – telling software end users that component vulnerabilities they’ve identified through having an SBOM aren’t exploitable in the product itself – goes away. The supplier and the service provider can make their own arrangements for communicating whether or not component vulnerabilities are exploitable in the product itself; they don’t need to follow any particular format to do that. Sounds good to me!

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.