Healthcare runs on software. Electronic health records, medical imaging systems, patient portals, infusion pumps, ventilators -- all of it depends on code, and most of that code includes open-source components that nobody in the hospital is tracking.
When a vulnerability is discovered in a software library used by a medical device, the question shifts from "could our data be breached?" to "could patients be harmed?" That changes the stakes entirely.
The Healthcare Software Landscape
Healthcare IT environments are uniquely complex. A typical hospital network includes:
- Electronic Health Record (EHR) systems like Epic or Cerner, each built on massive software stacks with hundreds of dependencies
- Medical devices ranging from MRI machines to insulin pumps, many running embedded software that hasn't been updated in years
- Clinical applications for lab management, pharmacy, radiology, and dozens of other specialties
- Patient-facing portals and mobile apps that integrate with backend systems
- IoT devices including environmental monitors, asset tracking systems, and building management
Each of these systems contains software components -- open-source libraries, third-party modules, embedded firmware -- that may harbor known vulnerabilities. And unlike most industries, patching in healthcare is complicated by patient safety considerations. You can't just reboot an infusion pump in the middle of a treatment.
FDA Requirements Are Changing the Game
The FDA's approach to cybersecurity in medical devices has evolved dramatically. The Consolidated Appropriations Act of 2023 (Section 524B of the FD&C Act) now requires medical device manufacturers to:
- Submit a Software Bill of Materials (SBOM) for new device submissions
- Provide a plan for monitoring, identifying, and addressing post-market cybersecurity vulnerabilities
- Design devices with the capability to be updated and patched
This is not guidance -- it's law. Medical device manufacturers must now include SBOMs as part of their premarket submissions. For healthcare delivery organizations (hospitals, clinics, health systems), this means you should start expecting SBOMs from your medical device vendors.
But the FDA requirement covers only new device submissions. The thousands of medical devices already deployed in your environment? Those are your problem.
HIPAA and Software Supply Chain Risk
HIPAA's Security Rule requires covered entities to conduct risk assessments and implement safeguards to protect electronic Protected Health Information (ePHI). Software supply chain vulnerabilities are a direct threat to ePHI confidentiality, integrity, and availability.
Consider the practical implications:
Risk Assessment (45 CFR 164.308(a)(1)). Your risk assessment should include software supply chain risks. If your EHR system includes a vulnerable logging library, that's a risk to ePHI. If your patient portal uses an outdated JavaScript framework with known XSS vulnerabilities, that's a risk to ePHI. Without SBOMs and component-level visibility, your risk assessment is incomplete.
Information System Activity Review (45 CFR 164.308(a)(1)(ii)(D)). You need to regularly review audit logs and system activity. Software supply chain compromises can be subtle -- a compromised dependency might exfiltrate data slowly or create backdoor access. You need to know what components are in your systems to understand what "normal" activity looks like.
Access Controls (45 CFR 164.312(a)(1)). Compromised software components can bypass access controls entirely. A vulnerability in an authentication library doesn't care about your role-based access policies.
Transmission Security (45 CFR 164.312(e)(1)). Vulnerable cryptographic libraries in your software stack can undermine transmission security controls. Without knowing which cryptographic libraries you're running, you can't verify that transmission security is actually working.
The connection between HIPAA compliance and software supply chain visibility is direct and auditable. OCR investigations following a breach increasingly look at whether the organization had adequate visibility into its software environment.
Real Healthcare Supply Chain Incidents
This isn't hypothetical. Healthcare has already been hit by software supply chain issues:
Log4Shell in healthcare. When Log4Shell was disclosed in December 2021, healthcare organizations scrambled to identify affected systems. Medical devices, clinical applications, and infrastructure components all potentially contained the vulnerable Log4j library. Organizations without software composition analysis spent weeks tracking down instances manually. Some never fully completed the effort.
SolarWinds in health systems. Multiple healthcare organizations were affected by the SolarWinds compromise. The Orion platform was widely used in healthcare for network management, and compromised updates were deployed across health system networks.
Medical device vulnerabilities. The ongoing stream of ICS-CERT advisories for medical devices reveals how many of these systems contain vulnerable third-party components. Many use outdated versions of operating systems, web servers, and libraries that have known vulnerabilities.
Building an SBOM Program for Healthcare
Healthcare organizations need a pragmatic approach to software supply chain security that accounts for clinical workflow constraints and patient safety requirements.
Step 1: Classify Your Software Environment
Not all healthcare software carries the same risk. Prioritize based on:
- Patient safety impact. Software that directly affects patient care (medical devices, clinical decision support, medication management) gets highest priority.
- ePHI exposure. Systems that store, process, or transmit ePHI need component-level visibility for HIPAA compliance.
- Network connectivity. Internet-facing systems and systems with external integrations have higher exposure to supply chain attacks.
Step 2: Generate SBOMs for Custom Applications
If your health system develops custom applications (many do -- patient portals, integration engines, reporting tools), integrate SBOM generation into your development pipeline. Use CycloneDX or SPDX format. Make SBOM generation automatic, not optional.
Step 3: Demand SBOMs from Vendors
Start with your highest-risk vendors:
- EHR vendors. Request SBOMs for your EHR platform and all modules.
- Medical device manufacturers. Under the new FDA requirements, manufacturers of new devices must provide SBOMs. For existing devices, request them proactively.
- Clinical application vendors. Lab, pharmacy, radiology, and other clinical system vendors should be producing SBOMs.
Add SBOM requirements to your procurement process. Make it a standard part of vendor security assessments.
Step 4: Implement Continuous Monitoring
SBOMs are only useful if you monitor them. When a new vulnerability is disclosed, you need to know within hours whether it affects any component in your environment. This requires:
- A centralized SBOM repository
- Automated matching against vulnerability databases (NVD, OSV, vendor advisories)
- Alerting that integrates with your existing security operations workflow
- Context-aware prioritization that considers clinical impact
Step 5: Coordinate Patching with Clinical Operations
Healthcare patching is different. You can't push an update to a medical device during a procedure. You can't take down an EHR system during peak clinical hours without advance planning. Your software supply chain vulnerability management process needs to account for:
- Clinical scheduling constraints
- Device validation requirements
- Change management procedures
- Downtime communication to clinical staff
The Patient Safety Angle
Software supply chain security in healthcare isn't just about data protection. It's about patient safety. A compromised infusion pump could deliver incorrect doses. A vulnerable clinical decision support system could provide incorrect recommendations. A ransomware attack that enters through a supply chain vulnerability could take down an entire hospital.
The FDA recognizes this, which is why SBOM requirements are now part of device submissions. Healthcare delivery organizations need to take the same approach: treating software transparency as a patient safety issue, not just a compliance checkbox.
How Safeguard.sh Helps
Safeguard.sh provides healthcare organizations with the software supply chain visibility that HIPAA risk assessments demand and FDA guidance recommends. The platform generates SBOMs for custom-built applications, ingests vendor-provided SBOMs, and continuously monitors all components against vulnerability databases.
For healthcare-specific needs, Safeguard.sh supports risk prioritization that accounts for clinical impact, provides the audit documentation needed for HIPAA compliance, and helps organizations track vendor SBOM compliance across their medical device and clinical application portfolio. When the next critical vulnerability is disclosed, healthcare security teams can query Safeguard.sh and know their exposure within minutes -- not the weeks it took most health systems during Log4Shell.