IMDRF published a new guidance on SBOM for medical device cybersecurity

Content of the New Guidance publication

The US National Telecommunications and Information Administration (NTIA) convened a multi-sector initiative of various stakeholders in 2018 to discuss software transparency. One output was the software bill of materials (SBOM) concept, which NTIA defined as a “list of one or more identified components, their relationships, and other associated information.” This initiative has informed SBOM development and adoption internationally. 

Now, the Medical Device Cybersecurity Working Group of the IMDRF, a voluntary group of international medical device regulators, has created a new guidance on Software Bills of Material for medical device  cybersecurity.

The guidance targets both manufacturers (MDM) and health care providers (HCP) that use medical devices which might have cybersecurity issues. 

The Scope of this guidance does not include Cloud Systems, and is focussed on the cybersecurity aspects of SBOMs.

The document is intended to:

• provide recommendations for medical device manufacturers in SBOM generation, management, and distribution;

• provide recommendations to healthcare providers on ingestion and management of an SBOM;

• demonstrate SBOM use cases for risk management, vulnerability management, and incident response from the perspective of medical device manufacturers and healthcare providers.

The guidance introduces an SBOM framework which allows communication about cybersecurity relevant content of medical devices between the MDM and the HCP.

Within that framework, MDMs and HCPs are given SBOM elements and formats, and to MDMs the methods to establish and maintain the SBOM troughout the product lifecycle, while for HCPs, considerations for the ingestion of SBOMs are provided. Distribution of SBOM information from MDM is another topic which is essential for communication.

The goal is to enable an effective exchange of information between software manufacturers and their users about potential vulnerabilities and ways to prevent their exploitation.

With typical usecases, the main goals of SBOM application are demonstrated: Risk management, Vulnerability Management, and Incident management - each from both the perspective of the MDM and the HCP.

Also SBOM components types and tools are discussed which can be used to create and analyse SBOM content. It is obvious, that tools for Coding, Building and Testing software are dedicated to also create, maintain, and analyse SBOM content.

Using the same taxonomy and semantic, interoperability between various tools used for provision, interception and analysis of SBOMs can be achieved, which is the main prerequisite to allow effective communication between all stakeholders.

Consequences for practical work in SAMD development

Simply spoken, SBOM is most of all a standardized method to document the items of a software system architecture, which is known in the regulatory requirements as "configuration of the medical device" which has to be managed throughout the lifecycle of the product.

So, all process steps of the SW lifecycle which are linked to configuration management will have to be considered for creation and update of an SBOM.

Usually, the problem of a manufacturer is more the question "where do I start with SBOM" and "what is the detail level", than using automatic tools to create SBOM from existing code or SOUP software - since the decisions about configuration items and their detail level have been made already.  

The main point to answer this question is like for most engineering questions "it depends". The detail depth of the SBOM depends at least on "who needs to know and why".

"Who" leads to all stakeholders - internally and externally throughout the lifecycle.

"Why" are the tasks of stakeholders regarding the software product.

In the context of cybersecurity, "why" will refer to detection and solving vulnerabilities. 

For a manufacturer to solve vulnerabilities that occur when the product is on the market, the detail level depends on how the software can be updated:

• For complete re-installations, the underlying content of your software only needs to show wich 3rd party SBOMs are in use, while your own code can remain a black box to the outside. Like a firmware for a device, for instance.

• However, for an application which can be updated depending on functional areas like modules, the SBOM should have the detail level that refers to the code units that make up the modules.

Since there is a lot of effort when building an infrastructure to create SBOMs, it makes sense, to document the code for all stakeholders the same way - using the SBOM format. That will enable also product developers to identify the pieces of code which need to be changed in case of bugs or malfunctions, which are not related to cybersecurity.

And, also consider the way how the software will be packaged and shipped.

As a result, tools that are used for software development, software packaging and deployment support the creation of an SBOM. 

"How to start with SBOM": on the level of detail for the product architecture documentation - go from high level components to more and more detailled during the design process. The splitting up will follow risk analysis, vulnerability mitigation, as well as functional and make-or-buy decisions. Start naming, identifying and documenting the components early, and use the same identifiers throughout the life cycle, so that the SBOM identifiers refer to the product architecture as it is documented in risk and cybersecurity assessments, tests and validations.

How can MatrixALM help?

Using MatrixALM, configuration management is supported with uniqueIDs for each documentation item, starting from the design input phase with the first overview architecture, until the last test run of the smallest software unit.

MatrixALM allows to identify SBOM components in the processing of: 

• system architecture;

• SW risk analysis;

• cybersecurity / threat analysis for SW design items, SOUP products and libraries;

• SOUP usage and integration.

In MatrixALM, all components are documented as Matrix Items. The MatrixItemID can be used as referrer also for component IDs in code and code documentation. That is how designing the software as a medical device, creation of the technical documentation and creation of the SBOM are aligned into the same information objects as one single source of truth.

For documentation of SBOMs, MatrixItems can be used as well - to manage updates of 3rd party software and SBOM files as well as for archiving and managing the own SBOM file.

Using automation via the Rest-API or SDK plugins, import and export of SBOMs within change management and automated deployment processes will be possible, thus leveraging MatrixALM to be a repository for the SBOMs of your software products. As part of the product documentation, also publishing of SBOM will be possible from MatrixALM.

As a near future enhancement of MatrixALM, use the cybersecurity threat modelling in MatrixALM for evaluating vulnerabilities documented for 3rd party software. Using the SDK, SBOM and VEX formats can be imported into native Matrix items using plugins. Also, it will be easy to create an SBOM from Matrix items - possibly including vulnerability information in the VEX format.