Implementing Outside Software in Medical Devices

SOUP and SBOM medical devices

The development process for a new product can be difficult and lengthy, but it can be eased by safely including external software in the finished product. It is often far more efficient to use a product designed specifically for a certain function or use case instead of dedicating time to developing the functionality from scratch. Unfortunately, it can be much harder to audit the security of someone else’s software. This is a critical step, as keeping every device aspect secure is important to maintain comprehensive security. The risk can quickly become catastrophic when developing medical devices specifically, making security even more important.

FDA Guidelines For Off-The-Shelf Software

The FDA has strict guidelines for integrating outside software in medical devices. Safely using SOUP, or Software Of Unknown Provenance, in newly developed devices involves using secure SOUP and accounting for the abuse of intended functionality. Properly preparing documentation to follow this process involves careful analysis of how the device works, how any SOUP works, and its intended use case. This is where the tester’s expertise comes into play, as thinking with an attacker’s mentality can guide the development of potential attack paths.

Due to the complexity and variety that can come up in the development of medical devices, the range of external software that can be implemented is massive. Many products, such as components being used to create a web interface, will introduce potential vulnerabilities that may be very familiar to many penetration testers. Other components being used for specific, niche functionalities of the device will likely introduce a unique attack surface.

Analyzing SOUP security typically begins with SBoM or Software Bill of Materials generation. This provides a list of what software components are being integrated into the device and allows for further analysis of what could be exploited in the unique attack surface of the device. SBoM generation is greatly assisted by careful documentation from the development team creating the medical device’s software. No matter how thorough the documentation is, it is still important to carefully comb through the code base and scan it for any external software.

This can quickly become a complicated process, as often, external software will include even more external software with less strict security requirements. Since doing this manually can be a lengthy process, SBoM generation is often assisted with automated tools that scan static code along with dynamic, compiled code to identify these dependencies. This can help streamline the vulnerability identification process and ultimately fast-track the security process.

Vulnerability Mitigation

Once software components are analyzed, the next step is to find solutions for any insecure ones. Crafting solutions to mitigate software vulnerabilities can take some creative thinking, as removing a vulnerable component may not always be possible. As with most others, this phase of the security process will require close collaboration with the security tester and the client. By working together and fully understanding the device’s needs, it will then be possible to craft a solution that amplifies the device’s security without sacrificing functionality.

It is often just as simple as updating the external component to the latest version. This simple solution may be overlooked, especially in lengthy development processes. This can be due to the rate at which new vulnerabilities are discovered, meaning that a secure component at the start of development might have had major problems identified shortly after. Whenever SOUP is added to the development plan, monitoring the software and ensuring that vulnerabilities do not arise during development can be a good idea.

While the easy fix may often be possible, sometimes that is not the case. Maybe the maintainers have abandoned support for a crucial component, or fixes are not coming around fast enough. In cases like these, other solutions have to be found. That may be modifying how the software is used to mitigate a vulnerable aspect, identifying an alternative that meets the same goal, or finding a custom approach to try and remediate the problem. Again, this is where collaboration between testers and developers is vital.

Pass The FDA Requirements With The Help Of Blue Goat Cyber

Our team can work with you to meet the latest FDA requirements and push your product to market smoothly and safely. We are experienced in securing many different types of medical devices and can work with you to find custom solutions to fit your needs. Contact us to schedule a consultation.

Blog Search

Social Media