Our Medical Devices’ Open Source Problem

Our Medical Devices’ Open Source Problem

Originally published on BeepingComputer, May 11, 2022

Open Source is Eating Device Software – What Are the Risks?

 

There is no doubt that open source powers our development processes, enabling software developers to build high quality, innovative products faster than ever before. Because it is already coded, typically well-tested,  and usually available free of charge, OSS offers developers a healthy way to get a head start on their medical device development.

Built and supported by vast communities of developers, OSS has become the ubiquitous building block of devices and apps in the general information technology community where 92% of applications now contain open source software – and medical devices have been catching up with that trend over the past few years.

Grabbing readily accessible routines and resources, like classes, functions, and communication protocols, is certainly an attractive boost to developers under pressure to produce fully functional medical products that meet aggressive delivery schedules. Why take the time to code from scratch if someone has already written the code you need and is willing to hand it to you free of charge?

But OSS also comes with its own set of risks that device manufacturers must address while leveraging its many advantages, because when it comes to the medical devices our lives depend on, a data breach or a system crash is nothing to sneeze at.

Risks of OSS

Visibility, security, and compliance are critical to properly managing OSS. Understanding these three factors will help verify that all the OSS that you adopt will contribute to the success of your medical device projects without exposing your company – and patients – to unacceptable risk.

Visibility

Gaining complete visibility of all the code implanted in devices is especially tricky for open source. It’s not practical to conduct a thorough manual examination of every library when devices rely on thousands of lines of open source code. Furthermore, one open source library could be pulling in any number of dependencies: other open source libraries in a potentially long chain that also need to be examined.

Cybersecurity

With large communities developing and updating, OSS tends to be thoroughly tested, robust, and reliable. But just because it is widely used doesn’t make it cybersafe. Just as many medical devices are still operated by PCs using the geriatric Windows XP, old code, open or otherwise, might have been birthed before the times of scrutiny for cyber safety.

Robust code isn’t necessarily hygienic code from the cyber perspective. Breaches can come about because an old version of an open source component OSS incubates a known vulnerability that hackers could exploit. Hacks on medical devices such as insulin pumps and implanted cardioverter defibrillators continue to damage the operation of medical devices. Open source management requires continuous tracking of open source libraries and their versions, in order to ensure devices do not contain vulnerabilities.

Applying updates to open source code is another acute cybersecurity issue. While the open source community is updating code as tirelessly as a hospital intern, there is no effective update push like you would experience with Windows 11 or Salesforce. Open source libraries don’t magically update themselves, and version updates could be published across a number of open source community resources. It’s impossible  to manually track all of the open source libraries in a codebase, and manage the numerous patches and version updates.

Compliance

License compliance is another acute issue. Open source software makes use of licenses that offer use of the source code at no charge. However, there are many such libraries that use licenses that conflict with one another in terms of permissions, requirements, and conditions. With more than 180,000 open source projects available and more than 1400 unique licenses, it’s no small task to understand, much less manage, the complexities of all this licensing.

No wonder the medical device industry has been slow to adopt OSS!

The only way to ensure that medical devices are complying with all of their open source licensing requirements is by identifying and carefully tracking all the open source components throughout the lifetime of the devices. That means from development through production and onto years of service in the hospital and clinic.

How to Track Open Source Usage In Medical Devices

Full visibility into all of OSS is necessary to properly manage it. But there is no way that you can manually track all of the lines of code, their use of and dependencies on other open source components, their updates and versions, their licensing requirements, their compliance with regulations, and their evolving vulnerabilities.

The only way to track all open source libraries is to automate the process, and run it continuously. When it comes to connected devices, it’s best to go with binary analysis, to ensure all aspects of the software that makes up a medical device. Binary analysis can identify vulnerabilities and security risks that might impact device operation and your customers. It automatically examines the actual code used in your software, yielding a lower false-positive rate while helping you focus on vulnerabilities that are truly relevant to your product.

Cybellum enables organizations to keep the products and devices they build compliant, and secure for life, from design to development to production and beyond – including all their open source components.

Learn how to secure medical devices against open source risks, with Cybellum’s Product Security Platform.