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