Software Bill of Materials for Advanced Medical Device Development

It’s hard to imagine the world of medical technology before computers when medical devices were tangible gadgets everyone could see and touch. Enter the computer age, which quickly led to using software in medical device development. Software innovation continues to increase with significant growth in the Software as Medical Device (SaMD) sector.

Understanding how intangible objects can be “things” is part of the modern human learning curve. We often use analogies of the physical world to help us “see” the virtual world. A typical example is calling the Internet an “information superhighway” hosting a “world wide web.”

For medical device manufacturers, one tool that is essential to their project is a software bill of materials (SBOM). At Galen Data, we provide an SBOM for all of our customers. In this post, we share more detail about what an SBOM is and why it’s essential.

Looking at the world of traditional manufacturing can help us better understand how an SBOM fits in with medical devices and SaMD project management. Let’s take a look.

What is a Software Bill of Materials (SBOM)?

When designing a tangible widget, manufacturing teams develop a bill of materials (BOM), a comprehensive list of all the raw materials and components required to manufacture a final product. This helps everyone be on the same page and helps managers plan and manage the production process efficiently.

If defects surface in a specific part, a BOM makes it easy to find that part and resolve the problem.

The software bill of materials (SBOM) serves a similar purpose in software development, especially for medical devices. The SBOM allows software users and vendors to know which software components were used in development so they can identify and fix any issues.

Similar to a traditional BOM, a software bill of materials (SBOM) is a complete and detailed inventory of all the software components that make up a product. Share on X

The SBOM provides software users visibility over what is included in a software product, facilitating communication between developers and other stakeholders

For medical device startups, especially SaMDs, understanding where the SBOM fits in the development process is crucial.

Why is a Software Bill of Materials (SBOM) Important?

In medical device development, an SBOM is essential for several reasons. Below we highlight a few.

Security

While security is important in all software projects, it’s difficult to overstate how crucial it is for advanced medical devices and SaMD development. The FDA requires companies to ensure that the device is secure and cannot be easily hacked or compromised.

Most software is created on top of other software, including open-source or commercial software components. Open-source components can be advantageous because they are free.
One challenge can be that because open source components are “open,” they may introduce security risks.

Third-party software (whether open source or commercial) facilitates rapid development and release cycles. It enables organizations to incorporate ready-made components into their application so they can quickly release software.

A SBOM provides a detailed list of all the software components used in the device, making it easier to identify and patch any existing security vulnerabilities.

The SBOM enables organizations to identify and track all third-party components, particularly open-source ones, and comply with licensing requirements. It also helps ensure the organization does not run vulnerable components and enables tracking of critical updates and patches.

Visibility

The SBOM creates visibility into the project and enables tracking of all the software components used in a medical device throughout the product life cycle.

Maintenance and Support

A SBOM helps medical device manufacturers identify which software components need to be updated or patched, helping ensure that the device remains safe and effective.

Compliance

Regulatory agencies require medical device manufacturers to document and demonstrate the safety and effectiveness of their products. A SBOM is a vital compliance document in the regulatory process.

The FDA is clear that whether a device is tangible or not, it requires the same level of testing for consumer safety and efficacy. The SBOM can help medical device companies navigate the complex waters of regulatory compliance.

Software Bill of Materials (SBOM) Standards

The US National Telecommunications and Information Administration (NTIA) sets the minimum requirements for a SBOM standard, which must include:

• Author Name—usually the organization that develops the software.
• Vendor Name—the name of the software vendor, including aliases (alternative names). The vendor and author may be different if a supplier is creating an SBOM on behalf of the vendor.
• Component Name—the name and possible aliases of the software component.
• Version String—the format of the version information is free-form but should follow common industry usage such as semantic versioning.
• Component Hash—the best way to identify a software component is to use a cryptographic hash (SHA2 or SHA3) that serves as a unique identifier.
• Unique Identifier—in addition to the hash, each component must have an ID number that identifies it within the SBOM.
• Relationship—defines the relationship between the component and the package. In most cases, the relationship is “included”, meaning that a certain component is included in a certain package.

However, FDA under their new cybersecurity guidance (draft format as of this writing) defined additional attributes that must be included in the SBOM documentation submitted as part of marketing approval applications. These are:

• Level of Support and Maintenance provided by the Vendor.
• End of Support Date
• Any Known Vulnerabilities

Two of the most popular SBOM formats, both which are compliant to NTIA guidelines, are CycloneDX and SPDX.

The Open Web Application Security Project (OWASP) sponsors CycloneDX, a software bill of materials (SBOM) that includes associated metadata and describes a set of software elements categorized as components, services, and dependencies, as well as constructs describing the connections between those elements.

The Linux Foundation maintains the Software Package Data Exchange (SPDX) project, which defines an SBOM model that comprises three components: Documents (metadata about the SBOM), Packages (groups of elements), and Files (individual files).

Both CycloneDX and SPDX are actively supported by large open-source communities. Commercial tools are also available for SBOM creation and management.

Tech Stack for Software Bill of Materials (SBOM)

There are many tools and technologies around the generation and use of SBOMs. Some open-source and free tools are available to generate SBOMs in different formats include:

1. Maven – CycloneDX plugin, SPDX plugin
2. Gradle – CycloneDX plugin
3. NPM – CycloneDX plugin
4. Microsoft SBOM Tool
5. Mend SBOM Generator

Once you have an SBOM, there are a variety of tools that can provide insights into dependencies like vulnerabilities and license insight. Some of these tools include:

1. Grype
2. FOSSA
3. Mend SCA
4. Vigilant Ops
5. Helm by MedCrypt

Moving Ahead with SBOM for Medical Device Development

By providing a comprehensive inventory of software and its dependencies, SBOM enables better tracking, management, and mitigation of vulnerabilities in medical device development. Do you have questions about a SBOM for your project? We can help you with that. Reach out today to get the conversation started.