Published in


The Role SBOMs Play in Healthcare Security

Originally published by Keri Forsythe-Stephens for 24x7 Magazine on November 18, 2021

The healthcare community has made progress in bringing awareness to medical device cyber-risks, as evidenced by the nearly 400%, year-over-year, increase in vulnerability disclosures since the U.S. FDA post-market guidance in 2016. However, identifying, managing, and remediating vulnerabilities is a complex task and has been burdensome and slow as it has traditionally relied on manual processes.

The strategic imperative is to move security upstream in the supply chain and build proactive security into devices starting with the architecture and design phases. If this methodology is applied across the lifecycle, it could reduce total costs, improve cybersecurity, and alleviate the burden that is currently passed on to and consequently carried by healthcare delivery organizations, physicians, and patients. One of the first steps in this journey is to build a vulnerability management program, which includes generating a software bill of materials (SBOM)-meaning a definite and accurate identification of all software components in a device.

Today’s State of Affairs

There are certain trends which highlight the urgency for addressing security gaps sooner rather than waiting to react to them in the deployed device, e.g., in a hospital. As a recent study highlighted, “hospitals are already facing the consequences of omitted [security] measures within their growing pool of medical devices.”

When designing a security program, there is seemingly a never-ending list of things that need to be added or could possibly derail the success of the program, and they must be mitigated. Seasoned executives will confirm that delivering security used to be relatively straightforward, with amateur or opportunistic attackers being the most probable adversary.

Today, the situation is different. Cybercriminals are organized, motivated, well-funded, and possess a wide range of skills. In an assessment of the SolarWinds attack during the winter of 2020, Microsoft estimated at least 1,000 engineers were involved in creating the attack. Is there any non-government entity that has an equivalent number of resources at their disposal to defend their ecosystem?

Why a Reactive Approach Doesn’t Work

It’s a common trope in cybersecurity to say that people are the weakest link. This is often followed by a statistic from the 2020 Cost of a Data Breach Report published annually by IBM and Ponemon stating 23% of breaches were attributed to human error or negligence.

But maybe that statistic should instead be interpreted as we are missing 23% of use-cases where a human’s behavior has been misunderstood, and where technology failed so that the human became the expected last line of defense. A great example is email-we’ve all sat through training which shows when clicking on a link in an email, make sure you check various feature to avoid falling for a phishing scam.

In reality, most email providers already have ML/AI trained filters to identify potential scams and have filtered out suspicious emails. If this filter cannot identify a phishing email, is it really fair to ask an end user to be able to do this? The gap keeps widening between attackers and defenders, and while there are some mitigation tools implemented to bridge us through this cybersecurity maturation, pointing to the people and manual processes to mitigate cybersecurity is not scalable nor sustainable.

During WannaCry in 2017, regulators and hospitals needed to answer the question: “Which devices in the field are affected by the Windows SMB vulnerability that is allowing WannaCry to spread?” This was difficult to do, because there was limited record of which version and patch level of Windows deployed medical devices were running.

This pain point was further evidenced with the recently disclosed, deeply embedded technology stack vulnerabilities (Urgent11, Amnesia:33, etc.), which impacts components, in some cases several generations, commonly found in medical devices.

How to Move Forward

As with most hard things, our industry seems to be struggling to get started. Frequent supply chain attacks have become something of a “new normal” for those of us whose everyday work involves protecting applications.

Further validated by the executive order (EO) issued in May by the White House, which directed federal agencies to bolster cybersecurity and that the National Institute of Standards and Technology (NIST) issue new guidelines to support the EO. Supply chain vulnerability management thus seems a prudent place to start, as evident by the fact that the EO specifically calls out SBOM as a procurement deliverable.

In practice, some device manufacturers have people-driven processes that manage vulnerabilities on a device during the pre- and post-market phases. Healthcare organizations, on the other hand, typically are struggling to get accurate inventories of devices and their respective SBOMs. This reflects the reality that there is massive variability in maturity across healthcare.

Supporting a product SBOM was never meant to be a standalone silver-bullet. It plays a role as part of a security strategy that begins at the inception of product design and persists across a device’s lifecycle. The transparency an SBOM provides into all the dependencies between the software components of an application or device can help prevent, or more quickly mitigate, supply chain vulnerabilities.

Over the years there have been objections to the SBOM, which the NTIA recently myth-busted. Of particular interest is the discussion around not making SBOMs public but being intentional in what information is shared and with whom. Within healthcare this is absolutely relevant as the value proposition varies dramatically depending on where you sit in the device lifecycle:

  • For software producers (i.e., manufacturers):
  • For software buyers and operators (i.e., healthcare delivery organizations):
  • For software operators (i.e., manufacturers and operators):

The more complex an application, the more valuable an SBOM, as it provides clarity into the dependencies within the components, and among the multiple layers of the software (i.e., the application, and the OS).

To date, the industry is still working through aligning on what should be included in the SBOM and the depth to which it must be compiled to be useful. The NTIA r ecently published a minimum expectation for what should be included in an SBOM, but much like security continues to evolve, it is reasonable to expect this will evolve as well.

Vidya Murthy is chief operating officer at MedCrypt. Questions and comments can be directed to 24×7 Magazine chief editor Keri Forsythe-Stephens at

Originally published at on November 18, 2021.




Proactive Healthcare Security in a Few Lines of Code

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store


More from Medium

Healthcare cybersecurity 2022: Learning from the cutting edge

The opportunities and challenges that digital technologies bring fashion retailers with.

Information Security Protection Goals

Integration = Innovation