There’s a big movement afoot to move to an SBOM-oriented world. If you’re new to this acronym, an SBOM is a “Software Bill of Materials.” The idea is that any piece of software, or service, should come with the equivalent of an ingredients label, itemizing the component pieces of software included in the manufacture of the product. That way, any vulnerability in a component that you don’t fix becomes visible to your customers. It sounds simple, right? Just write down the software you used in assembling your system!
Just.
“Just” is the most dangerous word in cybersecurity. In any complex system, there is an impulse to use a much simpler model to describe the system. Sometimes, this can be helpful because it makes the system easier to think about. Unfortunately, solutions that apply in simple systems are not usually as easy to apply to—and certainly rarely as effective in—more complex systems.
Software is not like packaged food
The model of food ingredient labeling is often used to justify publishing SBOMs. But even as complex as the food supply chain is, chemistry underpins the ingredient list. Even as complicated as sugars are (dextrose, sucrose, etc…), at the end of the day, there are only a handful of ways to include sugar (or non-sugar sweeteners). Software components, on the other hand, are continuously changing. Imagine buying a food, and the ingredient label contained “gnusugar-12.17.64-bigpharma-5.2.4.a.” And tomorrow, that might change, to “gnusugar-12.17.66-bigpharma-5.2.4.b.” For some people, that might be useful; but that’s a level of complexity we abstract out of the food supply chain — we don’t insist that an ingredient list contain the specific provenance of every ingredient, but provenance is a key goal of SBOMs.
A perverse incentive: Software is like packaged food
My favorite ingredient when buying food is “spices” (or “artificial and natural flavorings”). After checking for allergens, that’s the most important ingredient that I care about (exactly how much heat does this have?), and yet it’s the place without any transparency at all. And SBOMs also have a built-in flaw that creates a place to hide from transparency: in internally-developed software. The software that a company includes from third parties has to show up in the SBOMs, in a way that, as arcane as the phrasing might be, is still consistently decipherable. But the software that a company writes itself? Since it’s proprietary, it’s basically “spices.”
Why does this matter? Imagine a software developer wants to use an open-source piece of software in their component. But, if they do, they’ll have to keep track of that subcomponent forever and deal with internal and external inquiries about why they haven’t recently updated it. If, instead, they write their own version, even if it doesn’t work as well, nothing has to go into the SBOM! Does it seem unlikely that an engineer might make that choice? Consider the engineers at Volkswagen implementing diesel engines: Product managers who feel pain will exert pressure that will exactly align with “don’t publicly acknowledge third-party components.”
Software services are like restaurants
Buying a software service isn’t at all like buying a packaged food; it’s more like dining out at a restaurant. The service itself is an integrated supply chain of several software products, and each of them would be in scope for an SBOM. Imagine a food ingredient list that didn’t just include the actual chemicals in the food, but also listed every piece of equipment in the kitchen, as well as every article of clothing worn by the cooking staff, as well as the personal hygiene products each of them used today—and on any day they interacted with anything else in the list. And that extends into the restaurant’s supply chain. Each of their vendors, from the national food supply chains to the local farms would need to provide that same information to the restaurant to provide to you. And that’s a massive list, often without context to the consumer.
Now consider the cost to business of that large of a list. The larger the list of information you expose even to legitimate customers, the higher the likely cost of just answering a customer’s inquiries about the list becomes. Each customer may have a specific area of passion or expertise, and in that area, they’ll feel comfortable challenging the business choices made inside the vendor, especially if that choice is exposed to them. Some of those might be well-intentioned (“why is there an outdated version of OpenSSL somewhere in your supply chain?”), but some might just be petty friction (“I work on component X, why did you use competing component Y in your software!”). And some of the inquiries will come from a place of confusion. Cleaning materials would be poisonous in your food but entirely safe if only used to clean the kitchen floor—but how does a consumer determine that from just a list of materials?
Are SBOMs entirely awful?
Not at all! But the marginal value of an externally visible SBOM is, I think, negligible at best, and is a net negative at worst. An internal SBOM, though, has massive value.
Every piece of software that a company uses should be known to that company. You should be able to identify every subcomponent, understand what vulnerabilities might be present in that subcomponent, and know how relevant those vulnerabilities are to your use of the subcomponent. You should know how well your engineering teams stay on top of problematic software and whether they are prioritizing fixes to match the risk tolerance of your business.
But publishing that detailed data? That’ll be expensive, both in production and in maintenance of customer relationships, and won’t provide a magical benefit to make the software supply chain secure.
Copyright © 2022 IDG Communications, Inc.
