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:

Tab. 1: Differences between SOUP list and SBOM

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.

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:

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":

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.

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:

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).
 

Tab. 2: Comparison of attributes in CPE format and in Maven

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.

Support

The Johner Institute supports medical device manufacturers in meeting the legal requirements for the IT security of their devices quickly and without unnecessary effort, thus bringing safe medical devices to market.

• penetration tests
• designing the IT security development process
• seminar on IT security for medical devices