There is a big movement underway to move to a SBOM oriented IT world. SBOM stands for a “Software Bill of Materials”. The idea behind this is that every software or service should come with a label that lists all the software components that go into making the product.
This way, any vulnerability in a component that is not fixed will be visible to customers. Andy Ellis, Advisory CISO at Orca Security, discusses the pros and cons of SBOM (Software Bill of Materials) in light of the software supply chain security debate:
“The SBOm concept sounds simple. Just write down the software used to assemble the system!
“Only” 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. Often this can be helpful because it makes the system easier to think about. Unfortunately, solutions that can be used in simple systems are usually not as simple in more complex systems – and certainly not as effective.
Software is not packaged food
The food ingredient labeling model is often used as a justification for publishing SBOMs. No matter how complex the food supply chain is, there is chemistry behind the ingredient list. Ultimately, no matter how complicated sugar is (dextrose, sucrose, etc.), there are only a handful of ways to use sugar (or sugar-free sweeteners). Software components, on the other hand, are constantly changing. Imagine you buy a grocery item and the ingredient label says “gnusugar-12.17.64-bigpharma-5.2.4.a” and tomorrow that might change to “gnusugar-12.17.66-bigpharma-5.2.4. b”. That might be useful to some people, but it’s a level of complexity that’s being taken out of the food supply chain. Customers don’t insist that an ingredients list include the exact provenance of each ingredient, but provenance is a key goal of SBOMs.
Click on the link in the email we just sent you. Also check your spam folder and whitelist us.
More information about the newsletter.
A perverse incentive: Software should be like packaged groceries
The author’s favorite ingredient when shopping for groceries is “spices” (or “flavorings, both artificial and natural”). After checking for allergens, this is the main ingredient he looks for (exactly how hot is it?), yet there’s no transparency here. SBOMs also have a built-in flaw that creates a place to hide from transparency: in internally developed software. The software that a company obtains from third parties must show up in the SBOMs in a way that, however obscure the wording, is still consistently decipherable. But what about the software that a company writes itself? Because it’s proprietary, it’s basically “condiments”.
Why is that important? An example is a software developer who wants to use open source software in their component. If he does, he’ll have to keep tabs on that subcomponent forever and deal with internal and external requests as to why he hasn’t updated it recently. If companies write their own version instead, nothing needs to be included in the SBOM, even if it doesn’t work that well! Does it seem unlikely that an engineer could make that decision? Think of the engineers at Volkswagen who develop diesel engines. Product managers who have a bit of a headache about this will apply pressure precisely aimed at “not publicly acknowledging third-party components”.
Software services are like restaurants
Buying a software service is in no way like buying a packaged food, but rather using a service. The service itself is an integrated supply chain made up of a number of software products, and each of these products would fall within the scope of a bill of materials. Imagine a food ingredient list that includes not only the actual chemicals in the food, but every utensil in the kitchen, every item of clothing worn by kitchen staff, and the personal hygiene products everyone uses today. This also applies to the supply chain of the restaurant. Each of the suppliers, from national grocery chains to local farms, would need to provide the same information to the restaurant. That’s a huge list that’s often without context for the consumer.
However, a consumer with such an extensive list becomes a cost to the companies. The larger the list of information they provide to customers, the higher the cost of just responding to potential queries. Each customer may have a particular area of specialization, and it is in this area that they will feel comfortable questioning the vendor’s business decisions, especially if those decisions are visible to them. Some of these may be well-intentioned (“Why is there an outdated version of OpenSSL somewhere in your supply chain?”), while others might just be petty friction (“I’m working on component X, why do you have competing component Y in your software used!”). And some of the requests will come from the confusion. Cleaning products in food would be toxic, but perfectly safe if only used to clean the kitchen floor. But how can a consumer determine that from a list of materials?
Are SBOMs a bad thing?
Not at all! The threshold of an externally visible SBOM is negligible at best, negative at worst. But an internal SBOM? This is of enormous value. Any piece of software that a company uses should be known to that company. Security officers should be able to identify each sub-component and understand what vulnerabilities might exist in that sub-component and how relevant those vulnerabilities are to their use of the sub-component. They should know how well their development teams monitor problematic software and whether they prioritize fixing issues that align with their organization’s risk tolerance. But the publication of this detailed data? This becomes expensive, both in production and in maintaining customer relationships, and does not bring significant benefits in making the software supply chain secure.”