Comments from the ‘No Peanut’ Gallery: SBOM Usefulness and Limits


By: Christopher Gates

October 12, 2021

Categories: AAMI News, HTM Professionals, Medical Device Manufacturers

CYBERINSIGHTS Empty peanut shells

According to Sonatype’s 2021 State of the Software Supply Chain report, more than 12,000 software supply chain attacks have taken place since May 2020, representing a 650% year-over-year increase compared with the previous 12-month period.

“Bad actors are no longer waiting for public vulnerability disclosures to pursue an exploit,” stated Sonatype in the report. “Instead, they are taking the initiative and injecting new vulnerabilities into open-source projects that feed the global supply chain.”

Then, after that compromised version of the open-source project has been incorporated into released products as a software component, these malicious actors take advantage of their preplanted vulnerabilities. By compromising popular and/or critical software components before they’re leveraged for commercial applications, attackers are able to set themselves up for future zero-day exploits.

Although the concern isn’t limited to the health sector or medical devices, we are affected. Open-source projects and other third-party components (e.g., SOUP [software of unknown provenance] in the somewhat misleading language of IEC 62304) are frequently leveraged in software development, including software used in medical applications and healthcare settings. Some of the reasons include:

  • Reducing development costs and times.
  • Ensuring compatibility.
  • Ensuring compliance.
  • Leveraging the quality assurance and security vigilance of development communities beyond the walls of any one organization.

“Reinventing the wheel” when a tried and tested solution already exists to solve common challenges in software development would introduce a host of other challenges, expenses, and delays. Simply avoiding open-source and other third-party software components is so impractical as to be a nonstarter. That’s why President Joe Biden’s recent Executive Order on Improving the Nation’s Cybersecurity, as well as the Food and Drug Administration (FDA) seeking a more direct mandate from Congress to address cybersecurity, focuses instead on solutions that will help healthcare delivery organizations (HDOs) and medical device manufacturers (MDMs), along with other critical-infrastructure industries, exert security controls on their supply chains.

A man faces multiple monitors as he maintains cybersecurity.

Among these controls, the software bill of materials (SBOM) has taken center stage. Put simply, an SBOM is the software equivalent of ingredients lists on food packaging. If peanuts are a “vulnerability” (e.g., causing an allergic response), the ingredients list lets you determine whether peanuts were used in the creation of that product.

SBOMs go beyond a simple ingredients list, however. In software terms, a third-party component is a “dependency,” and because development so frequently builds on prior development, each dependency may have subdependencies. This can get very complicated to organize in a human-readable format, so human-readable SBOMs—such as those required to be included in a medical device’s labeling following release of the FDA’s Content of Premarket Submissions for Management of Cybersecurity in Medical Devices guidance in 2018—typically only display dependencies down to the second or third level.

This is comparable with what happens in food labeling when a primary compound ingredient gets broken down parenthetically to reveal its component ingredients (e.g., rolled oats [oats, molasses, peanut oil]). People living with severe food allergies are intimately familiar with the need to interrogate ingredients down to the nth level to make sure that what they’re buying will be safe for them to consume.

SBOMs and ingredients lists do differ, however, in terms of what you can do with an SBOM once you have it. Ingredients lists describe “components” in a fixed product. Whether you’re a manufacturer that becomes aware of a market need to eliminate peanuts in your product, a chef cooking for a customer with allergies, or a consumer with a recently diagnosed dietary need, you can’t do anything about what’s already in stock on store shelves, in commercial kitchens, or in your pantry at home.

For the end user of a food product (e.g., chef, consumer at home), the possible responses are very limited. However, this is not the case with software. After the software manufacturer knows the product has a problem, it can create a solution and, with the aid of authorized users at HDOs (and in certain cases patients at home), it can push the update out to the affected products—making them safe for end users without having to issue a recall.

Of important note, securely updating medical devices in the field is not a simple process, but designing devices and infrastructure with the capacity to perform such updates is now expected by the FDA. And it’s much less costly—in terms of business risk and risk to patients—compared with a recall!

ingredient listSimilar to how a person with a peanut allergy can check the ingredients list of a food product to see if peanuts were used in the making of the product, the end user of a software product can check the software bill of materials (SBOM) to see if a potential security vulnerability is present in the list of components. However, the similarities between the two part ways soon thereafter. For example, whereas a person can’t change the nature of peanuts to avoid an allergic response, a software manufacturer can recognize that a component of a product is causing a security problem and push an update, therefore rendering the product “safe” for the end user.


With software, a complete, nested inventory can go dozens of levels deep and potentially encompass hundreds of dependencies and subdependencies. Although creating such an inventory is most likely not feasible at the present time, this is the goal in coming years.

In addition, for an SBOM to be really useful, it must include more than just the name of the software component. What version was used? From where was the component sourced? These are two of the most critical data points needed for an SBOM to be actionable. However, the complete list of elements is available from the Department of Commerce’s National Telecommunications and Communications Administration (NTIA).

For most projects, capturing all of these data requires a second, machine-readable version of the SBOM to be maintained and accessible through automated tools. That way, when a new vulnerability is discovered in a third-party software component and disclosed, all stakeholders can order a quick search to rapidly determine whether their particular product or implementation is affected.

Having a comprehensive SBOM in place enables swift, appropriately scaled response to compromised software supply chains. They allow MDMs, HDOs, and even patients to determine whether their specific devices are affected and eligible for a security patch when a new vulnerability becomes known.

To return to our food/software analogy, let’s say the scenario is slightly different. Imagine that the manufacturer’s ingredients include no peanuts or peanut products, but an investigative journalist has just discovered that a commercial supplier of blended vegetable oil accidentally included peanut oil in a particular batch’s blend by mistake during a particular week in the previous quarter.

Initially, the mistake went undetected (or at least unreported), but it has now come to light. The manufacturer now knows that it’s possible that some, or all, of their product created after that industrial accident may contain peanut oil. If they have the food equivalent of an SBOM, they’ll be able to look up precisely which batch of their product (down to a range of serial numbers) used which lots of blended vegetable oil from the compromised supplier. If any peanut oil made it into their finished product, they’ll be able to correlate production serial numbers against shipping records and know where those contaminated products went. Then, instead of having to blindly recall everything produced since the supplier’s industrial accident, the manufacturer can issue a recall and public service announcement specific to those contaminated products.

Unlike manufacturers of food products, software manufacturers have more options related to vulnerabilities, including the ability to push a vulnerability mitigation directly to affected devices, without needing to recall them from stores and end users.

The SBOM concept first emerged in the late 1990s as a local tool, limited to internal development teams. In 2007, it was broadened to enable tracking and compliance with third-party software licensing. Then, in 2018, public/private working groups organized out of the NTIA, coordinated by Dr. Alan Friedman, began work in earnest to expand and develop SBOMs into a useful cybersecurity tool. Government and industry experts have codified SBOMs in anticipation of coming regulation and accelerated threats, and many organizations have stepped up to provide both thought leadership and implementation tools. In addition to the NTIA itself, notable resources include:

  • SPDX, a machine-readable SBOM tool created by the Linux Foundation. SPDX is now a recognized international standard per ISO 5962:2021.
  • CycloneDX, a machine-readable SBOM tool originally created by Steve Springett and now an OWASP (Open Web Application Security Project) initiative and supported by a robust training series.

Both of these excellent standards are widely supported by off-the-shelf, open-source, and commercial software, paving the way for robust automatic vulnerability monitoring services, such as MedCrypt’s Heimdall.

Widespread SBOM adoption and use is critical, but SBOMs alone are not enough to secure the software supply chain. SBOMs can’t, for example, be used to detect compromised software injected directly into the primary source code during development, whether actively (by a malicious actor working for the MDM or a subcontractor) or passively (by a previously compromised build system or development tool).

SBOMs also can’t control for a compromised production line during manufacturing, a compromised update system, or a successful attack during the update process. Each of these scenarios represents potential vulnerabilities to the HDO’s and/or MDM’s supply chains. Separate controls must be adopted to address them—which deserves a dedicated CyberInsights column of its own!

Resources for adopting comprehensive supply chain controls, including SBOM implementation and management, are available from the National Institute of Standards and Technology (NIST Special Publication 800-161, Cyber Supply Chain Risk Management Practices for Systems and Organizations) and the Cybersecurity & Infrastructure Security Agency.

Christopher Gates is the director of product security at Velentium in Lafayette, CO. Email: chris.gates@velentium.com