SBOM

A Software Bill of Materials (SBOM) is a nested inventory, analogous to a list of ingredients for software, that catalogs all components used in building a software application or embedded in a medical device. For medical devices, SBOMs are increasingly required by regulators to enhance cybersecurity, enable vulnerability tracking, and ensure supply chain transparency.

Purpose and importance of SBOM:

Cybersecurity and vulnerability management:
- Rapidly identify vulnerable components when new CVEs (Common Vulnerabilities and Exposures) are disclosed
- Assess device exposure to known security flaws
- Prioritize patching and remediation efforts
- Respond quickly to zero-day vulnerabilities affecting third-party components

Supply chain transparency:
- Document all open-source and commercial software components
- Track software origins and provenance
- Identify license compliance obligations
- Manage software dependencies and relationships

Regulatory compliance:
- Meet FDA cybersecurity premarket and post-market expectations
- Align with EU MDR cybersecurity requirements under General Safety and Performance Requirements
- Demonstrate software transparency and accountability
- Support incident response and Field Safety Corrective Actions

Post-market surveillance:
- Monitor software components for emerging risks
- Track component updates and end-of-support timelines
- Plan for software maintenance and upgrades
- Communicate effectively with users about vulnerabilities

Regulatory drivers for SBOM:

FDA Cybersecurity Guidance (2023):
"Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions" recommends:
- Manufacturers maintain SBOM for all software and firmware
- SBOM provided to users (healthcare facilities) to enable vulnerability management
- SBOM updated throughout product lifecycle
- SBOM includes commercial, open-source, and off-the-shelf (OTS) software

Executive Order 14028 (2021):
U.S. Executive Order on Improving the Nation's Cybersecurity:
- Directs federal agencies to require SBOMs for software procurement
- Establishes minimum elements for SBOMs (NTIA framework)
- Accelerates adoption of SBOMs across industries including medical devices
- Enhances software supply chain security nationally

EU Cyber Resilience Act (proposed):
Proposes requirements for software transparency:
- Manufacturers provide SBOM for products with digital elements
- SBOM supports vulnerability disclosure and patching
- Aligns with global movement toward software supply chain security

NTIA minimum elements for SBOM:

The U.S. National Telecommunications and Information Administration (NTIA) defines minimum data fields:

1. Supplier name:
- Name of entity creating, defining, or identifying the component
- Can be commercial vendor, open-source project, or internal developer

2. Component name:
- Common or widely recognized name of the component
- Examples: "OpenSSL", "Linux Kernel", "Qt Framework"

3. Version of the component:
- Specific version identifier
- Examples: "1.1.1k", "5.10.17", "6.2.3"
- Include patch level if applicable

4. Other unique identifiers:
- Package URL (PURL) for software packages
- CPE (Common Platform Enumeration) for vulnerability matching
- SWID (Software Identification) tags
- Hash values (SHA-256) for file integrity

5. Dependency relationship:
- Describes relationships between components
- Identifies direct vs. transitive dependencies
- Maps component hierarchy (which component includes which)

6. Author of SBOM data:
- Entity generating the SBOM
- Typically the device manufacturer or software supplier
- Contact information for SBOM questions

7. Timestamp:
- Date and time when SBOM was created
- Should be updated when software changes
- Critical for tracking SBOM currency

SBOM formats and standards:

SPDX (Software Package Data Exchange):
- ISO/IEC 5962:2021 standard
- Developed by Linux Foundation
- Supports multiple serialization formats (JSON, XML, YAML, RDF, tag-value)
- Includes license compliance information
- Widely adopted in open-source communities

CycloneDX:
- OWASP-developed standard
- Designed specifically for application security and supply chain component analysis
- Supports JSON and XML formats
- Includes vulnerability and license information
- Integrates with DevSecOps tools

SWID (Software Identification) Tags:
- ISO/IEC 19770-2:2015 standard
- XML-based format
- Focuses on software asset management
- Used in enterprise IT environments

Most medical device manufacturers use SPDX or CycloneDX due to their comprehensive data models and tool ecosystem.

Creating an SBOM for medical devices:

Step 1: Inventory all software components
Identify all software in the device:
- Operating system (Linux, Windows Embedded, real-time OS)
- Third-party libraries (OpenSSL, Qt, Boost)
- Open-source components (Apache, GNU utilities)
- Commercial software (database engines, communication stacks)
- Internally developed software (application code, drivers)
- Firmware and bootloaders

Step 2: Determine component versions
For each component:
- Exact version number
- Build date or commit hash if available
- Patch level or service pack
- Configuration or compilation options that affect functionality

Step 3: Identify dependencies
Map relationships:
- Direct dependencies (components your software directly uses)
- Transitive dependencies (dependencies of your dependencies)
- Runtime dependencies (required at execution)
- Build-time only dependencies (needed for compilation but not runtime)

Step 4: Gather component metadata
For each component:
- Supplier/vendor name
- Official component name
- License information (GPL, MIT, Apache, proprietary)
- Known vulnerabilities (CVE numbers if applicable)
- Component hash for verification
- Download location or package URL

Step 5: Generate SBOM using tools
Use automated SBOM generation tools:
- Syft (Anchore) - scans container images and filesystems
- Tern (VMware) - analyzes Docker containers
- FOSSology - license and component scanning
- Black Duck (Synopsys) - commercial software composition analysis
- WhiteSource (Mend) - open-source vulnerability management
- SPDX tools - official SPDX generators and validators

Step 6: Validate and verify SBOM
- Ensure all components captured
- Verify version accuracy
- Check for completeness of dependency relationships
- Validate SBOM format compliance (SPDX or CycloneDX schema)

Step 7: Maintain and update SBOM
- Update SBOM when software changes
- Track component updates and EOL timelines
- Re-generate SBOM for each device software release
- Version-control SBOMs alongside software builds

SBOM in medical device lifecycle:

Design and development:
- Document component selection rationale
- Assess component security posture
- Identify components with known vulnerabilities
- Plan for component updates and maintenance

Verification and validation:
- Verify SBOM completeness
- Test component integration
- Validate security of components
- Ensure license compliance

Premarket submission (FDA 510(k), PMA, De Novo):
- Include SBOM or SBOM summary in cybersecurity documentation
- Describe SBOM maintenance plan
- Explain vulnerability monitoring process
- Demonstrate component risk assessment

Manufacturing and release:
- Generate SBOM for each software version
- Include SBOM in release documentation
- Provide SBOM to customers (healthcare facilities)
- Archive SBOM with software release records

Post-market surveillance:
- Monitor components for new vulnerabilities (CVE databases)
- Assess impact of disclosed vulnerabilities on device
- Determine need for software updates or patches
- Communicate vulnerabilities and mitigations to users

Incident response:
- Use SBOM to rapidly identify affected components
- Assess exploitability and patient risk
- Plan remediation (patch, workaround, mitigation)
- Report to regulators if required (Field Safety Corrective Action)

SOUP (Software of Unknown Provenance) and SBOM:

SOUP management per IEC 62304:
SBOM supports SOUP management requirements:
- Identification: SBOM lists all SOUP components
- Version tracking: SBOM captures exact SOUP versions
- Risk analysis: SBOM enables assessment of SOUP-related risks
- Qualification: SBOM supports SOUP testing and validation planning
- Updates: SBOM tracks when SOUP versions change

Examples of SOUP in medical devices:
- Operating systems (Linux, VxWorks, QNX)
- Communication libraries (OpenSSL, cURL, Boost.Asio)
- Database engines (SQLite, PostgreSQL)
- GUI frameworks (Qt, wxWidgets)
- Compression libraries (zlib, libjpeg)
- Scripting engines (Python, Lua)

SBOM and cybersecurity risk management:

Vulnerability scanning:
- Compare SBOM against CVE databases (NVD, MITRE)
- Identify known vulnerabilities in components
- Automated tools (Grype, Trivy, Clair) scan SBOMs
- Prioritize vulnerabilities by severity (CVSS score) and exploitability

Threat modeling:
- Use SBOM to identify attack surface
- Assess risks from vulnerable components
- Model potential exploit scenarios
- Determine risk mitigation strategies

Patching and remediation:
- Identify affected components from SBOM
- Assess feasibility of updating component
- Test compatibility of updated component
- Release software update with updated SBOM

End-of-life and obsolescence:
- Track component end-of-support dates via SBOM
- Plan for component replacements before EOL
- Migrate away from unsupported components
- Communicate EOL risks to customers

Sharing SBOMs with healthcare providers:

FDA expectations:
Manufacturers should provide SBOMs to customers:
- Enable healthcare facilities to manage device vulnerabilities
- Support hospital cybersecurity programs
- Allow informed procurement decisions
- Facilitate vulnerability disclosure coordination

SBOM delivery formats:
- Machine-readable (SPDX JSON, CycloneDX JSON) for automated processing
- Human-readable summary for manual review
- Hosted online portal for SBOM access
- Included in product documentation or technical files

Protecting proprietary information:
Balance transparency with trade secret protection:
- Provide component names and versions without disclosing proprietary algorithms
- Summarize internally developed components at appropriate granularity
- Exclude sensitive configuration details
- Use non-disclosure agreements if detailed SBOM sharing required

SBOM tools and ecosystem:

SBOM generation tools:
- Syft - Open-source, generates SBOMs from container images and filesystems
- Tern - Analyzes containers layer-by-layer for components
- CycloneDX CLI - Generates CycloneDX SBOMs
- SPDX SBOM Generator - Official SPDX tool

SBOM analysis and vulnerability scanning:
- Grype - Scans SBOMs for vulnerabilities
- Trivy - Container and SBOM vulnerability scanner
- Dependency-Track - SBOM and vulnerability management platform
- OSS Index - Free vulnerability database lookup

Commercial software composition analysis (SCA):
- Black Duck (Synopsys) - Comprehensive SCA and license compliance
- WhiteSource (Mend) - Open-source security and license management
- Snyk - Developer-focused vulnerability scanning
- Sonatype Nexus - Repository and component management

Challenges and best practices:

Challenges:
- Capturing all dependencies, especially transitive ones
- Keeping SBOM updated as software evolves
- Managing SBOM complexity for large systems
- Balancing transparency with trade secret protection
- Integrating SBOM generation into build pipelines
- Training teams on SBOM creation and use

Best practices:
- Automate SBOM generation in CI/CD pipeline
- Version-control SBOMs alongside source code
- Regularly scan SBOMs for vulnerabilities
- Establish SBOM review and approval process
- Provide SBOMs to customers in accessible format
- Train software teams on SBOM importance and maintenance
- Integrate SBOM data into risk management and quality systems
- Plan for component obsolescence and updates
- Participate in industry SBOM initiatives and standards development

International perspectives:

USA FDA:
- Recommends SBOM in cybersecurity premarket submissions
- Expects manufacturers to maintain and update SBOMs
- Encourages sharing SBOMs with healthcare providers
- Aligns with NTIA minimum elements

EU:
- Cybersecurity addressed in MDR Annex I General Safety and Performance Requirements
- Proposed Cyber Resilience Act may mandate SBOMs
- MDCG guidance on cybersecurity mentions software transparency

Other regions:
- Canada, Australia, Japan increasingly recognizing SBOM value
- Global harmonization efforts through IMDRF
- Industry best practice becoming international norm

SBOMs represent a paradigm shift toward software supply chain transparency and accountability. For medical device manufacturers, implementing robust SBOM practices enhances cybersecurity posture, enables proactive vulnerability management, and builds trust with regulators and healthcare providers. As cybersecurity threats evolve, SBOMs will become a foundational element of medical device safety and regulatory compliance.