Improving medical device security with a software bill of materials

Developing a software bill of materials (SBOM) can help medical device manufacturers better manage the security of their devices. 

In 2021, 33% of all third-party breaches targeted the healthcare industry. Part of the underlying challenge facing healthcare organizations is managing medical device security and tracking vulnerabilities across the many systems used within the care environment. To mitigate risk and improve the overall security posture of medical device manufacturers, the U.S. Food and Drug Administration (FDA) and the Biden administration have provided guidance aimed at strengthening security and documentation requirements. One specific measure toward that end is for medical device manufacturers to provide a software bill of materials (SBOM) as part of their product submissions and subsequent releases. 

What is a software bill of materials? 

An SBOM is an inventory of all the components, libraries, and dependencies supporting a device or application, analogous to an ingredient list a customer might find on the side of a packaged food product. This inventory is standardized, machine-readable, and able to be interpreted by vulnerability scanners and other kinds of software. Ultimately, because SBOMs provide information about the supply chain involved with the application, they can help software developers and buyers analyze vulnerabilities and manage risk. 

According to the National Telecommunications and Information Administration’s working paper “Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM),” the purpose of SBOMs is to “uniquely and unambiguously identify components and their relationship to one another,” which helps consumers account for all components. By being able to catalog each component of firmware, consumers can isolate issues they might find and thus expedite the process of mitigating risks. For these reasons, creating SBOMs is now advised as a best practice and could eventually be required by law.

What do SBOMs have to do with medical device security?

According to the security company Armis, 40% of healthcare organizations experienced a ransomware attack from WannaCry in the last half of 2019, two years after the initial incident and after patches had been made available. Continued vulnerabilities from a broad attack such as WannaCry demonstrate the endemic problem and consequences of old, unpatched devices being left unsecured in healthcare environments. Additionally, such vulnerabilities cause significant cybersecurity attacks and breaches of data across the industry. Security improvements in third-party medical devices are necessary, and using SBOMs is a big step toward a more secure environment.

The ease with which threat actors can exploit known vulnerabilities and the sensitivity of the data they store makes medical devices lucrative and enticing targets for attackers. These environments use the internet of medical things, including third-party devices and software, for client service delivery, including kiosks, heart monitors, and even remote patient monitoring systems that malicious actors can use as attack vectors. 

In addition to falling behind on updates, vendor-supplied devices often rely on open-source code. In fact, the “2022 Open Source Security and Risk Analysis Report” by Synopsys, which analyzed codebases from all industries, noted that 93% of the healthcare repositories it scanned contained open-source code. This research also found that 81% of open-source code repositories contained at least one known vulnerability, and almost half of the codebases scanned contained at least one high-risk vulnerability. This level of research is possible because the vulnerabilities within open-source repositories are public to everyone – cybercriminals and developers alike. Therefore, organizations using these open-source repositories need to be extremely timely in making updates and fixing security flaws before bad actors have a chance to exploit the known bad code.

Outside of vulnerabilities, Synopsys identified license conflicts in more than half of the codebases. These stipulations in the licenses for how the software can and should be used could prompt lawsuits or compliance issues for manufacturers and clients of the devices where such licensing conflicts exist. Thus, having a deep understanding of what requirements are laid out in each license is necessary to ensure compliance with how the software can be used. Given the challenges with open-source code and license conflicts, a significant portion of medical devices on the market are set up for failure in terms of security. To combat these challenges, manufacturers need to produce an inventory of the resources used in the devices. 

What guidance exists on medical device security?

While medical device manufacturers are, at the moment, only being encouraged to increase the standard of security for developing new medical devices for premarket approval, federal guidance and legislation is focusing on new standards and laws that, if implemented, would create more stringent standards regarding the approval of these devices. 

In May 2021, an executive order called for, among other things, strengthening supply chain software security. The order notes that one means of improving security is through the use of SBOMs. Bipartisan, companion legislation, known as the Protecting and Transforming Cyber Health Care Act of 2022 (PATCH Act), is currently working through the House and Senate. Should the PATCH Act become law, regulations would require all medical “cyber device” manufacturers to furnish users with SBOMs that contain all software components. Additionally, draft guidance from the FDA in April 2022 emphasizes that manufacturers should provide a risk assessment of the known vulnerabilities of the device that includes how consumers should address those vulnerabilities.

How might SBOMs become part of medical device development?

Federal efforts to mandate strengthening security and best practices speak to an undeniable drive for greater security surrounding the components that support functionality in medical devices. The industry standard for approving devices in this market likely will become more rigorous in order protect patient care and improve overall security for product manufacturers and the organizations that use the devices. 

What might using SBOMs as part of a developmental cycle look like? On the manufacturer side, developers could implement a software composition analysis tool to compile and continually update SBOMs. Such a tool could then automatically scan for known open-source vulnerabilities, licensing, and versions. Having SBOMs available across a manufacturer’s portfolio allows granular visibility into device software and enables the manufacturer to quickly identify risks and address security issues.  

On the healthcare delivery side, consistent access to SBOMs can enable administrators to act more quickly in response to threats against their networks and environments. Security teams are well aware of vulnerable codebases used in medical devices, so being immediately alerted to known vulnerabilities helps keep patients safe. SBOMs can also help administrators stay one step ahead of attackers by preventing ransomware and other kinds of security events. 

What can medical device manufacturers do now to secure their environments?

Medical device manufacturers should incorporate security into their device and software development processes by establishing security standards to which all devices and software must adhere. Reviewing security, evaluating against established standards, and scanning code for security vulnerabilities should take place periodically throughout the development process and prior to launch. Additionally, device manufacturers should establish an SBOM inventory management process to monitor their portfolios for vulnerable code to help enable prompt correction of code and release to customers.

As security requirements of medical devices and applications increase in response to guidance, legislation, and patient expectations, medical device manufacturers must continue to mature their product security programs.