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.
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.
a formal record containing details and supply chain relationships of components included in the software elements of a product with digital elements;
EU Cyber Resilience Act, Article 3, Section 37
SBOMs map the hierarchy of components of which software items are made up.
The SBOM and the list of SOUPs used are not identical:
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.
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:
SBOMs are intended to serve manufacturers as well as their customers (e.g., software operators) and the supervisory authorities or notified bodies.
The manufacturers pursue several objectives with the SBOMs:
Authorities and notified bodies must ensure that manufacturers meet the regulatory requirements.
Both of these factors help authorities and notified bodies to meet their own regulatory requirements.
The FDA explicitly requires SBOMs. In other areas of law, SBOMs are essential because they are state of the art, and other legal obligations cannot be met without them.
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 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.
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).
The US government's Executive Order 14028 requires suppliers to US government agencies to include a Software Bill of Materials.
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.”
The SBOM is therefore not only expected as a document but is also linked to a purpose (publication to the operator).
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.
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 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
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).
package manager (Maven)
manufacturer or namespace
name of the component
version of the component
Tab. 2: Comparison of attributes in CPE format and in Maven
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.
It is up to the manufacturers to decide whether to add this information manually or to restrict themselves to the established formats as the state of the art.
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.
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.
We also recommend plugins that automatically analyze and visually display the dependencies of libraries and packages. One example is Oracle's JDeps for Java.
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.
There are countless commercial and free tools available. A search for "sbom vulnerability check," for example, supplemented by "open source" if necessary, will bring relevant hits to light.
Manufacturers should carry out a run at least once a week or be informed in real-time with push notifications if vulnerabilities are found above a specified CVSS value.
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.
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.