Software Bill of Materials

SBOM as part of vulnerability management

Risk management processes for hardware and software are essential to ensure quality and performance over the entire product life cycle. An implemented risk management process reduces the risks for patients, users and indirect users (safety) as far as possible and ensures the safety of the software and the networked customer environment (security).

Vulnerability management is part of risk management for IVD products and describes procedures for dealing with vulnerabilities. The protection objectives to be fulfilled as part of vulnerability management are the so-called CIA protection objectives (CIA triad):

The quality of vulnerability management also depends on how well the manufacturers provide information about the software components used and how they are used. The availability of high-quality sources for vulnerabilities plays an important role here. In principle, all software components of a product with known vulnerabilities must be identified and evaluated. Without the complete identification of all software components in a product, vulnerability management can only be implemented inadequately, which is why particular attention must be paid to documentation with the so-called Software Bill of Materials (SBOM).

An SBOM is a systematic and structured list of all software components of a product. It specifies which components (OTS, packages, libraries, frameworks, code snippets, etc.) are in an application, where they come from (creator/supplier/source), which version they have and how they can be clearly identified. In vulnerability management, a documented IT risk management process that puts SBOM at the forefront has become established.

Legislators have also recognized the central importance of SBOM and mentioned it in relevant regulatory IVD requirements, but have not yet made it mandatory to comply with norms and standards. An overview of the regulatory requirements in the area of SBOM is included at the end of the document.

Legal regulations in the EU

The main requirements for IVD products containing software or for stand-alone software can be found in Annex I Section 16.1, 16.2 and 16.4 of Regulation (EU) 2017/746 (IVDR). The requirements are to ensure the performance and IT security of the software throughout the entire product lifecycle.

Legal regulation in the USA

In Section 523(b) of the Consolidated Appropriations Act of 2023, the FDA explicitly requires manufacturers to perform vulnerability management and provide an SBOM for medical devices and IVDs.

Necessity of an SBOM

• Appropriate risk management and vulnerability management can only be carried out with a correct and complete SBOM.
• With a complete SBOM, product lifecycle management becomes more predictable and the software supply chain more transparent. Among other things, the SBOM can serve as a starting point for streamlining and updating products and reducing costs in the postmarket.
• A complete SBOM enables a systematic view of third-party licenses
• Customers request an SBOM from the manufacturer for their processes such as risk management, tenders, etc.

Contents of an SBOM at the time of release
(based on BSI)

General information:

• Creator of the SBOM
• Date and time of the SBOM data compilation

Data fields per component:

• Creator
• Name
• Version
• Direct dependencies on other components
• License used
• Checksum
• Unique ID (CPE/PURL) to look up vulnerabilities
• Status or end of support according to creator

Other optional components of an SBOM

• Vulnerabilities
• Lower level components

How can the SBOM be implemented successfully?

There are a number of standards, tools and procedures to facilitate the creation of an SBOM. The most important ones are listed and explained below.

1. Use machine-readable formats CycloneDX or SPDX.
2. Use automated (open source/commercial) tools and scanners that reduce the human effort required to create and maintain an SBOM. You can analyze the source code, binaries and dependencies of a software and extract metadata to generate a comprehensive list of components. For example BlackDuck, OWASP Dependency-Check or Snyk.
3. Integrate SBOM creation into the development process (CI/CD pipelines) to ensure that the SBOM is always up-to-date with every code change.
4. Check and validate the SBOM manually to ensure that the automated tools have not overlooked or incorrectly assigned any components.
5. Focus on the top level, to make it easier to get started. As experience and maturity of the process increases, other levels can also be recorded to obtain a comprehensive picture of the software components.

Monitoring the SBOM

The monitoring of SBOM includes the consideration of new vulnerabilities and the up-to-dateness of the integrated components. In vulnerability management, a documented, repetitive process of IT risk management that puts SBOM at the forefront has become established:

1. Identify vulnerabilities, check up-to-dateness and status of support
2. Evaluate possible effects in the context of the product
3. Define and implement measures and check their effectiveness

Monitoring should primarily be automated. There are numerous commercial products and services that continuously analyze and check SBOMs. One example of an open source project is OWASP Dependency Track.

There are various sources for known and documented vulnerabilities, which can be accessed via the website or programming interfaces:

1. National Vulnerability Database (NVD) of the National Institute of Standards and Technology (NIST)
2. GitHub Advisory Database
3. Sonatype OSS Index
4. Snyk Vulnerability Database
5. A distributed vulnerability database for Open Source

Please note:

• Only known information can be included in the monitoring.
• Not all information is available in machine-readable form.
• Not all vulnerabilities are recorded promptly in central databases.
• Some vulnerabilities are not recorded in central databases.

For these reasons, it makes sense to include the creators of the components as a source of information, for example.

Structure of an SBOM

(using the example of a CycloneDX JSON file)

Further information

An introduction to the topic of SBOM is provided both by the CyberMed expert group's document on the classification of SBOM for information security and the BSI's TR-03183-2 on SBOM.

The IMDRF addresses SBOM in "Principles and Practices for Medical Device Cybersecurity" and "Principles and Practices for Software Bill of Materials for Medical Device Cybersecurity", among others.

In 2022, the FDA published its official document "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions" (Sep 27, 2023), the FDA recommended attaching an SBOM to the Risk Management Report.

Use the standardized formats CycloneDX or SPDX. There are numerous tools to support the creation of SBOMs for the standards mentioned(CycloneDC Tool Center, SPDX Tools).

OWASPCycloneDX is a general format for bills of materials (BOM). It provides advanced supply chain capabilities to reduce cyber risks. The specification supports a range of BOM types (e.g. Software Bill of Materials (SBOM), Software-as-a-Service Bill of Materials (SaaSBOM, Hardware Bill of Materials (HBOM), etc.).

SPDX is an open standard for the communication of software bill of materials information, including origin, license, security and other related information. The SPDX specification is recognized as an international open standard for security, license compliance and other software supply chain artifacts as ISO/IEC 5962:2021.

See also: ISO/IEC 27001 Control 8.8 Management of technical vulnerabilities. Essentially regulated by Control 8.8 of ISO/IEC 27002:2022, as well as the Operational Capability: Threat and Vulnerability Management.