Nova Leah’s Ultimate SBOM Guide (Software Bill of Materials)

An SBOM, or software bill of materials, 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. 

When it comes to medical device software, an SBOM provides greater transparency and allows medical device manufacturers and healthcare operators to identify vulnerabilities and monitor medical device security more effectively. 

As the healthcare industry undergoes a complete re-examination of its cybersecurity processes, protocols and the regulatory landscape in general, SBOMs have been earmarked as a way to ensure the safety and security of software supply chains. 

There is no doubt about it — for those of us that are working in the medical device or healthcare industry, SBOMs are going to be a prominent feature for years to come. That is why we have decided to put together this ‘Nova Leah’s Ultimate SBOM Guide’. 

Introduction – A Transparency Issue in the Medical Device Industry

When purchasing a car, if you wanted to find an itemized list of every nut, bolt or auxiliary component, you’d be able to do so. Manufacturers cannot market a vehicle without accounting for each and every part used in its development. Without this piece of due diligence, product recalls would be impossible to roll out when certain parts are found to be faulty. This level of transparency is something we’ve become accustomed to.  

Yet for many years, we’ve been given very limited visibility into what makes up a piece of software, its supply chain and the third-party components. When issues or breaches occur, it can be very difficult to find solutions when various components aren’t properly accounted for.  

To make matters even more difficult, software solutions of today are made up of parts from many different vendors, often referred to as the software supply chain. Without a certain level of visibility, these software supply chains can be left vulnerable and open to cyber attack. One solution to this issue is to use SBOMs.

Using SBOMs to increase transparency and tighten supply chain security is something that has been endorsed by government bodies all over the world. In May 2021, US President Joe Biden issued an Executive Order on strengthening the nation’s cybersecurity infrastructure. This order followed a string of high-profile cyber-attacks. The executive order pointed to software bill of materials as a way of ensuring the safety and security of software supply chains across US critical infrastructure. 

What is an SBOM?

At the beginning of this blog post, we provided a quick definition of an SBOM and also compared it to an ‘ingredients list’ for software. This is something that was explored in more detail in a 2021 study titled ‘Building Resilient Medical Technology Supply Chains with a Software Bill of Materials’:

“An SBOM is analogous to the list of ingredients on food packaging. The ingredients list provides transparency about components (e.g., salt, nuts, and high-fructose corn syrup), allowing individuals with medical conditions, allergies, or preferences to make better buying decisions. Software engineers build products by assembling open-source and commercial software “components”, which are smaller pieces of software built by third parties. Similar to an ingredients list, an SBOM lists every component of software in the finished product. This ensures that anyone who chooses the product knows its relative hygiene, and anyone who uses the software knows what is inside. When a widespread vulnerability is discovered, SBOMs enable patients or organizations such as HDOs to identify impacted technology that might be in use.” 

This analogy is one that we use a lot at Nova Leah. The above passage also clearly describes the relevancy of SBOMs and how they can help organizations with emergency management and software licensing. If a vulnerability is uncovered, the SBOM can be used as a reference point to allow users and manufacturers to quickly identify the issue and fix it.   

What is a 510(k)?

What’s included in an SBOM?

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. 

In a document titled  ‘The Minimum Elements for a Software Bill of Materials’, the NTIA outlined three broad, inter-related categories — data fields, automation support, and practices and processes. These three categories are outlined in more detail below:  

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. 

Who Uses an SBOM?  

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.  

The Security Benefits of a Software Bill of Materials 

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:  

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

A full description of these benefits can be found here.  

The Role of SBOMs in Medical Device Risk Management 

Medical device risk management is the continuous process of identifying security vulnerabilities within a medical device and implementing plans to address them. It is an integral part of the medical device product development lifecycle. 

Risk management allows medical device manufacturers to ensure that their product works as expected and that all the necessary steps are being taken to adequately secure a device, limit threats and minimize risks. In other words, risk management is about finding weaknesses in medical device software and making sure they are properly addressed. 

In the last few years, SBOMs have emerged as a crucial component of the entire software supply chain risk management process. An SBOM gives developers, buyers and users of software a way to track software dependencies across supply chains, manage vulnerabilities and anticipate emerging risks. SBOMs are primarily making life easier for two different types of stakeholders – medical device manufacturers and healthcare providers

Medical Device Risk Management For Medical Device Manufacturers

SBOMs have made a number of risk management activities much easier and more effective for medical device manufacturers. 

This includes: 

                    • Risk Analysis: SBOMs can be used to identify potential cyber security vulnerabilities associated with known software components. 
                    • Risk Evaluation: SBOMs provide information about potential vulnerabilities that may exist, including their potential exploitability and impact. This can be used to estimate and evaluate the level of risk associated with a particular vulnerability. 
                    • Risk Control: Monitoring and routinely updating an SBOM with known vulnerabilities helps to keep risks at an acceptable level. 
                    • Lifecycle Risk Management: An SBOM can be provided as part of product security documentation to HCPs at purchase and throughout the device’s life cycle. 
Medical Device Risk Management For Healthcare Providers

SBOMs are similarly important to healthcare providers. The role of SBOMs in the risk management process starts in the pre-procurement phase where healthcare professionals are being advised to request an SBOM for any devices that are integrated into their network infrastructure. Requesting an SBOM allows for greater transparency and awareness. It also allows the healthcare provider to have more faith in what they’re buying.    

By being provided with SBOMs, healthcare providers are more informed about what’s in a device and what risks are associated with it. They can then apply more effective control measures and mitigation strategies across the device life cycle.  

Why It’s Important to Share Your SBOM 


Using and sharing an SBOM is in the best interest of not just your product but the entire software supply chain. 

In its two-page SBOM overview, the NTIA stated the following:   

“Software vulnerabilities are the by-product of both the human process of developing software and the increasingly frequent target of attacks into the software supply chain. If users don’t know what components are in their software, then they don’t know when they need to patch. They have no way to know if their software is potentially vulnerable to an exploit due to an included component – or even know if their software contains a component that comes directly from a malicious actor.”  

If there is one thing that everyone in the cybersecurity community can agree on it’s that you can’t secure what you do not know. One of the key reasons for using SBOMs is to provide manufacturers with greater transparency of what’s going on ‘under the hood’. Knowing the components of software installed on a device can save hundreds of hours in the risk analysis, vulnerability management, and remediation processes. While an SBOM won’t automatically solve all security problems, it does empower teams to solve cybersecurity issues faster and easier. 

Debunking SBOM Myths and Misconceptions

As SBOMs have grown in popularity, the misinformation has grown along with them. Below we address some of the biggest myths and misconceptions.

Myth 1 – The transparency offered through using an SBOM will make it easier for hackers to attack.

Being transparent with an 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.  

It is said however that attackers working with a criminal organization can leverage information contained in an SBOM. However, they are more than capable of scanning for vulnerabilities at scale without an SBOM so the point is irrelevant.  

On the flip side, the defensive benefits far outweigh this common concern about creating a “roadmap for an attacker”. If you were to forgo using an SBOM because you thought that it provides an attacker with an advantage, what you are actually doing is eliminating whatever advantage you had for protecting against such an attack. It would be like destroying your defensive playbook for fear that it could be used against you. In reality, it is just making you more vulnerable.  

Myth 2 – An SBOM alone provides no useful or actionable information.

An SBOM is not a security tool in itself. However, for those who produce software, it improves the ability to identify individual components and better locate vulnerabilities.  During an active attack, an SBOM allows a medical device manufacturer or enterprise to answer key questions such as “does my device contain any of the components that are at risk”, “am I affected?” or “where am I affected?”. 

This can be done in a matter of minutes or hours instead of days or possibly even weeks as might be the case without an SBOM. In this way, an SBOM speeds up the entire vulnerability scanning process, making it an incredibly useful defensive tool. 

Myth 3 – An SBOM increases exposure to licensing violations.

Licensing obligations are completely independent of SBOMs. License obligations occur whenever licensed software is present. SBOMs merely provide an inventory of software that may otherwise be hidden. In this way, SBOMs make potential license violations more visible. These violations should be dealt with regardless of whether or not they are listed on an SBOM. The awareness gained by creating an SBOM allows manufacturers to address unknown licensing commitments that may be lurking in your programs and that otherwise have been left unresolved.  

Myth 4 – An SBOM needs to be made public.

The act of generating an SBOM is separate from sharing it. An SBOM does not need to be made available to the public. You may need to provide an SBOM to a customer, but this can be done directly, avoiding the exposure of a public website. 

Myth 5 – SBOMs are not scalable.

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.  

Scalability is key to the success of an SBOM. Developers are already under pressure to finalize software, on time and under budget. The requirement for SBOMs wouldn’t have been prioritized unless it was already known to be automated and scalable.  

Myth 6 – An SBOM exposes business secrets.

A worry for some organizations is that in sharing an SBOM they are given away their trade secrets. This is simply not the case. To go back to our much used ‘SBOM as a list of ingredients’ analogy, there is a big difference between sharing a list of ingredients and sharing a recipe. Every food business that markets a food product shares a list of ingredients. In doing so they are not giving away trade secrets.  

Added to this, it would be difficult for an SBOM to expose intellectual property or leak trade secrets. Items listed within an SBOM include libraries, drivers, firmware, licenses, and operating systems. Code is not included in an SBOM, just component references. Your proprietary source code remains yours to share or to keep confidential at your discretion.

SelectEvidence and SBOMs

SelectEvidence™ is an expert cybersecurity risk assessment platform that guides medical device manufacturers through the process of identifying applicable vulnerabilities and identifying the right security controls to mitigate those risks. It provides device manufacturers with an intelligent, automated, and traceable approach to cybersecurity assessments. SelectEvidence™ does this by continually monitoring SBOMs across all connected medical devices.

The simple and automated ingestion of each SBOM makes it easier and faster to start monitoring and managing risk. SelectEvidence™ scans hundreds of thousands of vulnerabilities in real time, harnessing automation for 24/7 peace of mind. The solution provides specific and actionable mitigations for every vulnerability found. 

Learn more about SelectEvidence™ and download a free information sheet on our Solutions page.