Software Bill of Material (SBOM) for Medical Devices

Today’s medical devices rarely run on completely custom code. Instead, developers integrate proven third-party components to handle common tasks efficiently. Your device might use FreeRTOS for real-time operations, LwIP for network connectivity, or TensorFlow for data analysis. Each of these components brings its own development history, update cycle, and potential security considerations.

This reliance on third-party code, while efficient, creates a complex web of dependencies. A single feature might require multiple libraries, each with its own dependencies, creating a cascade of components that all need to be tracked and managed. For medical devices, where safety is paramount, understanding these dependencies isn’t just good practice – it’s essential for compliance with the IEC 62304 standard.

SOUP: Managing Unknown Software Elements

In the medical device world, third-party software components fall under a specific category: Software of Unknown Provenance (SOUP). This includes any software component not developed under your full quality system – whether it’s open-source libraries like MySQL, commercial components, or operating system elements.

IEC 62304, the international standard for medical device software lifecycle processes, places specific requirements on how we handle SOUP components. Section 7.1.3 mandates regular reviews of all SOUP elements for:

• – Known defects
• – Available updates
• – Security vulnerabilities
• – License changes

These requirements make maintaining an accurate SBOM not just helpful, but necessary for compliance and safety.

Comprehensive SBOM Elements for Medical Devices

A well-maintained SBOM documents essential information for each software component, ensuring compatibility, security, and compliance across the medical device lifecycle. Key elements to track include:

Component Type	What to Track	Why It Matters
Core Libraries	Version number, source, license type	Ensures compatibility and compliance
Operating System Components	Security patches, known vulnerabilities	Maintains system security
Communication Stacks	Protocol versions, security features	Ensures safe data transmission
Processing Engines	Performance limitations, compatibility	Guarantees reliable operation
User Interface Components	Accessibility features, known issues	Ensures usability and safety

By tracking these details, an SBOM ensures that all components within the device software are documented and monitored for security risks and regulatory compliance.

Real-World Examples of SBOM Entries

To illustrate, here are realistic examples of what entries might look like in an SBOM for a medical device:

Component Name	Component Type	Version	Source	License	Known Issues	Last Update	Compliance Notes
LwIP Network Stack	Communication Stack	2.1.2	Open Source	BSD	CVE-2022-12345 (resolved)	2023-05-12	Requires quarterly review for new CVEs
MySQL Database	Core Library	8.0.25	Open Source	GPL	Minor data consistency bug	2023-02-15	Compatible with database encryption protocol
TensorFlow	Processing Engine	2.4.1	Open Source	Apache 2.0	Known memory leak issue	2022-12-01	Reviewed for processing limits in device app

Each SBOM entry includes:

• – Component Type: Categorizes the component (e.g., library, driver, middleware) for easier tracking
• – Known Issues: Specific vulnerabilities or issues, with details on their status (e.g., resolved or pending)
• – Last Update: The date of the most recent update or patch, ensuring all components are as current as possible
• – Compliance Notes: Brief but actionable notes on compliance requirements, helping developers maintain regulatory alignment

Benefits of an SBOM for Compliance and Cybersecurity

For medical devices, an SBOM not only simplifies compliance with IEC 62304 but also strengthens cybersecurity practices. By maintaining a detailed inventory of all software components, manufacturers can quickly identify and resolve security vulnerabilities associated with third-party code. This proactive approach minimizes risks to patient safety and builds resilience against cyber threats, supporting long-term device reliability.

Furthermore, an SBOM supports regular audits and assessments, enabling developers to make informed decisions about software updates and replacements. Whether using open-source libraries, proprietary modules, or a mix of both, having a well-maintained SBOM is essential to comply with evolving regulatory requirements and uphold high safety standards.

Moving Forward with SBOM Implementation

Creating and maintaining an effective SBOM system requires expertise in both medical device development and software lifecycle management. At DojoFive, we understand these challenges and have helped numerous medical device manufacturers establish robust SBOM practices that ensure both compliance and efficiency.

To learn more, check out our [comprehensive guide to IEC 62304 compliance]. If you’re ready to simplify the complexities of medical device software development, we’re here to help.