I have not seriously dived into the topic of software bill of materials (SBOMs) in this monthly column for several reasons. First, there are numerous SBOM discussions and presentations across the internet. Second, since this is a highly technical topic, it requires more space and graphics than this column permits. However, I am going to provide some background and helpful tips for working with SBOMs.

Under the expert guidance of Allan Friedman, the National Telecommunications and Information Administration (NTIA)—a bureau within the U.S. Department of Commerce—has been a driving force behind the development and promotion of SBOMs. In 2018, NTIA convened a multi-stakeholder process, bringing together industry, government, and academia representatives to define a machine-readable SBOM standard and its core elements. This collaborative effort aimed to establish a common understanding and approach to software transparency, laying the groundwork for widespread SBOM adoption we have today.

The NTIA multi-stakeholder group consisted of diverse participants, including software producers, consumers, and cybersecurity experts (myself included). Through a multi-year series of working group meetings, the collective worked to define the essential concepts and components of an SBOM, such as the software components, their versions, and their dependency relationships. With some changes including Allan Friedman’s new job with the Cybersecurity & Infrastructure Security Agency (CISA), the group migrated to CISA where it remains today.

The goal was to create a structured and machine-readable format that would enable consumers to easily understand the software components that make up a product or system, and facilitate better risk management and vulnerability detection. This resulted in an SBOM standard that specifies a machine-readable format, such as CycloneDX (OWASP standard, ECMA standard, and soon to be an ISO standard) or SPDX (ISO standard), to ensure consistency and enable automated processing. This format (XML or JSON) allows for the efficient exchange of SBOM data between software producers and consumers, facilitating better visibility and control over the software supply chain.

After a few years, most machine-readable SBOMs in the medical device industry (this changes for each industry) are created with CycloneDX in JSON.

With the detailed information provided by SBOMs, organizations can now more effectively identify and mitigate potential vulnerabilities, reducing the risk of successful cyber attacks and other supply chain-related incidents.

While the benefits of SBOMs are widely recognized, their implementation faces several challenges. The complexity of modern software supply chains, the lack of standardized tooling, and the need for cultural shifts within the industry to prioritize software transparency are some of the key hurdles. Additionally, the cost and resources required to generate and maintain accurate SBOMs can be a significant barrier, especially for smaller organizations.

In recent years, there has been a growing recognition of the importance of software supply chain security, leading to the introduction of various regulatory and policy initiatives that are driving the adoption of SBOMs. For example, the U.S. government has issued executive orders and guidance requiring federal agencies and their contractors to provide SBOMs for their software products. These policy drivers have created a sense of urgency and a clear mandate for organizations to prioritize SBOM implementation as part of their overall product security strategy. The FDA has been there all along from the very start of this SBOM effort, and today, machine-readable SBOMs are required when performing a premarket approval for your new medical device.

However, that is a machine-readable SBOM—the lesser discussed SBOM but still required to be present during the premarket submission in the instructions for use (IFU).

The human-readable SBOM is typically expressed as a chart of the same minimum elements as found in the machine-readable version. Due to the huge expansion of entries in the SBOM that could occur, however, only the top software components are itemized in the human-readable version. For example, in a machine-readable version, it would include “Log4J” and its 294 transitive dependencies, but in a human-readable version, it would only include “Log4J,” resulting in a much smaller table of software components.

I have had clients manually create this SBOM table after they have automated tools create a machine-readable SBOM (the activity that inspired this article). The human-readable SBOM should be automatically created, requiring only minor editing for appearance and format from the machine-readable SBOM. Following are two easy approaches to performing this.

Using Excel 365

Using the latest version of Excel (using earlier versions may add complexity), the steps are:

• Open Excel

• Select the Data tab

• On the ribbon, select:
Get Data | From File | From JSON

• Browse to the location of the CycloneDX JSON SBOM file, select it, and click Import. The Power Query Editor dialog will be displayed (Figure 1). 

• Locate the row labeled “components” followed by “List” and click on List. 

• This is the “array” of components (Figure 2). Next, on the ribbon, click on “To Table Convert,” followed by “OK.”

• In the displayed Column1, there is a small icon with arrows facing left and right (Figure 3)—the “Expand” function. Click it. Then click OK. 

You will now have an accurate human-readable SBOM in Excel (Figure 4). At this point, you can use Excel to easily format what you want to include in your IFU.

Using a Python Script

Perhaps you want an approach that takes fewer steps or you don’t have access to Excel. If so, there is an excellent Python script that will convert your machine-readable CycloneDX JSON SBOM into text. 

• Assuming you have Python installed (the current version is 3.12), follow the directions at the GitHub site¹ to install the script and its dependencies. 

• Open a CMD dialog (hit the Windows key, then type CMD followed by enter) and then type “sbom2doc -I C:\example\sbom.json” (substitute “C:\example\sbom.json” with your path and filename).

• The results will be displayed as they appear in Figure 5. This can be redirected into a file, or captured from the display.

While I prefer the Excel approach, as it gives me more flexibility in how I format the table, both options work well and can save you from the tedious activity of handwriting a human-readable SBOM.

Recommended Reading

www.ntia.gov/page/software-bill-materials

www.cisa.gov/sbom 

Reference

¹ github.com/anthonyharrison/sbom2doc

Christopher Gates is the director of Product Security at Velentium. He is also the current co-chair for H-ISAC’s MDSC. Gates has more than 50 years of experience developing and securing medical devices and works with numerous industry-leading device manufacturers. He frequently collaborates with regulatory and standard bodies—including the CSIA, Health Sector Coordinating Council, H-ISAC, Bluetooth SIG, and FDA—to present, define, and codify tools, techniques, and processes that enable the creation of secure medical devices.