Bring me the broomstick of the wicked witch of the west!

Last week, someone brought to my attention this “position paper” on SBOMs from the “Cybersecurity Coalition” (a group I hadn’t heard of. But then, there are lots of legitimate groups I haven’t heard of). The person pointed out to me that the paper describes roadblocks preventing SBOMs from being widely used. I read it because I’m very interested in identifying these roadblocks. I’ve come to realize in the past year that widespread rollout of SBOMs will require solving some fundamental problems – and those problems need to be identified before they can be solved.

However, in reading this paper (it’s not very long), I realized that this isn’t an honest attempt to facilitate the rollout of SBOMs; it’s an attempt to impede it by asserting that this rollout can’t happen before a bunch of impossible things happen. It’s a lot like the Wizard of Oz ordering Dorothy to bring him the broomstick of the Wicked Witch of the West. The good wizard didn’t expect Dorothy to bring him the broomstick, and he certainly didn’t have any use for it when she did.

So what’s the broomstick that the Cybersecurity Coalition wants “SBOM” to bring back? Oh, just these four items:

·        Establish pilot programs involving software suppliers and agencies to demonstrate the effectiveness of SBOMs in improving vulnerability management practices, based on risk metrics, more rapidly and with less effort than existing tools and processes.

·        Drive to common standards for sharing, processing, and implementation of SBOMs and infrastructure to reduce potential confusion and inconsistency in outcomes.

·        Perform additional research and develop pilot programs to better refine how SBOMs can and should be used in cloud environments.

·        Create public/private workshops to discuss both the technical and non-technical aspects of SBOM sharing, including establishment of criteria for ensuring confidentiality where desired, and avoiding liability for software suppliers.

Of course, there’s nothing inherently bad about any of these things. But the NTIA Software Component Transparency Initiative went on for almost four years (from 2018 through the end of 2021) and took at least some of these steps. Plus, if the good people who wrote this position paper had joined the NTIA effort during that time and suggested these specific steps, I’m sure the group would have considered them. Why have they just recently realized that all of these things are needed?

Of course, the NTIA effort is over (although a couple of the groups that were working under the NTIA are continuing to work under CISA). Meanwhile, Executive Order 14028 (which the Cybersecurity Coalition expresses great love for in their document) – which was published a little more than one year ago - requires federal agencies to start asking their software suppliers for SBOMs less than three months from today. Isn’t it kind of late to suddenly decide that we need pilot programs and additional research and public/private workshops…and lions and tigers and bears (oh my!)? These people could have…you know, mentioned these things when the EO was being drafted or at least after it was released. And they might have contacted OMB to give them this input, since that agency is charged with implementing the EO.

But the items listed in the four bullet points above aren’t all the deficiencies these people have observed. I was shocked SHOCKED! to learn that:

1.      “Given that SBOMs are a relatively new and often misunderstood topic, they are not being produced routinely by many software producers, and changing that will require time and effort.” That’s certainly true. But what are producers required to do? The EO simply requires that federal agencies start asking producers for SBOMs, starting this August. If a producer says it’s too soon for them to produce SBOMs, they won’t be shot at dawn (or any other time). They’ll just need to tell the agencies when they will be ready. On the other hand, given that modern development tools can automatically produce a new SBOM with each build of the software – and given that one single SBOM-based tool used by developers is generating 20 billion requests to one vulnerability database every month - it’s a little hard to understand why there are developers who still think this is something new and difficult.

2.      “… it is important to recognize that, in the near term, there will be inconsistencies related to software produced before the Cyber EO versus software produced after.” One of the main purposes of SBOMs is to help suppliers and users understand how the components in software have changed from version to version and build to build. It seems to me that finding inconsistencies – and their causes – is one of the reasons for having SBOMs in the first place.

3.       “…it remains unclear how departments and agencies will receive and use SBOMs once they are shared with them.” My goodness! The authors seem to be saying that “departments and agencies” are used to receiving perfectly clear instructions that don’t require any thought at all, so they don’t know how to handle ambiguity. My guess is the agencies, had they been asked about this, would point out that dealing with ambiguity is a prerequisite for working in the government, just as it is in private industry. They can handle ambiguity just fine, thank you.

4.      “…overly stringent requirements related to the production and dissemination of SBOMs will require that resources be diverted from other activities.” In other words, the authors are saying, “Don’t get us wrong…we love SBOMs and we love the EO. But don’t expect us to, you know…have to balance competing resource priorities. We’ve never had to do that before.” Hmm…it seems that software developers are the only businesspeople on the planet who don’t have to make choices between (almost) equally valid uses for their funds. That’s news to me (and I expect to their employees as well). In any case, welcome to the real world.

The last two sections of the paper – titled “Automation” and “Challenges in cloud environments” – raise a couple of legitimate points, namely:

First, there isn’t much automation available now for use of SBOMs to manage vulnerabilities by software customers (although there are plenty of tools available for developers, contrary to what the paper says). Nobody has pointed this out more loudly than I have. But the paper suggests that what’s needed is “a series of pilots and test cases”, as if there haven’t been any so far (again, where were all these people while the NTIA Software Component Transparency Initiative – including several proofs of concept – was going on? In fact, the oldest of the PoCs, for healthcare, is still active. Any healthcare software or device supplier that wants to join that PoC should drop me an email; I’ll put you in touch with the leaders of the effort). 

The consumer tools will come; I’m sure of that. In fact, I just received word yesterday that Dependency-Track, the open source tool that is already widely used by software suppliers to manage component risks in their own software, now can ingest VEXes as well as SBOMs (it has ingested SBOMs for ten years, before the phrase “software bill of materials” was even being used); this makes it the first complete user tool for software component vulnerability risk management (I’ll have more to say on this subject soon).

Second, the last section points out that there are a lot of open issues having to do with SBOMs for SaaS. That’s absolutely true. However, the NTIA initiative made the calculated decision to address other issues before taking on SaaS SBOMs – so it’s not surprising these issues are still open. The CISA SBOM effort has this at the top of the agenda for this year, and even if that doesn’t happen, I’m sure another group will take it up.

But it’s simply not realistic to expect all of the capabilities that you would like to see in a new technology will be ready on day one. After all, did automobile buyers in 1910 demand that cars start without hand cranking, go at least 90 miles an hour, and by the way that there be plentiful roads and highways in place to handle cars going at those speeds? My guess is, if they’d demanded those things up front, we’d still be waiting for cars to be widely used today. New technologies need to grow in conjunction with use; no use, no technology growth.

And God help us if car buyers in 1910 had demanded Bluetooth! And especially if they’d demanded cell towers to allow them to make hands-free phone calls.

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.