Medical Device SBOMs: Best Practices, FAQs, and Examples

Introduction 🔗

The FDA is increasingly focused on cybersecurity. Many medical-device manufacturers must now generate a Software Bill of Materials (SBOM) for each release of your device software. This document describes best practices, answers frequently asked questions, and gives examples of related to SBOMs. It is focused on the US market, although content may be relevant to other jurisdictions.

I’d like to thank Om Mahida from Medcrypt (the creators of the Helm SBOM Management and Vulnerability Monitoring tool) for reviewing this document and providing his experiences from working directly with medtech and healthcare on their SBOMs for over 5 years.

Best Practices 🔗

Here is a short list of best-practices for creating SBOMs.

• Automate the generation of your SBOM, e.g., by including its generation in your CI/CD pipeline and storing it as a build artifact.
• Include metadata about your software in the SBOM, in addition to including at least:
  • The name of your company, including your company website and a contact.
  • The git hash of the source code used to generate the file.
  • The timestamp when the SBOM was generated.
  • A short description of the component.
• Include all the fields from Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM) in your SBOM.
• Use a tool to continuously monitor for vulnerabilities in the SBOM for all devices in the field.
• Include both a human-readable and machine-readable version of your SBOMs in your regulatory submissions.
• Have a process for periodically reviewing the identified vulnerabilities and systematically evaluating their risk to patient safety.

Basics 🔗

What is an SBOM? 🔗

An SBOM, or Software Bill of Materials, is a comprehensive list of components, libraries, and dependencies used in a software system.

What is the purpose of an SBOM? 🔗

SBOMs provide transparency about the software's composition, making it easier to track and manage potential security vulnerabilities, licensing requirements, and other risks associated with software usage. An SBOM can include information about open-source and commercial components, as well as their respective versions and licensing information.

Do we need to include an SBOM in our pre-market submission? 🔗

If you’re marketing your device in the United States and your device contains software, then most likely you need to include an SBOM in your 510(k), De Novo, or PMA submission.

The FDA guidance recommends that you include an SBOM for all devices.

If your medical-device meets the regulatory definition of a “cyber device”, then you must include an SBOM. In general, a “cyber device” is one that has the ability to connect to the internet and has “any such technological characteristics … that could be vulnerable to cybersecurity threats”. If your device contains software and has any external ports (even USB ports), the FDA will almost certainly consider it a “cyber device.”

Do we need to distribute SBOMs to our customers? 🔗

The FDA regulations do not explicitly require that you distribute an SBOM, although your customers will likely request it. The FDA guidance does suggest that it be made available:

Manufacturers should provide or make available SBOM information to users on a continuous basis. If an online portal is used, manufacturers should ensure that users have up-to-date links that contain accurate information. The SBOM should be in a machine-readable format.

Does the FDA specify a particular SBOM format? 🔗

No. FDA does not specify a particular SBOM format. They do, however, require that whatever format you use include the “Baseline Attributes” from Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM), which was published in October 2021.

They also require a couple of additional fields. See the later questions for more details.

How often do we need to update our SBOM? 🔗

FDA expects that the SBOM be updated as the software is updated. Thus, you must create a new SBOM for each release of the software, especially if the versions of the software components have changed since the last release.

Should we create an SBOM early in our development process? 🔗

In our experience, many medical-device manufacturers don’t produce an SBOM until it is needed for their first FDA submission. This is a missed opportunity. Since we suggest automating your SBOM-generation, you may as well set this up early in the process. Once you have your SBOM, you can begin scanning it for vulnerabilities during development. This ensures that if there are any unsupported, outdated dependencies with unfixed vulnerabilities, you’ll catch them early in the development process.

Here’s a scenario I’ve run into several times:

• A junior engineer adds “Poorly Supported Package v0.3.5” to a project.
• This package depends on other widely used and out-dated libraries.
• A company waits until their 510(k), and generates an SBOM.
• They start writing their Security Assessment of Unresolved Anomalies and they realize there is a bad vulnerability they can’t ship.
• You now need to do one of the following:
  • Fork and update “Poorly Supported Package v0.3.5”
  • Rip out “Poorly Supported Package v0.3.5”
  • Bend yourself in circles trying to mitigate the vulnerability

All of this could have been avoided if you set up SBOM generation and vulnerability monitoring earlier in the development process and integrated it into your development process. This is why the FDA has gotten increasingly focused on using a “Secure Product Development Framework” in their guidance.

Do you need OTS Software Documentation for every item on your SBOM? 🔗

No, not typically. See our Off-The-Shelf Software: Best Practices, FAQs, and Examples document for much more details on this topic.

What is a CBOM? 🔗

CBOM stands for Cybersecurity Bill of Materials. The FDA introduced this term in their 2018 draft guidance, but in they switched to the more standard SBOM term in their 2023 final guidance. You may see this term used in older articles.

Do you have any other resources for learning about SBOMs? 🔗

Yes! Here are a few more good reads:

1. How-To Guide for SBOM Generation
2. 2023 IMDR Guidance “Principles and Practices for Software Bill of Materials for Medical Device Cybersecurity”
3. Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM)
4. 2021 Software Identification Challenges and Guidance
5. 2021 Survey of Existing SBOM Formats and Standards
6. 2024 Data Normalization Challenges and Mitigations in SBOM Processing

Generating an SBOM 🔗

How do we create an SBOM? 🔗

The basic process involves these steps:

1. Select an SBOM file-format.
2. Identify the third-party components, libraries, and dependencies used in your software.
3. Gather the information needed to fill in the required attributes for your SBOM format (ideally automatically, using a tool).
4. Insert the information into your SBOM file (ideally automatically).
5. Validate your SBOM file.

We suggest automating the process and incorporating it into your CI/CD pipeline.

Usually some components are not tracked anywhere else and need to be manually added.

What SBOM file format should we use? 🔗

There are two widely-used SBOM formats:

• CycloneDX
• SPDX

We recommend the CycloneDX format. It has good tooling support and it’s specification is short and more developer friendly. (Compare it to the SPDX specification.) The CycloneDX format is focused on security use-cases while the SPDX historically focused on open-source license tracking.

That said, some tools (e.g., GitHub) produce SPDX files, and it is also industry standard. Future updates to the SPDX standard are likely to bring it closer to the CycloneDx standard.

If you’d like a more in-depth comparison of the formats, the 2021 Survey of Existing SBOM Formats and Standards is a good read.

(Note that most people aren’t really using the SWID format anymore.)

What Information do we need to include for each component in our SBOM? 🔗

FDA requires your SBOM to address the “Baseline Attributes” from Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM), which was published in October 2021. They also require a couple of additional fields. We’ve collected all of this information into the following table for your convenience:

*These last two items are not mentioned in the NTIA SBOM document, but are requested by FDA. They may be included in a separate document.

How do you handle level of support or the end of support date for open source packages? 🔗

The easy approach is to say “N/A open-source software”. FDA has often not questioned this approach.

It isn’t always true, however, that open-source software doesn’t have explicit levels of support and end of support dates for particular versions. If you go through the open-source packages one-by-one, you can look up the relevant EOS and level of support details. See the examples for a more robust approach to gathering this information.

Can we upload a machine-readable SBOM in our regulatory submissions? 🔗

Yes, the FDA’s new eSTAR format allows for machine-readable attachments. However, as of 2023, the FDA has been asking for human-readable (e.g., a PDF or Excel file) versions of the SBOM as well. JSON doesn’t cut it.

If you only have a human-readable SBOM, then a machine-readable format is not required (a Lead Cybersecurity Specialist at FDA said this in a talk I attended in February 2024).

How do you create a human-readable SBOM? 🔗

We have some open-source python scripts that we maintain to help us do this.

What components should be included in our SBOM? 🔗

This is a difficult question, as there are several layers of components that could in theory be included. Here is a list of types of components that could be included in an SBOM, starting with the most basic to the most comprehensive:

1. Language-level dependencies (e.g., Tensorflow v2.9.1)
2. Dependencies of your language dependencies (e.g., if package A depends on package B, be sure to include package B too.)
3. System dependencies (e.g., Python v3.10.3)
4. The operating system
5. External cloud services
6. Compilers

Hypothetically, one should include all of these dependencies in a very robust SBOM. However, keeping up with all of these dependencies takes a lot of effort. Furthermore, as you go down the list the value of including the components decreases. Thus, given limited resources we suggest focusing on dependencies that are higher risk. This typically means at least levels (1) and (2), and ideally levels (3) and (4) also. We don’t typically include levels (5) and (6).

FDA does say in their guidance that “upstream software dependencies that are required/depended upon by proprietary, purchased/licensed, and open-source software” must be included. I interpret this to mean (1), (2), (3), and (4).

Why not include external cloud services (e.g., AWS S3) in the SBOM? 🔗

You certainly can include them. However, the purpose of the SBOM is to enable you to track and upgrade dependencies. Therefore, if there is no way to upgrade the dependency, then it’s not nearly as useful to track vulnerabilities in the tool using your SBOM.

For example, imagine if you were to add AWS S3 to your SBOM. You then receive a vulnerability alert for it. It is reasonable to think that AWS will be fixing the issue and upgrading their service as quickly as they can anyway. In the mean time, there’s nothing you could do.

The main counter argument to this is that at least you would know there is a vulnerability and you could turn off your service or switch to another provider temporarily. Practically, I don’t think this would be useful in most cases.

Is it okay to have multiple SBOMs? 🔗

FDA appears to expect a single SBOM. Note that you can merge SBOMs together using tools such as cyclonedx-cli. Consider using a hierarchical merge when appropriate.

Should we automate the generation of our SBOM? 🔗

Yes, we suggest that you automate the generation of your SBOM, especially if your software has more than a handful of dependencies. For example, most software that’s built using a container solution such as Docker will have hundreds or thousands of components. Updating this by hand isn’t really feasible.

Furthermore, FDA requires most manufacturers to provide periodic security updates to their software. Automating your SBOM generation will help you keep your SBOM up to date as you release. Your engineers will likely not want to generate an SBOM by hand.

We suggest generating your SBOM as a build artifact in your continuous integration pipeline.

One downside to automatically generating an SBOM is that you may give up some control over what components are included. For example, if you combine all of your development dependencies and production dependencies into a single requirements.txt file for a Python project, then your SBOM may include your development dependencies. As a result, when you or your customers scan the SBOM for vulnerabilities, you’ll have false positives that you need to address.

If you generate an SBOM automatically, you at least want to have some mechanism for black listing the inclusion of irrelevant components so that you can (over time) reduce false positive vulnerabilities.

How do you automate the generation of an SBOM? 🔗

There is a growing suite of tools you can use to automate your SBOM generation process.

GitHub supports generating SBOMs automatically.

Amazon Inspect can produce SBOMs from EC2 and Lambda instances.

Tools like Syft or docker scout can generate SBOMs from container images or filesystems. (Here’s an article about generating SBOM’s as part of your Docker build.)

We haven’t used them ourselves, but one of our clients had good things to say about Ketryx.

There are also “lower-level” tools that operate on a language-level. For example, if you have Python language dependencies, you can import them from your requirements.txt file.

How do you automatically generate an SBOM for a docker container? 🔗

Here’s some example bash commands showing how to create an SBOM for two docker images and to then combine them into a human-readable SBOM for an FDA submission.

Note you’ll need docker installed as well as our open-source python script.

docker load -i my-docker-image1_v1.0.0.tar
docker load -i my-docker-image2_v1.0.0.tar
mkdir child-sboms
docker sbom my-docker-image1:v1.0.0 --format spdx-json > child-sboms/sbom1.json
docker sbom my-docker-image2:v1.0.0 --format spdx-json > child-sboms/sbom2.json
python gen_sbom.py child-sboms sbom.xlsx

Distributing SBOMs 🔗

Does the FDA suggest how SBOMs are distributed? 🔗

The only details the FDA provides regarding the distribution of SBOMs are found in the 2023 Cybersecurity Guidance:

Manufacturers should provide or make available SBOM information to users on a continuous basis. If an online portal is used, manufacturers should ensure that users have up-to-date links that contain accurate information. The SBOM should be in a machine-readable format.

How are SBOMs usually distributed? 🔗

This is an unsolved problem and there are several alternative ways to distribute SBOMs. We suspect in a few years a standard approach will be settled upon.

Here is a nice table of alternative approaches, taken from the IMDRF Draft SBOM Guidance:

How do you recommend we distribute our SBOM? 🔗

For early stage startups with limited resources, we recommend starting with a very simple approach: Maintain all of your SBOMs for each version of your software in a “Manufacturer-managed Repository”. (E.g., these can be release artifacts stored in GitHub with your built system images.) Then, include an email address in your user manual where manufacturers can request the SBOM for a particular version of the software. We’d then react to customer or FDA feedback before adopting a more complex distribution method.

For example, FDA pushed back on this approach (August 2024) for one of our submissions, stating:

An SBOM in a machine-readable format for users to effectively manage their assets, to understand the potential impact of identified vulnerabilities to the medical device system, and to deploy countermeasures to maintain the device’s safety and effectiveness. While we acknowledge you have stated a user is able to request the SBOM via email, this documentation should be readily available to the end user at all times. Please provide the SBOM to the end user as part of the device system labeling.

If you’re more risk averse, then you can adopt a more complex distribution approach out of the box.

Vulnerability Monitoring 🔗

Do we need to do monitor our SBOM for vulnerabilities? 🔗

Yes, you must

design, develop, and maintain processes and procedures to provide a reasonable assurance that the device and related systems are cybersecure, and make available postmarket updates and patches to the device and related systems to address—(A) on a reasonably justified regular cycle, known unacceptable vulnerabilities; and (B) as soon as possible out of cycle, critical vulnerabilities that could cause uncontrolled risks.

Thus, you need some mechanism to scan your SBOM for known vulnerabilities.

What are good tools for finding vulnerabilities using an SBOM? 🔗

GitHub’s Dependabot may be used in certain cases, although as of April 2023 it only supports certain package ecosystems.

Open-source tools include Dependency Track and Trivy.

Black Duck and Snyk are good paid options to consider.

Will the FDA scan our SBOM? 🔗

We haven’t seen any evidence of the FDA doing this, but it wouldn’t surprise us if they start doing this. The FDA does expect that you have evaluated the safety risk associated with any known vulnerabilities. One approach is to list the known vulnerabilities alongside your Unresolved Software Anomalies.

Will our customers scan our SBOM? 🔗

It is increasingly likely that sophisticated HDOs will rely on SBOMs as well as independent vulnerability scanners to identify vulnerabilities in their medical devices.

Thus, you need to be careful to not include packages (e.g., development dependencies) in your SBOM which will cause unnecessary false alarms.

Is it acceptable to monitor vulnerabilities independently from our SBOM? 🔗

Yes, we believe it is acceptable to monitor cybersecurity vulnerabilities in your dependencies using a mechanism apart from the SBOM. For example, if your SBOM is generated from your requirements.txt, and a vulnerability monitoring tool monitors the requirements file directly, that should be fine. FDA seems to recognize this [emphasis added]:

Because vulnerability management is a critical part of a device’s security risk management processes, an SBOM or an equivalent capability should be maintained as part of the device’s configuration management, be regularly updated to reflect any changes to the software in marketed devices

Examples 🔗

The following examples show how to handle some common situations with SBOM generation when using CycloneDX. Note that the examples are not valid standalone SBOMs since they do not include some mandatory metadata, such as the bomFormat, speVersion, or version.

Your Device 🔗

It’s helpful to include the name and version of your medical device software in the SBOM metadata so that it’s easy to identify which version of your software the SBOM applies to. This information goes inside the metadata.component field. See here for details. Here’s an example that includes other metadata suggested by the NTIA:

{
  "metadata": {
		"timestamp": "2060-06-09T00:33:20+0000",
    "authors": {
			"name": "Medical Device Manufacturer Name",
			"url": "https://yourwebsite.com"
		},
    "supplier": {
			"name": "Medical Device Manufacturer Name"
			"url": "https://yourwebsite.com"
		},
    "component": {
      "type": "application",
      "name": "Medical Device Name",
			"author": "Medical Device Manufacturer Name",
      "version": "1.0.5"
    }
  },
}

The 2013 Visual C++ Redistributable Package 🔗

The Visual C++ Redistributable Package is not included in any of the purl types, so we searched the CPE database for it. We found match for the Visual Studio 2017 runtime, but the 2013 runtime was not present. Thus, we copied the CPE identifier for the 2017 runtime and updated the year number as a best guess attempt at identifying this dependency. The “name” field is a best guess based on the CPE string. The “type” is set to “library” despite the fact that the CPE identifier begins with “a” (for application). This is because the runtime isn’t really an application.

{
  "components": [
    {
	    "type": "library",
	    "name": "visual_studio",
	    "cpe": "cpe:2.3:a:microsoft:visual_studio:2013:-:*:*:*:*:*:*"
    }
  ]
}

Python 🔗

None of the purl package types apply to Python itself, thus the CPE identifier was used. A few searches of the CPE database turned up a match. This can be included as a CycloneDX component as follows:

{
  "components": [
    {
	    "type": "application",
	    "name": "python",
	    "cpe": "cpe:/a:python:python:3.6"
    }
  ]
}

Documentation Supporting Software Bill of Materials 🔗

The following content would go in a separate document, in addition to the SBOM, to provide the EOL and Level of Support items as required by FDA’s guidance.

Below we outline EOL and support levels for the major software components used to implement the system items described in DOC-0023 System and Software Architecture Diagram. Note that most open source software do not typically advertise an end-of-life date for each version or for most versions. Instead, major deprecations are only typically published when a piece of open-source piece of software is widely used and undergoing a major version change.

For any item in the DOC-0025 Software Bill of Materials but not in the above table, the following applies:

• The EOL is indeterminate (e.g. most open-source software does not adhere to a known EOL schedule)
• The level-of-support is not guaranteed and/or undocumented (e.g. most open-source software does not offer paid support and support might only come from the open-source community, not official team members)

Revision History 🔗