How to generate an SBOM (Software Bill of Materials) fast

What is an SBOM?

A software bill of materials (SBOM) derives from the traditional use of a bill of materials (BOM) in manufacturing, which catalogs the raw materials and components of a product. An SBOM is a complete list of all the software components used in a product, including commercial off-the-shelf (COTS) and open-source components.

As software becomes increasingly integral to the operation of medical devices, regulatory agencies such as the FDA have recognized the need for transparency and traceability in the software supply chain. An SBOM is a key part of meeting these needs. Creating and maintaining an SBOM presents challenges because of the inherent amount of change in software and the huge number of dependencies modern software products use. 

Who needs an SBOM?

Any organization involved in the development and distribution of software, especially in industries with regulatory oversight, can benefit from having an SBOM. However, medical device software manufacturers have a critical need for SBOMs due to the stringent regulations and safety requirements imposed by regulatory agencies such as the FDA. 

The latest FDA guidance on cybersecurity in medical devices states that software manufacturers and other regulated organizations need an SBOM to meet regulatory requirements, ensure software transparency, and manage risks effectively. As of October 1, 2023, manufacturers’ submissions can be rejected by the FDA if an SBOM and a plan to monitor and respond to vulnerabilities is not included. By following a step-by-step guide and using SBOM generators or tools, organizations can streamline the SBOM generation process and improve the overall security and compliance of their software products.

When to create a software bill of materials (SBOM)

You should incorporate SBOM generation as a standard practice throughout the entire software development lifecycle to ensure that the SBOM remains comprehensive, accurate, and aligned with the software being developed. Creating an SBOM early in the lifecycle allows better tracking and documentation of software components as they are integrated into the product. It also enables your team to incorporate SBOM generation into your organization's development workflows, making it a seamless part of the overall software development process. 

Waiting to create an SBOM until later stages of development makes it difficult to identify all of the used components and their versions, especially if the development process has frequent updates or changes. Additionally, delays in creating the SBOM can impede compliance with regulatory requirements, as well as hinder vulnerability management and risk assessment processes, by providing an incomplete overview of the project. This issue can harm product reliability, company reputation, and patient safety. 

Are there open-source SBOM generators & SBOM Tools?

Yes, there are SBOM generators and tools available that can assist in the creation and management of the software bill of materials (SBOMs). However, while many of these tools claim to automate the SBOM management process, the truth is that there is still a large amount of manual intervention and configuration that falls on the development and compliance teams who use them. Other issues include non-standardized documentation and continued difficulty in tracking changes over the entire lifecycle. This last point cannot be overstated enough as each update to any component in the SBOM requires attention.

It's important to note that the availability and features of specific tools may vary. It's recommended to explore and evaluate different options based on your organization's specific needs and requirements. 

Step by Step instructions to Create an SBOM and What’s Included 

Medical device software manufacturers consistently lose time, and developers, adhering to cybersecurity-related documentation requirements. Why lose developers? Because this task is extremely tedious, time-consuming, and boring.  

To underscore this point, let’s take a look at the traditional steps to generate an SBOM for medical device software.

A typical SBOM cycle looks like this: 

1. Proprietary, open-source software and other third-party components must be documented and updated with even small changes to any component. 

How it's done: Development teams track down each component in their system and prepare for compilation into an SBOM. 

2. Create a list of components: Once all components are identified, software teams compile the list into a traditional SBOM. Information must include the Component name, version number, software manufacturer, level of support provided by the software manufacturer, the end-of-support date, and any known vulnerabilities.

How it's done: Traditionally, developer teams achieve this task by manually copying and pasting into Excel spreadsheets or a siloed documentation tool. This back-and-forth opens up the potential for human error misalignment between documentation and code base. Teams must constantly communicate to catch any changes or vulnerabilities and change details manually. This manual documentation means developers are spending their time updating documents and not using their skills to develop and improve a product.

3. Determine dependencies: The next step is to determine the dependencies between the components by identifying which components rely on others to function properly. This information can help identify potential vulnerabilities and ensure that all components are properly updated.

How it's done: Teams manually import their dependencies into their traceability matrix creating yet another opportunity for misalignment between documentation and codebase.

4. Verify component licenses: The licenses of each software component need to be verified to ensure compliance with regulatory requirements. This process may involve reviewing the license agreements and terms of use for each component to ensure that they are compatible with the intended use of the medical device. 

How it's done: Teams go through and verify each component (which could be thousands depending on complexity) one by one. Unfortunately, this is not a one time task; teams need to monitor and re-verify throughout the product lifecycle.

5. Document and maintain the SBOM: Documenting and maintaining your SBOM over time is a long-term stressor for software development teams. This process traditionally includes tracking any changes to the software components or their dependencies, as well as manually updating the SBOM documentation (whether in a spreadsheet or documentation tool) to reflect any new versions, releases, or modifications.

How it's done: The demand to update the SBOM after each small change piles up on the development team, and, at some point, human error occurs, leaving your SBOM out of compliance with FDA requirements. Even worse, teams will retroactively go back and update their SBOMs after a release, which creates extra work and exposes the patient to potential risk and the company to financial and reputational damage.

6. Monitor Vulnerabilities: New vulnerabilities are constantly being identified. Per the FDA’s cybersecurity guidance, organizations must have a plan to monitor and address new vulnerabilities in their constantly updating list of used dependencies.

How it's done: Personnel in the organization may manually monitor the dependencies contained in the SBOM, which they are manually updating, for new vulnerabilities. When new vulnerabilities are identified, the information related to them, such as the criticality, needs to be documented. Then, personnel need to assess where the dependency is used and the risk the vulnerability presents to their software. After this, a plan may be communicated to address the vulnerability and control its impact on the product.

Ketryx generates SBOMs in seconds

Watch the quick video or view the step-by-step instructions below.

Ketryx enables organizations to create an FDA-compliant SBOM in seconds and easily manage it over the course of the product life cycle.

How it’s done:

Step 1: Open your Ketryx Project dashboard.

Step 2. Select “Create Project” in the left menu and copy your Git Repository URL into the designated box. 

Step 3. Watch your updated SBOM generate in seconds, along with much of the FDA required metadata for each item. Now you can easily assign different levels of concern to each component, sort the list, and easily monitor it for vulnerabilities and updates. 

Step 4. Assign risk-levels for each dependency and enter in FDA-required information. When you're on the dedicated dependency page, you'll be empowered to:

1. Connect each dependency to specific risks they introduce and test cases that risk-control them.

2. Connect dependencies to items in your software design, such as requirements and specifications

3. Effectively manage the essential FDA-required compliance metadata, encompassing factors like:

     a. Level of Concern

     b. Intended Use

     c. Security Impact

     d. Reliability Impact

If you’re ready to learn about Ketryx Open Supply Chain and our truly automated SBOM tool that leverages AI/ML, try it here.

Continuing exploring the topic of SBOMs and the newest FDA requirements with Ketryx’s blog post “The FDA drops a cybersecurity compliance SBOM in 2023.” 

Learn more about design traceability with our blog posts “The Ultimate Guide to Requirements Traceability Matrix (RTM)” and “FDA Traceability Matrix Requirements for Medical Devices.”