Software Bill of Materials: The Most Frequently Asked Questions (FAQs)  


What is a Software Bill of Materials (SBOM)?  

The software bill of materials, or SBOM, provides a list of all software components within a given device. Items listed within an SBOM include libraries, drivers, firmware, licenses, and operating systems. Given the obvious similarities, an SBOM is often depicted as a nutrition label or ‘ingredients list’ for software. Within the healthcare industry SBOMs provides greater transparency and enables medical device manufacturers and healthcare operators to identify vulnerabilities and monitor medical device security more effectively.   

Within ‘The Minimum Elements for a Software Bill of Materials’, the NTIA defined an SBOM as follows:  

“An SBOM is a formal record containing the details and supply chain relationships of various components used in building software. In addition to establishing these minimum elements, this report defines the scope of how to think about minimum elements, describes SBOM use cases for greater transparency in the software supply chain, and lays out options for future evolution.”  

What is in a Software Bill of Materials?  

In his 2021 Cybersecurity Executive Order, President Biden tasked the National Telecommunications and Information Administration (NTIA) and the Commerce Department with defining the minimum elements of an SBOM. Their minimum elements document was published in July 2021. In it, The NTIA outlined three broad, inter-related categories including data fields, automation support, and practices and processes.

Below, we go into the three categories in a little more detail: 

Data Fields – Data fields contain baseline information about each component that should be tracked and maintained across the software supply chain. With this information, users can identify various components and map them against other available sources of data, such as vulnerability databases or license databases. The (minimum) required fields are:  

                    • Supplier Name   
                    • Component Name  
                    • Version of the Component  
                    • Other Unique Identifiers  
                    • Dependency Relationship  
                    • Author of SBOM Data  
                    • Timestamp 

Automation Support – SBOMs must be in a machine-readable format and contain information about software components, their dependencies, and their hierarchical relationships. NTIA has defined the following approved formats:  

                    • Software Package Data eXchange (SPDX)  
                    • CycloneDX  
                    • Software Identification (SWID) tags  

Practice and Processes – This section provided guidance on how SBOMs are used. To integrate SBOMs into the operations of the secure development life cycle, the NTIA advised organizations to follow certain practices and processes that focus on the mechanics of SBOM use. The document shared best practices in relation to frequency, depth, known unknowns, distribution and delivery, access control, and accommodation of mistakes.  

What is a 510(k)?

Who uses SBOMs?  

SBOM usage falls into three main categories. There are those who produce software, those who purchase software and those who operate software.  

For those who produce software, an SBOM assists in the overall production and maintenance process. An SBOM improves the ability to identify individual components and better locate vulnerabilities.  

For those choosing software, a software bill of materials increases transparency and helps in the buy decision-making process as it displays exactly what components exist within a software device.  

For those operating software, a software bill of materials makes it easier to spot risks and vulnerabilities. It is also a key part of managing licenses and compliance.  

Who should have a software bill of materials? 

An SBOM is created and maintained by the producers of software. Within the medical device industry this includes medical device manufacturers, suppliers and individual authors. Any organization that is concerned about better supporting their software products internally, supporting their customers, and being part of a more secure medical device industry should consider creating SBOMs and providing them to support their customers.  

Once again, the benefits of developing and maintaining an accurate list of software components is to better assure trustworthy and reliable software.

Is it mandatory for manufacturers to produce an SBOM? 

As cybersecurity threats and risks continue to evolve, SBOMs have been repeatedly highlighted as a means to strengthen cybersecurity and ensure software supply chain security. The regulatory landscape is beginning to catch up to this advice. A key element of Joe Biden’s Cybersecurity Executive Order, published in May 2021, was the requirement for vendors to provide an SBOM as part of the federal procurement process. 

This was followed in April 2022 by the FDA publishing an overhauled draft guidance on medical device cybersecurity for submitting a premarket submission. Within this draft guidance the use of threat modeling and SBOMs are identified as ways of managing security risk.

The medical device industry is currently undergoing a major re-examination of cybersecurity laws and regulations. As SBOMs have repeatedly been highlighted as a way to strengthen cybersecurity, we can expect to see further requirements for their use.     

What are the benefits of using SBOMs? 

When it comes to strengthening medical device cybersecurity, there are many benefits of using SBOMs including greater transparency and improved ability to spot vulnerabilities. The benefits that using SBOMs bring can be felt throughout the software supply chain and directly affect multiple parties including medical device manufacturers, healthcare delivery organizations and, ultimately, patients. While an SBOM is not a cure-all, the industry can benefit hugely from utilizing SBOMs across the medical device supply chain. 

The benefits of using an SBOM across the total product life cycle include (but are not limited to):  

                      • An improved ability to identify software components contained in a device. 
                      • Better identification of suspicious software components and vulnerabilities. 
                      • More secure software development. 
                      • The ability to resolve security flaws quicker and more efficiently. 
                      • Increased software transparency among vendors and increased consumer trust. 
                      • Improve licensing governance. 
                      • Greater supply chain resiliency. 

A full description of these benefits can be found here.  

What are the common concerns about SBOMs? 

In a recent Forbes’ article, Daniel Riedel shared three reasons why software developers are tentative about sharing SBOMs. Developers’ fears include:   

                    • That the transparency offered through using SBOMs will make it easier for hackers to attack.  
                    • That building the SBOM itself will extend software delivery times.  
                    • That the package listing all the software in an organization will be unmanageably large.   

Being transparent with the SBOM isn’t going to create a roadmap for attackers as it does not divulge the configuration of the software. Instead, it creates a roadmap for an organization and its customers to be able to respond to threats quickly. Modern best practices in software development require solutions to be assembled a piece at a time. Adding an SBOM component to that process and building it into a DevOps continuous integration and continuous delivery pipeline isn’t a lot of additional work. And if it’s large, that’s not necessarily a bad thing. SBOMs are designed to be machine-readable so the size of an SBOM doesn’t really matter. 

 

How does an SBOM relate to the Manufacturer Disclosure Statement for Medical Device Security (MDS2)?  

The Manufacturer Disclosure Statement for Medical Device Security (MDS2) is a voluntary standard that includes a form/questionnaire which medical device manufacturers use to communicate crucial security-related information to healthcare delivery organizations. 

While SBOMs can be seen as the ingredients list of a software device, MDS2s are more like the nutritional facts related to it. The MDS2 captures and contextualizes security information through a list of short questions that cover 23 topics known as security capabilities.

Most of the questions use a simple yes or no format so that there’s little room for interpretation and confusion. Within the form there are questions related to; the management of personally identifiable information, authorization, audit controls, cybersecurity upgrades, patching, data backup and disaster recovery, connectivity capabilities, and personal authentication, amongst other security considerations. Software Bill of Materials is also one of those topics which include 8 questions regarding the development, rigour and updating of SBOMs.

To learn more, you can check out this blog post. 

Image credit – Photo by ThisisEngineering RAEng on Unsplash