Cybersecurity/SBOM Monitoring

Introduction

Within today’s interconnected healthcare environment, the cybersecurity of medical devices has become an essential focus for both manufacturers and regulators. With the increased reliance on network and cloud connected medical devices, ensuring that these devices are protected against cyber threats is critical for safeguarding patient safety and privacy, maintaining the integrity of the healthcare systems while ensuring that medical device manufacturers are able to continue to innovate and bring new products to market in an efficient manner.

In March 2024, the FDA released their updated premarket cybersecurity guidelines aimed at solidifying the requirements for medical devices with internet connectivity. According to the guidance:

“The FDA considers the ‘ability to connect to the internet’ to include devices that can connect to the internet, whether intentionally or unintentionally, through any means (including at any point identified in the evaluation of the threat surface of the device and the environment of use). It is well-demonstrated that if a device has the ability to connect to the internet, it is possible that it can be connected to the internet, regardless of whether such connectivity was intended by the device sponsor.”

The FDA further identifies devices with features such as Wi-Fi or cellular connectivity, network or cloud service connections, Bluetooth, radiofrequency communications, inductive communications, and hardware connectors (e.g., USB, Ethernet, serial ports) as having the ability to connect to the internet.

Key aspects of the FDA guidance include the integration of a comprehensive cybersecurity risk assessment and management, the implementation of “security by design” principles, and the necessity for continuous postmarket surveillance to monitor, identify, and address any discovered vulnerabilities. The guideline outlines the requirement of generating and maintaining a Software Bill of Materials (SBOM), to ensure that all the software components, including open-source and off-the-shelf software, are accounted for and managed effectively.

Within this resource page, we’ll focus on the requirement for continuous surveillance and reporting of the application SOUPs, including the generation of the SBOM as well as continuous monitoring for CVEs as part of the software development cycle.

Approach Overview

SBOM Generation

The generation and maintenance of an SBOM is a critical aspect of cybersecurity risk management. The SBOM serves as a detailed inventory of all software components used within a medical device, providing transparency into the various software components utilized and facilitating effective vulnerability management. The composition of the required SBOM follows the guidelines put forward by the National Telecommunications and Information Administration (NTIA) in the United States. The NTIA guideline outlines a minimum set of fields that must be specified per software component —

Supplier Name – The name of the entity that created and and maintains the component.
Component Name – Designation assigned to a unit of software defined by the original supplier.
Version of the Component – Identifier used by the supplier to specify a change in software from a previously identified version
Other Unique Identifiers – Other identifiers that are used to identify ta component, or serve as a look-up key for relevant databases. Examples of these identifiers include the Package Uniform Resource Locators (PURL), and the Common Platform Enumeration (CPE).
Dependency Relationship – Characterizing the relationship that an upstream component X is included in software Y.
Author of SBOM Data – The name of the entity that creates the SBOM data for this component.
Timestamp – Record of the date and time of the SBOM data assembly.

Due to the large number of components that typically make up an SBOM, the generation process needs to be automated to ensure comprehensive coverage. Currently, two main tools can be utilized to generate the base SBOM:

CycloneDX (CDX)
Software Package Data Exchange (SPDX)

Each of these tools has its own advantages and disadvantages, but in practice, either can be used to generate the base SBOM. Once the SBOM is generated, it should be reviewed and amended to include any missing information that the tools may not have captured. For the purpose of this resource page, we’ll focus on using CycloneDX for generating the SBOM.

The first step in creating and managing the SBOM is determining when the base SBOM should be generated. Ideally, this generation process should be integrated into the CI/CD pipeline by utilizing the application’s package manager lock file to ensure that any newly added SOUPs are automatically included in the SBOM.

The process of generating an SBOM is project-specific, as each project may utilize a specialized package manager to specify and lock dependencies. The first step in this integration is identifying the appropriate tools required to generate the CycloneDX SBOM. A comprehensive list of available tools that can be used to generate the base SBOM is available on the CycloneDx website.

For projects composed of multiple components, it is crucial to generate an SBOM for each component individually. In the case of a cloud application, this would typically include the front end, back end, cloud provider services, and any components deployed within containers.

Vulnerability Monitoring

Once the various project SBOMs are generated and verified to ensure they contain all the required information, the next step in the workflow is to integrate the SBOM into a continuous CVE monitoring and reporting application. There are several options available, ranging from custom development to open-source applications. One such application that can be used for this task is OWASP Dependency-Track.

The Dependency-Track application can be used to monitor multiple sources for new CVEs and trigger actions, such as sending emails or Slack notifications, to alert developers about new vulnerabilities that may affect their application. Additionally, the application can be configured to flag any components that use a license deemed unacceptable by the manufacturer.