Stacey on IoT | Internet of Things news and analysis

Internet of Things

  • Home
  • Analysis
  • Startups
  • How-To
  • News
  • Podcast
  • Events
  • About
  • Advertise
  • Speaking
    • Facebook
    • RSS
    • Twitter
    • YouTube

Why IoT (and more) need software bills of materials

April 13, 2021 by Stacey Higginbotham Leave a Comment

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.

What’s in your product? A graphic taken from the NTIA’s 2019 report on SBoMs detailing how software gets embedded in the medical device supply chain.

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.

Want the latest IoT news and analysis? Get my newsletter in your inbox every Friday.

Share this:

  • Click to share on Twitter (Opens in new window)
  • Click to share on Facebook (Opens in new window)
  • Click to share on LinkedIn (Opens in new window)

Related

Filed Under: Analysis, Featured Tagged With: fda, NTIA, Ripple 20, Software bill of materials, Treck

Sponsors



Become a sponsor

Subscribe to Blog via Email

Enter your email address to receive notifications of new posts by email.

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

IoT Podcast

Listen to the latest episode of the Internet of Things Podcast. Just press play!

Sponsors

Become a sponsor





Get Stacey’s free weekly Internet of Things newsletter

  • This field is for validation purposes and should be left unchanged.

Recent Comments

  • Michel on Should you install low-voltage wiring for your smart home in 2023?
  • JD Roberts on Should you install low-voltage wiring for your smart home in 2023?
  • BillD on Should you install low-voltage wiring for your smart home in 2023?
  • Jon Smirl on Should you install low-voltage wiring for your smart home in 2023?

Stacey on Twitter

Tweets by gigastacey
Copyright © 2023 SKT Labs, LLC · Privacy Policy