SBOM: Software Bill of Materials

Laws and standards require medical device manufacturers to compile a Software Bill of Materials, the SBOM. However, standardized SBOM formats are not always sufficient to meet these requirements.

In particular, medical device manufacturers who do not supply and use SBOMs for their software are no longer accepted in the market. Here are the reasons.

1. SBOM: The basics

a) What is a “Software Bill of Materials”?

Definition of the term “SBOM”

The “Software Bill of Materials” (SBOM) is a nested list of software items that make up a software system. Manufacturers use this inventory list to make transparent which clearly identifiable components in which versions make up their software items.

SBOMs map the hierarchy of components of which software items are made up.

Differentiation of SBOM from the SOUP list

The SBOM and the list of SOUPs used are not identical:

SOUP	SBOM
The SOUP “only” lists the software items contained in the medical device itself.	The SBOM may also contain system components around the medical device on which the device is dependent.
A SOUP is a software item that has not been developed under IEC 62304.	The SBOM does not distinguish this.
Self-developed software items that are part of the medical device but were not developed under IEC 62304 also count as SOUP.	The SBOM does not differentiate between types of self-developed software.
The SOUP list is generally a “flat list”.	The SBOM can contain the hierarchy of components.
As part of the technical documentation, a SOUP list is usually an independent document or part of it (e.g., part of the software architecture).	SBOMs are machine-readable.
As part of the technical documentation, the SOUP list is an internal document.	The SBOM is made available to operators (healthcare providers such as hospitals).
The SOUP list contains the attributes required for each entry to identify the respective SOUP component.	The entries of an SBOM have more attributes than the elements of a SOUP list. Examples are HASH/signature, link to the host component, globally unique ID, etc.

Conclusion: Both SOUPs in IEC 62304 and SBOMs are used for the identification and management of software components. However, they originate from different contexts and serve different purposes:

• The SOUP is a concept that is specific to medical device software, particularly in the context of ensuring the safety and effectiveness of that software.
• The concept of SBOM is broader and is used in various industries to manage software supply chains and improve cybersecurity by creating transparency about the software items used in a system.

b) What are the objectives of SBOMs?

SBOMs are intended to serve manufacturers as well as their customers (e.g., software operators) and the supervisory authorities or notified bodies.

Objectives of the manufacturers

The manufacturers pursue several objectives with the SBOMs:

• They fulfill their regulatory requirements (more on this below).
• The license terms of open-source software include the obligation to disclose that this open-source software is part of the device.
• Manufacturers must quickly find vulnerabilities in the components used – e.g., by checking them against the NIST database – and fix them. This requires them to know exactly which components their device contains. The SBOM makes it possible to automate this vulnerability analysis.
• This knowledge also helps with risk analysis, especially FMEA. This is because this analysis method starts with the assumption that the components of a device are faulty.
• Manufacturers must also continue this analysis in the post-market phase, especially as part of post-market surveillance.
• During development, it is important to know (and define) which components are used in which versions. Version conflicts and redundant components regularly cause the software to misbehave and make troubleshooting more difficult. The SBOM thus becomes part of the configuration management.
• Finally, the SBOM can be part of supplier management. It links the components with the suppliers and the requirements for their processes and devices (the components). It facilitates communication between manufacturer and supplier by uniquely identifying the components and assigning them to the respective supplier.

Objectives of the operators

• Operators can use the SBOM to determine whether they are affected by a security vulnerability, which they must report to the manufacturer or a “vulnerability database” and, if necessary, eliminate themselves.
• During installation, SBOMs are useful for recognizing and avoiding version conflicts between components. Such disputes occur, for example, when an operator installs several devices (from several manufacturers) on one platform.

Objectives of the authorities and notified bodies

Authorities and notified bodies must ensure that manufacturers meet the regulatory requirements.

• If a manufacturer can present an SBOM, this is an indication of conformity.
• If the manufacturer also plausibly demonstrates how it creates the SBOM (automatically), this also indicates that it knows its system and has configuration management under control.

Both of these factors help authorities and notified bodies to meet their own regulatory requirements.

2. Regulatory requirements

a) EU requirements

Specific requirements for medical devices

Annex I, Section 17.2 of the MDR and, by analogy, the IVDR do not require SBOMs, but “only” IT security in accordance with the state of the art. But SBOMs are state of the art.

The MDCG 2019-16 rev. 1 also does not explicitly require the use of SBOMs. However, it does require vulnerability monitoring.

“This may include the infield monitoring of the software’s vulnerabilities and the possibility to perform a device update (outside the context of a field safety corrective action) through, for example delivering patches to ensure the continued security of the device.”

MDCG 2019-16 rev. 1

Without SBOM, it is difficult to automate this process and implement it in a meaningful way.

Even IEC 81001-5-1, the future harmonized standard, does not explicitly require SBOM. But it says:

“The software bill of material (SBOM) is a documentation that tracks all incorporated software.”

IEC 81001-5-1, note in E.2.4

IEC TR 60601-4-5 addresses the requirements for medical electrical systems and is also explicitly applicable to software as a medical device. This standard describes the “Security Bill of Material”:

“A SECURITY concept related cyber SECURITY Bill of Material including but not limited to a list of commercial, open source, and off-the-shelf software and hardware components. The list should enable the target groups to effectively manage their ASSETS, to understand the potential impact of identified vulnerabilities to the MEDICAL DEVICE (and the connected  IT-NETWORK), and to deploy COUNTERMEASURES to maintain the ESSENTIAL FUNCTION of the MEDICAL DEVICE.”

IEC TR 60601-4-5

The interpretation of the notified bodies is still cautious. Neither the position paper of the IG-NB nor the position paper of the TEAM-NB mentions the SBOM.

Requirements for all devices

The Cyber Resilience Act does exclude medical devices because they already follow vertical legislation. Nevertheless, it is interesting that this law refers to the “software bill of materials” (SBOM) in 13 passages.

Manufacturers of the products with digital elements shall: (1) identify and document vulnerabilities and components contained in the product, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the product;

Cyber Resilience Act, Annex I, Section 2

In order to make the implementation of the previously unpublished law more practicable, the BSI has issued Technical Guideline TR03183. Part TR03183-2 is entitled “Software Bill of Materials (SBOM)” and formulates the corresponding requirements. These can be understood as the generally applicable state of the art.

b) FDA requirements

While in Europe, the requirements for an SBOM are usually not explicitly formulated, the FDA has long insisted on a “Cybersecurity Bill of Materials,” which also included hardware.

With the Omnibus Act at the national level, the SBOM finally became legally binding and is now also required in the current final cybersecurity document.

It refers to the specifications of the National Telecommunications and Information Administration (NTIA). These also specify the contents of the SBOMs (baseline and options). The FDA requires basic attributes (“baseline attributes,” source: page 17 of this document).

c) Requirements in other markets

There is also an explicit requirement for SBOMs in other markets.

These include the IMDRF’s “Principles and Practices” on cybersecurity and a related guidance document.

China has published dedicated cybersecurity guidelines for medical devices. These include the Guidelines for the Review of Medical Device Cybersecurity Registration (revised 2022). They name the SBOM:

“16. Off-the-shelf software list (SBOM): The ability of the product to provide the user with a full list of off-the-shelf software.”

Guidelines for the Review of Medical Device Cybersecurity Registration (no. 7, 2022)

The SBOM is therefore not only expected as a document but is also linked to a purpose (publication to the operator).

3. SBOM: Standardized formats

a) Overview of formats

SPDX und CyclonDX

SPDX and CyclonDX are established SBOM formats. These formats define the document format (JSON, XML) but do not uniquely identify the software items. Instead, they benefit from other formats, such as CPE, PURE, or SWID (see Fig. 2), as well as checksums or hashes.

The attributes of all these formats partially overlap.

Converters allow the conversion of SPDX files into CycloneDX files and vice versa.

As shown above, other standards, such as CPE, PURL, and SWID, can be used to identify software items uniquely. The first two are particularly relevant.

CPE

NIST maintains a list of components in the Common Platform Enumeration (CPE).

NIST also compiles the list of “Common Vulnerabilities.” The CPE and CVE (Common Vulnerability Enumeration) formats, as well as CVSS, are part of the Security Content Automation Protocol (SCAP).

PURL

PURL pursues a decentralized approach. Here, the manufacturer assigns the attributes themselves. This is similar to Maven’s approach with the GAV parameters. GAV stands for

• group-ID (e.g., org.apache.commons),
• artifact-ID (e.g., commons-math), and
• version (e.g., 2.0).

In contrast to CPE, the artifacts or components can be represented more granularly. For example, PURL distinguishes between log4j-core and log4-api in Log4j, whereas CPE does not (see Tab. 2).

attribute	CPE	package manager (Maven)
manufacturer or namespace	apache	org.apache.logging.log4j
name of the component	log4j	log4j-core
version of the component	2.0	2.0

b) Fulfillment of regulatory requirements through the formats

Unfortunately, the attributes in the standard formats are not defined completely enough to meet all legal requirements. For example, IEC 81001-5-1 distinguishes between the status “maintained,” “supported,” or “required” for components. This status is not an attribute of the standard formats.

The FDA has the strictest requirements (“baseline attributes,” page 17 of this document). These correspond to the requirements of the US National Telecommunications and Information Administration (NTIA) and are covered by the above-mentioned formats.

4. Working with SBOMs

a) Automatic generation of SBOMs

Manufacturers should generate an SBOM automatically and as part of their CI/CD pipeline. Plugins such as the CycloneDX Maven plugin or the npm meta package “CycloneDX BOM” are suitable for this purpose. Microsoft has published an “sbom-tool” on GitHub.

The OWSAP tool list is also helpful.

b) SBOMs in the automatic detection of vulnerabilities

A major benefit of SBOMs is the automated identification of vulnerabilities in software devices that are used or have been manufactured.

To this end, tools automatically and regularly compare the software items listed in the SBOM with the vulnerabilities published in the NIST database, for example.

5. Summary and conclusion

Delivering software without an SBOM is not in line with the state of the art. In the USA, it is a statutory requirement.

There are numerous tools for creating the software bill of materials and automatically comparing it with vulnerability databases.

Medical device manufacturers, in particular, must fulfill their responsibility for the IT security and safety of their devices.

For these reasons, there is no longer any justification for not working with SBOMs.