In the realm of medical device security, several components are critical when integrating outside software. These elements relate to software dependencies, and there are cybersecurity implications. In this post, you’ll learn about SOUPs (software of unknown pedigree), SBOM (software bill of materials), and facades (software design patterns used in object-oriented programming).

What Is a SOUP?

A SOUP is any external code a development team uses without knowing its security. It’s a common practice, as it’s very rare for development to use internal solutions exclusively. External tools and open-source libraries are available to help programmers create almost anything.

The reason for their prevalent usage is that they save time and support efficiency in the development process. However, they do come with risk. Medical devices have specific requirements regarding SOUPs. To comply with the IEC 62304:2006 medical device software standard, regularly reviewing the status of SOUPs for known issues in code is mandatory. In addition, you must look for updates and fixes related to these weaknesses. This information lets you make more informed decisions and keep versions updated, compliant, and secure.

Keeping track of all these things involves SBOM.

What Is SBOM?

An SBOM is a formal and standardized list of all software components, dependencies, and metadata found within a medical device. It functions as an inventory with the aim to ensure transparency and mitigate risk. It would consist of:

• Open-source and third-party software elements
• Firmware and binaries
• Cloud resources
• APIs (application program interfaces) that the device interacts with or sends data to

Why Do Medical Devices Need SBOMs?

The FDA (Food and Drug Administration) enacted a new law that became effective on October 1, 2023. They updated Section 542B of the Food, Drug, and Cosmetic Act (FD&C Act). Part of the rules mandates that every device maker submit an SBOM within their FDA paperwork. It must be a complete list of all software components within the device.

The objective of the FDA was to improve the future of medical device security. An SBOM offers visibility into the software integrated into medical devices. It can also reduce the risk associated with using insecure code, a proactive measure to decrease supply chain attacks.

Medical Device SBOMs: FDA Wants More Than a Superficial List

Prior to the law, there was a tendency to put less thought and care into SBOMs. The FDA law goes much further than requiring SBOMs. It also requires manufacturers to submit plans for monitoring, identifying, and addressing cybersecurity vulnerabilities and exploits. It includes issuing patches for any severe weaknesses found as well.

To ensure you can do that with accuracy, you’ll need protocols and testing in place to assess:

• Risks regarding confidentiality, integrity, and availability
• System entry points
• Existing controls
• Data flows

Further, you’ll need to develop a threat tree, traceability matrix, standard operating procedures, and software architecture cybersecurity.

These plans would need the support of an experienced medical device cybersecurity firm. They would provide you with SOUP analysis and SBOM creation. Other services they can support include:

• Static and dynamic code analysis
• Recommended revisions to or new security controls
• Suggested design changes to reduce risk
• Medical device penetration tests

As you begin to improve how you use SOUP and the management of SBOMs, you may have questions.

FAQs About SBOMs for Medical Device Manufacturers

Those in the medical device industry often ask these questions about SBOMs:

Why Are SBOMs Important?

Besides being regulatory mandates, SBOMs are critical in understanding the components in the SOUPs used. According to the 2023 Open Source Security and Risk Analysis Report:

• 96% of all scanned codebases contain open source.
• 76% of code in codebases was open source.
• 84% of codebases had at least one vulnerability.
• 48% of codebases met the threshold for high vulnerabilities.
• Codebases were often out-of-date and did not contain the right version.
• The percentage of open-source code grew in the healthcare space.

Using open source is not an option, so medical device developers need a better way to uncover its weaknesses, as they have to respond to them.

What Benefits Does SBOM Adoption Offer to the Medical Device Industry?

Healthcare is a common and favorite target for cybercriminals. Connected medical devices on hospital networks offer a way in, with incidents increasing. Approximately 88% of cyberattacks in healthcare involve IoT medical devices. There is an average of 6.2 vulnerabilities per medical device, which fuels these attacks.

The FDA, in response to the growing threat, took action to make SBOM a part of a manufacturer’s responsibility. SBOMs make cybersecurity and vulnerability detection much easier to manage.

Can SBOMs Improve the Security of Medical Devices?

Connected medical devices have become essential in care delivery. These smart assets, such as pacemakers and insulin pumps, are making a difference in the lives of patients. With this opportunity also comes risk. Instead of helping, vulnerabilities can put patient lives at risk.

If these devices are going to continue to support better patient outcomes, SBOMs can be a pillar for better cybersecurity. They offer a comprehensive view of what’s inside, so the mystery of integrated software is no more.

How Do SBOMs Help with Supply Chain Security?

SBOMs are a benefit to the entire ecosystem—manufacturers, healthcare providers, and patients. They enable open communication about vulnerabilities across the entire supply chain. Developers get what they need to track software, which leads to earlier detection of issues. They can quickly issue updates to devices to mitigate threats.

How Do You Create an SBOM?

Here is a set of recommended steps to use:

• Analyze the security of external sources to locate all outside components that are in active use in your development environment. It’s a straightforward task but not an easy one. The larger the landscape, the more challenging it is. Simply keeping a list of dependencies can be unmanageable. To facilitate this, establish appropriate documentation standards.
• Track programs in use during build time and run time to ensure they’re complete. Look for calls to outside sources and trace their use. Often, this exercise delivers a more comprehensive list of code.
• Reiterate SBOMs regularly. Creating an SBOM isn’t a one-time exercise. Begin a new analysis every time there are major changes or new components added. It keeps documentation up-to-date and supports compliance. Even if the devices haven’t had any significant changes, you should still have a regular cadence of review.

Developing and maintaining your SBOM is critical, as the devices you’re creating have broad and public use. The impact of vulnerabilities can result in breaches, systems going offline, and ransomware. Having consistent practices for your SBOMs also streamlines FDA approval, getting devices to market faster.

Next, let’s review facades and their connection to medical device security.

What Are Facades?

Facades are a software design pattern that acts as an object in front-facing interfaces. They cover the more complex underlying and structural code, hence the name.

Facades are useful in these ways:

• Improving the readability and usability of software libraries by masking interactions and elements into a single API
• Delivering a context-specific interface for more functionality

Medical devices are complicated machines with lots of software, which is why facades are prevalent. The interface isolates other code from a library. The result is standard functionality, such as authenticating, reading, writing, and deleting.

Consider if you have to switch libraries because of a threat or other motivation. You can replace the facade module without having to touch the remaining code.

How Can Medical Device Manufacturers Control Vulnerabilities in External Components Successfully?

The main focus is always on being secure by design. It’s the framework for most manufacturers. You have your list of software components and knowledge around facade usage. This enables you to be more strategic and precise about looking at third-party sources. You don’t have direct control over these components, but you’re not without some influence.

The first strategy is to ensure you’re constantly updating vulnerable components to the most recent version. It’s fast but not always achievable. Dependency problems make this more difficult. For example, newer software updates may not work well with others, which could impact integrations and interoperability. Additionally, those new versions may not even be available.

It’s a complicated ecosystem. Problems arise, and solutions aren’t always feasible. You could try to find alternatives, yet they may not align with the features you need. There may also be extra expenses.

Another strategy is developing other ways to mitigate. In many cases, there is a single vulnerability that hackers would exploit that ties to specific functionality. So, you’d have to evaluate the value versus the risk. Workarounds may also be an option.

Get Help with Medical Device Cybersecurity and SBOMs

Managing device cybersecurity and SBOMs to meet FDA requirements is crucial but also complex and time-consuming. Testing devices, getting them to market, and ensuring they remain safe don’t have to be entirely on your shoulders. We can help. We’re experts in medical device security and have helped many in the industry get devices approved and maintain compliance. Contact our team to schedule a consultation.