Why IoT (and more) need software bills of materials

You may have started to hear the term “software bills of materials (SBoM)” in the last few years. In 2019, the Food and Drug Administration set out guidance for medical devices makers to disclose the software used in each of their products. More recently, in the wake of the Solar Winds attack this past winter, cybersecurity experts have been anticipating an executive order that boosts federal cybersecurity and would include a requirement for a software bill of materials.

So if you’re wondering what the heck these are, why they matter, and what the tradeoffs are, let me help. First up, a software bill of materials is simply a list of the code used in a software-containing device. The idea is that people who operate the device can check its SBoM for security vulnerabilities that might affect it.

So the same way food manufacturers have to list their ingredients so consumers can, for example, ensure they won’t inadvertently suffer an allergic reaction, companies making connected products have to list both the code they used to make the device and where that code comes from. This is important, because software can be made using chunks of code from a variety of places. Copying and pasting is common. So is using old software that has been previously proven to work.

Software makers may not realize that their product contains vulnerable code. A good example of this is the Ripple20 vulnerability, which affected a Transmission Control Protocol/Internet Protocol (TCP/IP) software library developed by a company called Treck Inc. Treck made networking software for embedded systems, so thousands of IoT devices for the home, enterprise, and medical world were vulnerable. While Treck provided a patch and contacted those it knew used the software, it couldn’t find everyone.

For organizations that have an SBoM, knowing if your gear contains vulnerable code is easier. But figuring out where your code comes from is hard and simply knowing where the code comes from doesn’t prevent a vulnerability from becoming a hack. To do that, someone has to patch or update the code, potentially messing with the way the device functions. If there are millions of those devices out on the market, running critical jobs and then patching them becomes an especially fraught proposition.

For many, ignorance is bliss, and even with a software bill of materials, the risks of an improperly coded update outweigh the risks of the vulnerability. So a device owner may know there’s a vulnerability but decide to do nothing about it.

There are also people opposed to mandated SBoMs. They argue that unlike the world of hardware bills of materials (or your list of food ingredients), software is more layered and full of complexities. In a hardware BoM, you might list a specific chip, but in a software BoM, you’d have to list the software, the component libraries, and possibly even different variants of the affected component library.

All of which ties back to the initial objection related to processes and the need to update. Not all vulnerabilities will become exploits, and with so many different software components, teams could spend all day patching or tracking vulnerabilities.

And yet, this sort of slippery slope to the most complex and worst-case scenario ignores the advantages that come from forcing product managers to know what’s inside their devices and product owners from keeping track of the software on which their operations depend. Just because it’s complex doesn’t mean it’s not worthwhile. As we embed software into more and more of our physical infrastructure, having a basic understanding of what’s inside matters.

Beyond that, making the invisible visible through SBoMs can help developers create standards for common components that are more robust, or help vendors offer longer support for their products. Enterprises are already asking software vendors to include a software bill of materials with their products, and Gartner estimates that more than half of enterprises will demand SBoMs by 2024, up from 5% in 2019.

So even if the federal government doesn’t act, conscientious IT buyers may force the issue.