Healthcare has a unique relationship with software supply chain security. When a vulnerability in a hospital's inventory management system gets exploited, the organization loses data and money. When a vulnerability in a medical device gets exploited, patients can be harmed.
That distinction — the connection between software security and patient safety — makes healthcare one of the most consequential sectors for SBOM adoption. It is also one of the most challenging, due to the complexity of medical device ecosystems, the length of device lifecycles, and the regulatory requirements that govern them.
The FDA Mandate
The Consolidated Appropriations Act of 2023 amended the Federal Food, Drug, and Cosmetic Act to require cybersecurity documentation — including SBOMs — for medical device premarket submissions. The FDA's premarket cybersecurity guidance, finalized in 2024, provides the implementation details.
The requirements are significant:
SBOMs for all software components. Every medical device submission must include an SBOM covering all software components, including third-party and open-source libraries. The SBOM must be in a machine-readable format (CycloneDX or SPDX).
Vulnerability assessment. The manufacturer must assess known vulnerabilities in all SBOM components and document their risk mitigation strategy.
Patch management plan. The submission must include a plan for addressing vulnerabilities discovered after market approval, including how SBOMs will be updated and how customers will be notified.
Coordinated vulnerability disclosure. Manufacturers must establish a coordinated vulnerability disclosure policy for their devices.
These requirements apply to all new premarket submissions. The FDA has signaled that it will increasingly expect similar documentation for device renewals and modifications.
The Hospital Perspective
Medical device manufacturers are the direct targets of FDA SBOM requirements, but hospitals and health systems are the organizations that need to operationalize the data.
A typical large hospital operates 10,000-15,000 networked medical devices from dozens of manufacturers. The devices range from MRI machines and infusion pumps to patient monitors and laboratory analyzers. Each device runs firmware and software with its own set of dependencies and vulnerabilities.
Before SBOMs, the hospital's biomedical engineering team had limited visibility into the software running on these devices. They knew the device model and firmware version, but not the specific open-source libraries embedded in the firmware. When a vulnerability like Log4Shell was announced, the process for determining which devices were affected was manual, slow, and incomplete.
SBOMs change this equation. With a machine-readable inventory of every device's software components, the hospital can:
- Instantly determine which devices contain the affected component
- Assess the severity based on the device's network exposure and function
- Prioritize patching or compensating controls
- Communicate the impact to clinical staff
The operational value is clear. The challenge is scaling it.
Practical Challenges
SBOM Quality Varies Wildly
Not all manufacturer-provided SBOMs are equal. Some are comprehensive, well-formatted documents that include transitive dependencies, version information, and package URLs. Others are shallow lists of top-level components that omit the dependency tree.
The FDA's requirements set a floor, but the floor is not high enough. An SBOM that lists "OpenSSL" without specifying the version is technically an SBOM but practically useless for vulnerability assessment.
Hospitals need a validation process — automated checks that verify SBOM completeness and quality before the data enters their asset management system.
Legacy Devices
The FDA mandate applies to new submissions. Devices already on the market — some of which were approved ten or more years ago — are not required to provide SBOMs. These legacy devices represent the majority of a typical hospital's installed base.
For legacy devices without manufacturer-provided SBOMs, hospitals have limited options:
- Request SBOMs from manufacturers. Some will comply voluntarily, especially if they have already built the capability for new submissions.
- Binary analysis. Tools that decompose firmware images and identify components can produce approximate SBOMs, though with lower accuracy than manufacturer-generated ones.
- Compensating controls. For devices where SBOMs are unavailable and cannot be generated, network segmentation, monitoring, and access controls become the primary defense.
Operational Technology Constraints
Medical devices operate under constraints that IT systems do not:
Uptime requirements. A critical care device cannot be taken offline for patching without a clinical replacement plan.
Validation requirements. Software changes to medical devices may require revalidation by the manufacturer or the hospital's clinical engineering team. A firmware update is not a simple apt-get upgrade.
Network restrictions. Many medical devices operate on isolated networks with limited connectivity, making automated patch deployment difficult.
These constraints mean that even when a vulnerability is identified through SBOM analysis, the remediation path is often longer and more complex than it would be for a standard IT system.
Building a Healthcare SBOM Program
For hospitals and health systems building an SBOM program from scratch, here is a practical approach:
Phase 1: New device procurement. Add SBOM requirements to your procurement contracts. Require SBOMs in CycloneDX or SPDX format, with transitive dependencies and version information. Validate SBOM quality before accepting delivery.
Phase 2: SBOM ingestion and analysis. Deploy tooling to ingest manufacturer SBOMs, correlate them with vulnerability databases, and link them to your asset inventory. The goal is to answer "which devices are affected?" within minutes of a new CVE announcement.
Phase 3: Legacy device assessment. Prioritize legacy devices by criticality and network exposure. Request SBOMs from manufacturers where possible. Use binary analysis for high-priority devices where manufacturer SBOMs are unavailable.
Phase 4: Continuous monitoring. Establish ongoing monitoring that alerts when new vulnerabilities affect components in your device SBOMs. Integrate with your existing vulnerability management workflow and clinical risk assessment process.
Phase 5: Vendor risk management. Use SBOM data as an input to vendor risk assessments. Manufacturers that produce high-quality SBOMs, respond quickly to vulnerability disclosures, and maintain active patch programs should be preferred over those that do not.
The Patient Safety Connection
The ultimate purpose of healthcare SBOM programs is patient safety. A hospital that can rapidly identify which infusion pumps are running a vulnerable version of an embedded web server and take appropriate action — patching, isolating, or replacing those devices — is protecting patients from potential harm.
This connection between software transparency and patient safety is not abstract. The WannaCry attack in 2017 disrupted hospital operations across the UK's NHS, leading to cancelled surgeries and diverted ambulances. Subsequent analysis revealed that many affected systems were running outdated software with known vulnerabilities. Better software inventory management — the kind that SBOMs enable — could have identified and mitigated the exposure before the attack.
How Safeguard.sh Helps
Safeguard provides healthcare-specific SBOM management capabilities designed for the unique challenges of medical device ecosystems. Our platform ingests manufacturer SBOMs, validates their quality against FDA requirements, correlates components with vulnerability databases, and integrates with hospital asset management systems. For legacy devices, our binary analysis module can generate approximate SBOMs to fill visibility gaps. The result is a unified view of software risk across your entire device fleet, enabling faster response to new vulnerabilities and better-informed procurement decisions.