SOUP

Software of Unknown Provenance (SOUP), also referred to as "Off-The-Shelf Software" (OTS), is software that exists independently and was not developed specifically for incorporation into a particular medical device. SOUP is ubiquitous in modern medical devices, ranging from operating systems to third-party libraries, and requires special risk management and qualification under IEC 62304.

IEC 62304 definition:

SOUP is defined as:
"Software item that is already developed and generally available and that has not been developed for the purpose of being incorporated into the medical device (also known as 'off-the-shelf software') or software previously developed for which adequate records of the development process are not available."

Key characteristics:
- Not developed specifically for your medical device
- Development process not under manufacturer's control
- Source code may or may not be available
- May be commercial, open-source, or freeware
- Provenance (origin and development history) may be unknown or limited

Examples of SOUP in medical devices:

Operating systems:
- Commercial: Windows Embedded, VxWorks, QNX, Integrity RTOS
- Open-source: Linux (various distributions), FreeRTOS, Zephyr RTOS
- Mobile: Android, iOS (for SaMD applications)

Middleware and frameworks:
- Communication: OpenSSL, Boost.Asio, cURL, gRPC
- Database: SQLite, PostgreSQL, MySQL Embedded
- GUI frameworks: Qt, wxWidgets, GTK+
- Serialization: JSON libraries (RapidJSON, nlohmann/json), XML parsers

Libraries and utilities:
- Compression: zlib, libjpeg, libpng
- Cryptography: OpenSSL, libsodium, mbedTLS
- Math and scientific: Eigen, FFTW, BLAS/LAPACK
- Image processing: OpenCV, ITK (Insight Toolkit), VTK (Visualization Toolkit)

Development tools (used to build software):
- Compilers: GCC, Clang, MSVC
- Build systems: CMake, Make, Gradle
- Testing frameworks: Google Test, JUnit, pytest

Note: Development tools used only at build time may have reduced SOUP requirements compared to runtime SOUP, but IEC 62304 still recommends configuration management.

Why SOUP is used in medical devices:

Practical reasons:
- Cost-effective: Avoid reinventing common functionality
- Time-saving: Accelerate development using proven components
- Expertise leverage: Use specialized libraries developed by experts
- Standards compliance: Many SOUP components implement industry standards (TCP/IP, DICOM, HL7)
- Maturity: Well-established SOUP often more reliable than custom code

Challenges:
- Unknown quality: Development process not controlled or visible
- Unknown defects: Bugs and vulnerabilities may exist
- Lack of documentation: May have incomplete technical documentation
- Update dependency: Manufacturer depends on SOUP supplier for updates
- Obsolescence risk: SOUP may reach end-of-life, requiring replacement
- Licensing: Open-source licenses may impose obligations (GPL, LGPL)

IEC 62304 requirements for SOUP:

SOUP risk classification:
SOUP is not separately classified; it inherits the software safety class of the system containing it:
- Class C SOUP: Used in Class C (high-risk) medical device software
- Class B SOUP: Used in Class B (medium-risk) medical device software
- Class A SOUP: Used in Class A (low-risk) medical device software

Higher software safety classes impose more stringent SOUP requirements.

Section 5.1.1 - SOUP identification:
Manufacturers must document:
- Title and manufacturer/supplier of SOUP
- Version identifier (exact version number)
- How SOUP is used in medical device
- Which requirements SOUP fulfills (functional and non-functional)
- Hardware and software needed for SOUP operation
- SOUP software safety classification

Section 7.1 - SOUP integration planning:
Development plan must address:
- List of SOUP items to be integrated
- SOUP version control and configuration management
- Verification and testing approach for SOUP
- Known anomalies (bugs) in SOUP and mitigation plan

Section 8 - SOUP configuration management:
Maintain configuration management for SOUP:
- SOUP identification (name, version, source)
- SOUP integrity verification (checksums, digital signatures)
- SOUP changes and updates tracked
- Configuration baseline for each medical device software release

Section 5.3 - SOUP anomaly assessment:

Requirement:
Evaluate published SOUP anomalies (bugs, defects, vulnerabilities) and determine:
- Could the anomaly contribute to a hazardous situation?
- If yes, document in risk management file
- Implement risk control measures (workarounds, testing, monitoring)

Sources for SOUP anomalies:
- Vendor release notes and known issues lists
- CVE (Common Vulnerabilities and Exposures) databases
- Public bug trackers (GitHub Issues, JIRA, Bugzilla)
- Security advisories (CERT, NVD, vendor security bulletins)
- User forums and community discussions

Section 5.1.3 - SOUP qualification testing:

Purpose:
Demonstrate that SOUP is suitable for its intended use in the medical device.

Qualification testing includes:
- Functional testing: Verify SOUP performs required functions correctly
- Interface testing: Verify integration points with medical device software
- Performance testing: Verify SOUP meets performance requirements (speed, memory, throughput)
- Robustness testing: Test SOUP behavior under error conditions, invalid inputs, boundary cases
- Security testing: Verify SOUP doesn't introduce security vulnerabilities

Test coverage considerations:
- Higher software safety class → more thorough testing required
- Test SOUP features actually used by medical device (don't need to test unused features)
- Consider risk-based testing: test high-risk SOUP functions more extensively

Document qualification results:
- Test plan and test cases for SOUP
- Test results and pass/fail criteria
- Known limitations or anomalies discovered
- Conclusion that SOUP is suitable for intended use

Risk management for SOUP:

ISO 14971 integration:
SOUP must be considered in device risk management:

Hazard identification:
- Software bugs in SOUP causing device malfunction
- SOUP vulnerabilities exploited by attackers (cybersecurity)
- SOUP incompatibility with other components
- SOUP performance limitations causing device failure
- SOUP end-of-life causing long-term support issues

Risk controls for SOUP:
- Qualification testing: Verify SOUP suitability
- Anomaly monitoring: Track known SOUP defects and mitigations
- Input validation: Protect SOUP from invalid inputs
- Error handling: Gracefully handle SOUP errors
- Fallback mechanisms: Redundancy or fail-safe for critical SOUP
- Cybersecurity controls: Harden SOUP, apply patches, restrict access
- Version pinning: Use specific tested SOUP versions, not "latest"

SOUP selection criteria:

When selecting SOUP, consider:

Maturity and reputation:
- Well-established SOUP with long track record
- Active development and maintenance
- Large user base providing feedback
- Vendor reputation and financial stability

Documentation quality:
- Clear API documentation
- User guides and tutorials
- Known issues and limitations documented
- Security advisories and patch management

Support and maintenance:
- Active vendor or community support
- Regular updates and bug fixes
- Security patch availability
- End-of-life policy transparent

Functional suitability:
- SOUP meets device requirements
- Performance adequate for medical use
- Configurable or customizable as needed
- Licensing compatible with device commercialization

Risk and compliance:
- Known vulnerabilities acceptable or mitigatable
- Compatible with device software safety classification
- No critical unresolved bugs affecting medical use
- License terms acceptable (proprietary, open-source obligations)

SOUP documentation requirements:

SOUP file or register:
Maintain a centralized SOUP inventory including:
- SOUP name and description
- Supplier/vendor and source (download URL, commercial license)
- Version number and release date
- Intended use in medical device
- Software safety classification
- Known anomalies and mitigation strategies
- Qualification testing summary and results
- License information and obligations
- Dependencies (SOUP that depends on other SOUP)
- Configuration and build options used
- Responsible person or team for SOUP management

Design History File (DHF) inclusion:
- SOUP selection rationale
- SOUP qualification test records
- SOUP risk assessment
- SOUP configuration management records

Risk Management File:
- SOUP-related hazards and risks
- Risk controls implemented for SOUP
- Verification of risk control effectiveness

SOUP updates and changes:

When SOUP version changes:
Evaluate impact per IEC 62304 Section 6 (Maintenance):
- Assess changes in SOUP functionality, interfaces, or performance
- Determine if change affects device safety or effectiveness
- Perform risk assessment for SOUP update
- Conduct regression testing to verify no adverse impact
- May require re-qualification testing depending on scope of change
- Update SOUP documentation (version, anomalies, qualification)

Major SOUP updates:
- New SOUP version with significant changes: treat as new SOUP
- Full qualification testing required
- Update risk analysis
- May trigger regulatory submission (510(k), design change notification)

Minor SOUP updates (patches, bug fixes):
- Review release notes for changes
- Assess impact on device
- Regression testing
- Update SOUP records

SOUP end-of-life:
- Plan for SOUP replacement if vendor discontinues support
- Assess risk of unsupported SOUP (no security patches)
- Budget for migration to alternative SOUP
- Communicate EOL risk to customers

SOUP and cybersecurity:

Vulnerabilities in SOUP:
Common source of medical device cybersecurity vulnerabilities:
- Unpatched SOUP with known CVEs
- Insecure default configurations
- Outdated cryptographic algorithms
- Memory corruption bugs (buffer overflows, use-after-free)

Cybersecurity best practices for SOUP:
- Vulnerability scanning: Regularly scan SOUP for known CVEs using tools like Trivy, Grype, or commercial scanners
- Timely patching: Apply security patches promptly when available
- Configuration hardening: Disable unused SOUP features, use secure settings
- Network isolation: Limit SOUP access to network resources
- SBOM (Software Bill of Materials): Maintain SBOM to track SOUP and identify vulnerabilities
- Penetration testing: Test for exploitable SOUP vulnerabilities in device context

FDA cybersecurity guidance and SOUP:
FDA expects manufacturers to:
- Identify all SOUP components
- Maintain SBOM including SOUP
- Monitor SOUP for vulnerabilities
- Develop plan for addressing SOUP vulnerabilities post-market
- Coordinate vulnerability disclosure with SOUP suppliers

Open-source SOUP considerations:

Benefits of open-source SOUP:
- Source code available for review and modification
- Transparent development process (GitHub, public bug trackers)
- Community support and rapid bug discovery
- No licensing fees
- Widely used and tested by large community

Challenges of open-source SOUP:
- No formal vendor support (community-based)
- Licensing obligations (GPL, LGPL may require source disclosure)
- Variable code quality depending on project maturity
- Maintenance burden if project abandoned
- Potential IP risks if license compliance not managed

Popular open-source SOUP in medical devices:
- Linux: Widely used for embedded systems, extensive hardware support
- OpenSSL: Cryptography and TLS communication, but requires careful patching (history of serious vulnerabilities like Heartbleed)
- Qt: GUI framework, dual-licensed (open-source GPL or commercial)
- SQLite: Lightweight embedded database, public domain
- Boost: Comprehensive C++ libraries, high-quality, extensively tested

Commercial SOUP considerations:

Benefits of commercial SOUP:
- Formal vendor support and SLAs
- Professional documentation and training
- Liability and warranty (to some extent)
- Regular updates and long-term roadmap
- Compliance with industry standards (FDA-listed SOUP, safety-certified RTOS)

Challenges of commercial SOUP:
- Licensing costs (per-unit royalties, upfront fees)
- Source code may not be available (black-box)
- Vendor dependency (lock-in)
- Limited transparency into defects or development process
- Vendor may discontinue product

Examples of commercial SOUP:
- VxWorks, QNX: Safety-certified real-time operating systems
- Integrity RTOS: High-assurance OS for safety-critical applications
- MATLAB/Simulink: Model-based design for algorithms (generated code is SOUP)
- Proprietary communication stacks: Bluetooth, Wi-Fi, cellular protocol implementations

SOUP and Software Bill of Materials (SBOM):

SBOM for SOUP transparency:
SBOM catalogs all SOUP in device:
- Enables rapid identification of vulnerable SOUP
- Supports post-market vulnerability management
- Facilitates communication with healthcare providers about device security
- Required by FDA cybersecurity guidance

Maintaining SBOM for SOUP:
- Automated tools (Syft, Tern, CycloneDX generators) scan software and generate SBOM
- Include SOUP name, version, supplier, and dependencies
- Update SBOM when SOUP versions change
- Provide SBOM to customers for their cybersecurity programs

Best practices for SOUP management:

Establish SOUP policy:
- Define process for selecting, evaluating, and approving SOUP
- Assign roles and responsibilities for SOUP management
- Set criteria for SOUP acceptance (maturity, support, licensing)

Maintain SOUP inventory:
- Centralized SOUP register or database
- Track all SOUP across product portfolio
- Version control SOUP alongside device software

Conduct SOUP risk assessment:
- Identify SOUP-related hazards
- Implement and verify risk controls
- Re-assess risk when SOUP changes

Qualify SOUP rigorously:
- Develop SOUP-specific test plans
- Test SOUP in device context
- Document qualification results
- Don't assume SOUP works correctly without testing

Monitor SOUP continuously:
- Subscribe to security advisories for SOUP
- Track SOUP vendor announcements and roadmaps
- Scan for vulnerabilities regularly (CVE databases)
- Plan for SOUP updates and EOL

Document SOUP thoroughly:
- SOUP identification and version
- Intended use and rationale for selection
- Qualification testing and results
- Known anomalies and mitigations
- Risk assessment and controls
- License compliance

Plan for SOUP lifecycle:
- Budget for SOUP license costs (if commercial)
- Plan for SOUP updates and re-qualification
- Identify alternative SOUP in case of EOL
- Allocate resources for SOUP maintenance

SOUP is an essential but challenging aspect of modern medical device software development. By following IEC 62304 requirements and implementing robust SOUP management practices, manufacturers can leverage the benefits of existing software while maintaining patient safety and regulatory compliance. Proper SOUP management is not optional—it is a fundamental element of medical device software quality and risk management.