Understanding SBOM, SOUP, COTS, and OTS in Medical Device Cybersecurity

In the connected world of healthcare technology, understanding the software inside your medical device is critical—not just for development, but also for compliance and patient safety. This blog post explores four foundational software concepts: SBOM, SOUP, COTS/OTS, and their role in regulatory frameworks like the FDA cybersecurity requirements and IEC 62304.

SBOM (Software Bill of Materials)

Definition: An SBOM is a formal record of all software components—open-source libraries, proprietary code, firmware, APIs, and binaries—used in a product.

Why it matters:

• Helps identify vulnerable components (e.g., if a library like log4j is included).
• Supports faster incident response in the face of supply chain attacks.
• Required under FDA Section 524B as of March 2023.

Real-World Example:
A Class II infusion pump uses third-party time-synchronization code. If a CVE emerges in that library, a complete SBOM allows immediate impact assessment and patch prioritization.

Regulations Requiring SBOM:

• FDA (FD&C Act Section 524B)
• Executive Order 14028 (for federal procurement)
• Cyber Resilience Act (EU)

‍

SOUP (Software of Unknown Provenance)

Definition: SOUP refers to software components not developed under a documented medical software lifecycle process. These include:

• Open-source libraries with limited audit trails
• AI/ML models trained externally
• Legacy drivers or firmware

Risks:

• Unknown security history or unpatched vulnerabilities
• Lack of development traceability
• May include non-compliant cryptographic modules or insecure APIs

How to handle SOUP (per IEC 62304):

• Perform risk analysis specific to the device’s safety classification
• Validate functionality and safety impacts
• Monitor for public vulnerabilities (e.g., through NVD feeds)
• Document mitigations for any unacceptable risk

Example: A hospital-grade ECG monitor uses a graphing package pulled from GitHub. If that library fails under certain inputs, the waveform may display incorrectly, affecting diagnosis.

‍

OTS/COTS Software

Definitions:

• OTS (Off-the-Shelf): Any pre-built software not specifically designed for the medical device in question.
• COTS (Commercial Off-the-Shelf): A subset of OTS, referring specifically to commercially licensed software (e.g., Windows OS, Oracle DB).

Key Difference from SOUP:
COTS software can be considered “known provenance” if vendor documentation exists. However, when lifecycle processes are unclear or undocumented, even COTS becomes SOUP.

Risks & Mitigations:

• Lack of source code or patch control
• Vendor lifecycle decisions may affect device safety
• FDA expects “adequate assurance” that the OTS software won’t degrade performance or safety

Regulatory Guidance:

• FDA’s “Guidance on the Content of Premarket Submissions for Software Contained in Medical Devices” specifically addresses COTS risk documentation.
• IEC 62304 requires validation even when the software is not modified.

‍

Regulation Round-Up

• SBOM
  
  • Required for FDA (2023), FD&C Act §542B
  • Comprehensive software component inventory; include metadata like support and vuln status
• SOUP Management
  
  • Required for IEC 62304, FDA Guidance
  • Risk analysis, validation, patch management process
• OTS Usage
  
  • Required for IEC 62304, FDA OTS Guidance
  • Assess risk, document development history, verify safety in mission‑critical use

‍

Why It All Matters

• Proactive Risk Mitigation: SBOM + SOUP/OTS vigilance allows faster vulnerability detection and patching, reducing exposure time.
• Regulatory Compliance: The FDA’s CBOM/SBOM mandates and IEC 62304’s SOUP/OTS requirements are enforceable—non-compliance risks rejection or fines.
• Enhanced Patient Safety: Software vulnerabilities in medical devices can lead to malfunctions or hacking, compromising patient health.
• Supply Chain Resilience: Knowing components (via SBOM) and their origins (SOUP/OTS provenance) strengthens security posture across lifecycle.

‍

⚙️ Manufacturer Best Practices

1. Automate SBOM generation via Software Composition Analysis (SCA) tools.
2. Maintain CBOMs with support timelines and patch responsibilities.
3. Create a SOUP registry that includes rationale for usage and risk mitigation plans.
4. Work with COTS vendors to secure long-term support or equivalent alternatives.
5. Monitor public vulnerability feeds (like CVE/NVD) for both known and SOUP software.
6. Tie software risk into ISO 14971 processes to ensure coverage from a patient safety angle.

‍

In a regulated industry like medical devices, compliance is not just about paperwork—it’s about patient safety. Building secure, reliable devices starts with understanding what software you're using, where it came from, and how it behaves under adverse conditions.

Whether you’re building next-gen diagnostic wearables or implantable systems, get your SBOM, SOUP, and COTS strategy right—and stay ahead of regulators, threats, and competitors alike.

‍

‍