Thursday, July 28, 2022

SBOMs for devices vs. SBOMs for software

It has always struck me as odd that only one or two of the documents published by the NTIA Software Component Transparency Initiative (which ended last December) mentions SBOMs for intelligent devices, even though the Initiative got its start after the FDA announced in 2018 that they were going to require SBOMs for medical devices in the future (which turns out to be this year). SBOMs will be one small part of the “pre-market” approval process – meaning the device can’t be sold to hospitals unless the manufacturer has provided a satisfactory SBOM to the FDA.

In fact, the “laboratory” in which SBOM concepts were tested was (and still is) the Healthcare SBOM Proof of Concept, in which medical device manufacturers and some large hospital organizations (known in the industry as HDOs, which stands for “healthcare delivery organizations”) exchange SBOMs and document lessons learned. The ongoing work of that group was essential to the NTIA effort and is now informing the CISA effort (although I believe the PoC is now officially under the wing of the Healthcare ISAC). All the SBOMs exchanged in the PoC since 2018 are about medical devices, although the PoC would like at some point to start addressing standalone software products utilized by hospitals, of which there are many.

The reason that SBOMs for devices aren’t mentioned, in any but one or two documents published by the Healthcare PoC itself, is that there has been a dogma that there’s no difference between an SBOM for a device and an SBOM for a software product that isn’t tied to any particular device. And while it’s true that the form of the SBOM is the same in both cases, what is very different are the actions the manufacturer of a device needs to take to help their users identify and mitigate vulnerabilities found in the software and firmware products installed in the device. After all, those actions are what really matters, right?

This spring, I wrote an article with Isaac Dangana, who works for a client of mine in France, Red Alert Labs, which focuses on certification and standards compliance for IoT devices. The article addresses the question of how SBOMs for devices differ from SBOMs for “user-managed” software – which means everything that we normally refer to as “software”; it concludes with a set of actions that we believe IoT users should require (or at least request) of the manufacturers of IoT and IIoT devices that they use.

The article was for the Journal of Innovation, which is published by the Industrial IoT Consortium (IIC). It was published yesterday. You can download a PDF of the article here and you can view the entire issue here. I and Isaac will welcome any comments!

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.

 

No comments:

Post a Comment