The International Medical Device Regulators Forum (IMDRF) guidance on the use of a software bill of materials (SBOM) might not have drawn much attention in times gone by, but cybersecurity has become an increasingly critical consideration in recent years. While SBOMs may not fundamentally change your perspective on cybersecurity, they can be tremendously useful not just in managing cybersecurity across the total product life cycle (TPLC), but also in sustaining good relationships with customers and regulatory agencies.
The FDA may be the most aggressive enforcer of cybersecurity requirements thanks to passage of legislation that allows the agency to reject applications with incomplete cybersecurity provisions. However, enforcement is becoming increasingly stringent across the globe, a fact that makes the IMDRF guidance an especially helpful source of information. The SBOM is tied to IMDRF’s N60 guidance for cybersecurity, which provides the context for this new SBOM guidance.
This new guidance offers a more detailed look into cybersecurity management issues across the TPLC than the N60 guidance, including product end-of-life (EOL) considerations. However, the IMDRF guidance does not address privacy breaches, nor does it apply to cloud-based computing services.
Begin Collecting SBOM Data Immediately
Software developers are urged to begin collecting data for an SBOM during the design phase of the software development life cycle (SDLC). Early sources of data for the SBOM include:
- Proprietary software development documentation;
- Documentation provided by vendors of third-party software;
- Documentation related to any open-source software components; and
- Data generated by software composition analysis tools.
Data regarding firmware should also be included in the SBOM, as firmware is within the scope of the SBOM guidance, and all this should be done with the entirety of the software supply chain in mind. That supply chain consideration works in both directions, as the use of third-party software and firmware requires that any cybersecurity-related updates to these components must be incorporated into a revised version of the SBOM.
While it does not appear that the FDA believes that an electronic SBOM is subject to regulations under Part 11, there are nonetheless several electronic signature-style considerations. Per the recommendations released in July 2021 by the National Telecommunications and Information Administration (NTIA), an SBOM should identify the author of the document(s) and a timestamp of the assembly of the SBOM. There are several SBOM formats to choose from, such as CycloneDx and the Software Package Data Exchange (SPDX) format, each with its own advantages and disadvantages.
Method of SBOM Distribution a Key Consideration
One of the more difficult decisions a software developer will make in connection with SBOMs is the method of distribution. There may be no one method of distribution that works effortlessly for all client healthcare providers and facilities, a problem that forces some difficult choices. The centralized repository might seem the most logical approach to distribution, thanks to the fact that a repository provides an ease of update automation for the customer not found in any of the alternatives. IMDRF notes, however, that a repository doesn’t necessarily solve the problem encountered when a hospital uses several different versions of a device. For the medical device manufacturer or software developer, there are potential intellectual property and liability risks associated with central repositories as well.
Among the alternatives to a centralized repository is the manufacturer-managed repository, which is not especially convenient for the customer who may be forced to check multiple manufacturer repositories. However, this, too, can be automated. Inclusion of the SBOM in the customer security documentation requires no special software tools, but this can be awkward for both the customer and the medical device manufacturer, as there is no facile way to directly link updates to the device(s) to which those updates apply.
Small Events and Big Effects on SBOMs
The IMDRF guidance’s section on change management is brief but highlights one of the most critical functions of an SBOM. This is because any change to software (or firmware) requires a change to the SBOM, and some of these triggers are seemingly innocuous events. While most in the medical device industry are aware that a patch or an update requires an update to the SBOM, some may not realize that the mere removal of a software component may also require an SBOM update. IMDRF suggests the adoption of a change control methodology that includes any changes to third-party software libraries, not an uncommon event in medical device software.
Among the difficulties associated with SBOMs is the vast inventory of legacy devices still in use in hospitals and doctors’ offices, but IMDRF recommends that the medical device manufacturer develop an SBOM for these devices even if it includes only basic information and elements. Obtaining relevant information from third-party suppliers adds another set of hurdles to the formation of an SBOM for these legacy devices, but an SBOM of limited scope and depth is preferrable to none at all.
No discussion of SBOMs is complete without a discussion of risk management, which captures the entire software/firmware supply chain. This is particularly important for the medical device manufacturer/developer’s customers, who need to be aware of how the product’s cybersecurity standing evolves over the product’s life cycle in order to make informed judgments as to when it is time to replace that product. The benefit of an SBOM for risk management purposes is that it can:
- Help promptly identify potential vulnerabilities when external sources of vulnerability are updated;
- Aid in determining whether the risks associated with the product are still acceptable;
- Ensure that the customer’s product is updated as needed — for instance, when a new software release becomes available.
Along with risk management, a hospital or other clinical site must maintain an awareness of cybersecurity vulnerabilities, a consideration that makes the SBOM invaluable. IMDRF noted that this suggests that the medical device manufacturer does not need to have the ultimate solution to a newly discovered vulnerability before contacting the customer so long as an interim mitigation is available.
The worst scenario for a hospital or physician practice is to be blindsided by the discovery that the software and/or firmware in their imaging system simply cannot be made cyber-safe any longer.
One question about life cycle management that is easy to overlook in the development phase is the timeline of support for the product as the end of product life approaches. Obviously not all hospitals are sufficiently well off to replace every product rapidly enough to avoid cybersecurity obsolescence — there are, after all, some rural hospitals that need the legacy MRI system to keep working until the finances are available for a replacement — but the worst scenario for a hospital or physician practice is to be blindsided by the discovery that the software and/or firmware in their imaging system simply cannot be made cyber-safe any longer.
One element of cybersecurity that is not found in any FDA or IMDRF guidance bears mentioning here, which is that hospitals that suffer cybersecurity lapses are at risk of losing accreditation. This is why we recommend adopting a proactive stance on cybersecurity, including adoption of SBOMs as a routine practice. While development of an SBOM can be quite expensive and time-consuming, it is always well worth the effort for entities that want to stay on the good side of regulators and customers alike.
