NTIA, SBOMs and the Future of Medical Device Cybersecurity
In May ‘21, US President Joe Biden issued an Executive Order (EO) on strengthening the nation’s cybersecurity infrastructure. This order followed a string of high-profile cyber-attacks that had taken place in the previous 18 months. The executive order pointed to software bill of materials (SBOMs) as a way of ensuring the safety and security of software supply chains across US critical infrastructure. Within the EO, Biden tasked the National Telecommunications and Information Administration (NTIA) and the Commerce Department with defining the minimum elements of an SBOM.
The NTIA published these guidelines in July 2021. The 28-page document titled ‘The Minimum Elements for a Software Bill of Materials’ can be viewed here.
While there have been conversations around SBOMs for some years (including a 2014 bill and recommendations for some medical devices), they are now a common concern across all industries. And this latest publication cements SBOMs as a staple of effective cybersecurity for medical devices.

What is a Software Bill of Materials?
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.”
A Nutrition Label for Software
An SBOM is often depicted as a nutrition label for software. In a recent interview, Allan Friedman, Director of Cybersecurity Initiatives at NTIA described it as such, referring to an SBOM as a “list of ingredients for software”. A 2021 study, which was published in npj digital medicine and titled ‘Building Resilient Medical Technology Supply Chains with a Software Bill of Materials’ followed a similar train of thought:
“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.”
The above passage perfectly 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.
This study goes on to state that:
“In the absence of a published software bill of materials (SBOM), builders such as medical device manufacturers and operators such as healthcare delivery organizations (HDOs) likely would have had to manually inventory systems to detect the vulnerable software versions. These resource-intensive processes can contribute to delays in patch validation, patch installation, and consequently, inoculation of systems.”
Again, the benefits for standardizing SBOMs across the industry are abundantly clear.

What’s in an SBOM?
Having been tasked with defining the minimum elements of an SBOM, The NTIA outlined three broad, inter-related categories:
-
-
-
-
-
-
-
-
-
- Data Fields
- Automation Support
- Practices and Processes
-
-
-
-
-
-
-
-
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.
Above is just a quick introduction to the report. You can read it in full here.

What The Future Holds for Software Security
These guidelines should be viewed as a starting point. Within the healthcare industry, SBOMs have the potential to mitigate vulnerabilities in connected medical devices. If exploited, these vulnerabilities can pose serious risks to patient safety.
While a software bill of materials is not a cure-all, the industry can benefit hugely from implementing SBOMs across the medical device supply chain. In the coming months, Nova Leah will be exploring the use cases, benefits, challenges, latest news, and real-world criticality of implementing SBOMs.
SelectEvidence and SBOMs
SelectEvidence® from Nova Leah is an expert cybersecurity risk assessment platform. The first-of-its-kind platform guides medical device manufacturers through the process of identifying applicable threats to their products and implementing the right security controls to mitigate those threats. A key component of SelectEvidence® involves the simple and automated ingestion of SBOMs which are continuously monitored for vulnerabilities. Learn more about SelectEvidence® here.