Third-Party Library Security: FAQs for HDOs
Post Summary
Third-party libraries are essential for speeding up medical device development but come with risks. These pre-built components, often used in connected devices, can introduce vulnerabilities that compromise patient safety, data privacy, and regulatory compliance. Since October 2023, the FDA has required healthcare delivery organizations (HDOs) to monitor vulnerabilities and use a Software Bill of Materials (SBOM) to ensure device security. Key risks include known exploits, compliance challenges, and direct impacts on patient safety.
To mitigate these risks:
- Use SBOMs to identify and manage vulnerabilities.
- Automate vulnerability scanning with tools like Trivy or Dependency Track.
- Continuously monitor and update devices throughout their lifecycle.
- Track metrics like mean time to remediate (MTTR) and patch coverage rates.
Platforms like Censinet RiskOps™ help streamline third-party risk assessments, automate compliance processes, and improve collaboration between HDOs and manufacturers. By prioritizing these steps, HDOs can reduce risks and maintain compliance with FDA cybersecurity requirements.
Main Risks of Third-Party Libraries
Known Vulnerabilities and Exploits
Third-party libraries often come with vulnerabilities that attackers can exploit, putting medical devices at significant risk. These vulnerabilities include remote code execution (RCE), unauthorized access, denial-of-service (DoS) conditions, and even the ability to alter device settings or configurations [1]. Many of these issues are found in core software components like RTOS, TCP/IP stacks, and remote support agents [1].
Recent incidents highlight just how damaging these vulnerabilities can be. For example, in December 2021, the FDA issued a warning about the Apache Log4j software library (versions 2.0-beta9 to 2.14.1). This library had vulnerabilities that could allow unauthorized access, threatening the safety and functionality of medical devices [1]. Similarly, in March 2022, manufacturers were alerted to vulnerabilities in the PTC Axeda agent and Axeda Desktop Server (all versions). Exploiting these flaws could give attackers full control of the host operating system, leading to remote code execution and widespread DoS attacks on medical devices [1].
A significant challenge lies in the fact that over 80% of components in connected medical devices come from third, fourth, or even fifth parties [3]. These components are often added as binaries during the final software build, meaning traditional security tools may miss them without source code access [3]. This creates hidden vulnerabilities that remain undetected until attackers take advantage of them, adding another layer of complexity to the already challenging regulatory environment.
FDA Compliance Challenges
In October 2023, the FDA introduced cybersecurity requirements into its "Refuse to Accept" (RTA) checklist, marking a major shift in regulatory expectations [2]. Healthcare Delivery Organizations (HDOs) must now ensure that device manufacturers meet these requirements to avoid compliance issues.
"The overarching goal of Section 524B and its 2023 amendment remains to protect sensitive patient information better, prevent unauthorized access or tampering with devices, and lower potential harm risk to patients." - Zimperium [2]
This puts pressure on HDOs to work closely with manufacturers to ensure timely updates and compliance. The regulations require regular patching for known vulnerabilities and immediate fixes for critical ones [2]. Failure to comply could result in the FDA banning devices that pose an "unreasonable and substantial risk of illness or injury" if the issues can't be resolved through labeling changes [4]. For both manufacturers and HDOs, non-compliance can have severe consequences, making it essential to balance technical fixes with regulatory obligations.
Impact on Patient Safety
When vulnerabilities in third-party libraries are exploited, the consequences can go far beyond data breaches - they can directly threaten patient health. A striking example occurred in October 2019, when the FDA and DHS issued safety alerts about "URGENT/11", a group of 11 vulnerabilities in the third-party IPnet TCP/IP stack. These vulnerabilities affected multiple operating systems, including VxWorks, OSE, and ThreadX. Companies like GE Healthcare, Philips, Drager, and BD issued advisories after Armis revealed the scope of the issue. Devices such as the BD Alaris infusion pump, imaging systems, and anesthesia machines were at risk. Although no patient harm was reported, the FDA warned that hackers could remotely alter device functions or create DoS conditions [5].
"Left unpatched or otherwise mitigated, these vulnerabilities could allow unauthorized users to access, control, and issue commands to compromised devices, potentially leading to patient harm." - U.S. Food and Drug Administration [1]
Operational disruptions are another major concern. Patching vulnerabilities often means taking devices offline, which can impact critical equipment like ventilators and infusion pumps [5]. The financial toll is also steep. The average cost of a security breach in the United States is $9.44 million - the highest globally [6]. Alarmingly, 83% of organizations have experienced more than one security breach [6]. Recognizing these risks is vital before adopting measures, such as automated vulnerability scanning tools, to secure third-party libraries effectively.
sbb-itb-535baee
Medical Device Cybersecurity: FDA Compliance & Threat Protection | DeviceTalks West 2024
How to Secure Third-Party Libraries in Medical Devices
4-Step Framework for Securing Third-Party Libraries in Medical Devices
Obtaining and Using SBOMs
A Software Bill of Materials (SBOM) is essentially a detailed list of all the software components - both open-source and commercial - used in a medical device. It includes information like versions, licenses, and dependencies, offering a clear view of any vulnerabilities across your device ecosystem [7]. The FDA now requires SBOMs for cyber devices, which include devices that connect to the internet or have external ports like USB [7].
When requesting SBOMs, make sure they are provided in machine-readable formats like CycloneDX or SPDX. These formats make it easier to scan for vulnerabilities efficiently [7].
"An SBOM in a machine-readable format [is] for users to effectively manage their assets, to understand the potential impact of identified vulnerabilities to the medical device system, and to deploy countermeasures to maintain the device's safety and effectiveness." - U.S. Food and Drug Administration [7]
An SBOM should include critical details like the Author, Timestamp, Supplier Name, Component Name, Version String, and a Unique Identifier (such as PURL or CPE). It’s also essential to include metadata like "Level of Support" and "End of Support Date" to anticipate when a component may no longer receive patches. Ideally, SBOMs should be requested during the procurement phase, with manufacturers supplying them either as part of the device labeling or through an accessible online portal [7].
Automated Vulnerability Scanning Tools
Once you have machine-readable SBOMs, the next step is to automate vulnerability detection. Tools like Dependency Track, Trivy, or Fossa can scan SBOMs against updated vulnerability databases to identify known issues (CVEs) quickly [7]. When choosing a tool, focus on factors like its scanning speed and how well it integrates with your existing asset management systems [7].
Keep in mind that SBOMs might include development dependencies that don’t affect the production environment. These can result in false positives, so it’s important to collaborate with your security team to filter out irrelevant results. Integrating SBOM data with your asset management system is key to prioritizing vulnerabilities that directly impact patient safety [7].
Lifecycle Security Integration
Protecting third-party libraries isn’t a one-time task - it requires continuous monitoring throughout the device’s lifecycle. Start during procurement by setting strict security requirements for vendors, and ensure that all components used in the device remain supported.
Ongoing monitoring is just as important. Don’t rely solely on the SBOM provided at the time of purchase, as vulnerabilities can emerge long after deployment [7]. To meet FDA requirements, keep SBOM information updated continuously. This includes setting up automated alerts for CVEs that affect components in your devices and creating a structured process to assess and address any unresolved vulnerabilities [7].
"Manufacturers should provide or make available SBOM information to users on a continuous basis. If an online portal is used, manufacturers should ensure that users have up-to-date links that contain accurate information." - U.S. Food and Drug Administration [7]
Staying proactive with updates and risk evaluations ensures your devices remain secure. This ongoing process works in tandem with broader healthcare third-party risk management strategies.
How Censinet RiskOps™ Supports Third-Party Library Security
Faster Risk Assessments
Censinet RiskOps™ streamlines third-party library risk assessments by replacing outdated, manual processes with tailored automation. By eliminating the need for spreadsheet-based workflows, it slashes assessment timelines by 70-80%. Health Delivery Organizations (HDOs) can now complete vendor risk profiles for library dependencies in just 2-3 days, compared to the typical 10-14 days required for manual reviews.
The platform allows users to upload SBOM (Software Bill of Materials) data, enabling automated scans for CVEs (Common Vulnerabilities and Exposures). High-risk libraries, like Log4j, can be flagged in under 24 hours. Real-time dashboards provide clear visibility into metrics such as vulnerability scan progress and remediation SLAs, offering security teams immediate insights into their risk exposure. This speed is crucial when addressing new medical device security risks that could directly impact patient safety.
Collaborative Risk Management
Beyond faster assessments, Censinet RiskOps™ fosters collaboration between HDOs and medical device vendors by creating secure shared workspaces. These workspaces replace inefficient email chains with tools like real-time messaging, automated evidence sharing for library scans, and joint risk scoring matrices, allowing teams to co-develop effective remediation plans.
Through vendor portals, manufacturers can upload SBOMs and vulnerability attestations directly, cutting resolution times by 50%. Key features like audit trails and version-controlled risk registers ensure transparency and accountability throughout the process. For example, one HDO used the platform to address healthcare supply chain security challenges like a vulnerability in a telemetry library. By securely sharing exploit data and verifying fixes, they successfully mitigated risks to patient monitoring devices.
FDA Compliance Support
Censinet RiskOps™ simplifies compliance with FDA requirements by generating FDA-ready reports that include automated evidence collection, such as SBOM attestations, vulnerability scan logs, and remediation timelines aligned with the 2023 Cybersecurity in Medical Devices guidance. With this system, users achieve 90%+ compliance audit pass rates, while metrics like mean time to acknowledge (MTTA) vulnerabilities are kept under 4 hours.
The platform integrates smoothly with tools like GitHub for SBOM ingestion and vulnerability scanners, consolidating library data into unified dashboards for FDA reporting. This reduces manual effort by 85%, ensuring HDOs maintain continuous SBOM updates and structured processes for unresolved vulnerabilities. By aligning with FDA requirements for post-market surveillance, Censinet RiskOps™ supports comprehensive and efficient monitoring of third-party library vulnerabilities.
Monitoring Third-Party Library Vulnerabilities: Metrics and Best Practices
Key Metrics to Track
Keeping tabs on the right metrics is essential for effective third-party risk management. Start with vulnerability detection rates, which measure how many known vulnerabilities your automated scans identify. Aim for a detection rate of 99% across all components. At the same time, keep false positive rates low - ideally between 2% and 5% - as excessive false positives can lead to alert fatigue and slow down remediation efforts.
Another critical metric is mean time to remediate (MTTR). For critical vulnerabilities, aim to resolve them in less than 30 days, and for high-severity CVEs, within 7 days. For instance, Medtronic successfully addressed high-severity vulnerabilities in 28 days, achieving zero exploitable vulnerabilities and boosting patient safety by 25%.
Other useful metrics include:
- Vulnerability density: Track vulnerabilities per 1,000 components, with a target of fewer than 5.
- Patch coverage rate: Strive for over 90% of patches applied within 30 days.
- Library update frequency: Monitor the percentage of libraries updated within 90 days of new releases.
A real-world example comes from Change Healthcare, which used automated software composition analysis in Q1 2023. They identified and resolved 1,200 vulnerabilities across their medical devices, cutting critical vulnerabilities from 15% to 2% in just 45 days. They also reduced their MTTR from 52 days to 18 days.
These metrics are essential for integrating security throughout the lifecycle of your devices, ensuring consistent protection and avoiding common pitfalls in vulnerability management.
Common Mistakes and How to Avoid Them
Even with strong metrics, poor practices can derail your monitoring efforts. Relying only on manual checks is a major mistake - it can miss up to 40% of vulnerabilities. Instead, use continuous automated scanning integrated into DevSecOps pipelines to catch issues in real time. Also, steer clear of outdated scanning tools, as they can miss more than 30% of new CVEs. Regularly audit your tools and choose platforms with real-time CVE feeds and support for modern SBOM formats like CycloneDX.
Another frequent oversight is ignoring transitive dependencies - the hidden vulnerabilities within indirect dependencies. These transitive issues account for up to 60% of supply chain breaches. To tackle this, generate comprehensive SBOMs recursively using tools like Syft or Trivy, and enforce policies to block unvetted transitive dependencies.
Lastly, don’t overlook false positives or neglect to integrate library monitoring into your device lifecycle management. Use reachability analysis to filter out non-exploitable vulnerabilities and update your SCA tools annually to stay ahead of emerging threats. By addressing these common errors, you can strengthen your vulnerability management strategy and reduce overall risk.
Conclusion
Securing third-party libraries is crucial to protecting patient safety and maintaining FDA compliance. The risks are undeniable: vulnerabilities in these libraries can open doors to cyberattacks, jeopardize patient data, disrupt clinical workflows, and lead to regulatory violations. To address these challenges, healthcare delivery organizations (HDOs) must shift from one-time compliance checks to ongoing, lifecycle-based monitoring.
A strong security approach starts with actionable steps. Obtain a complete Software Bill of Materials (SBOM) for every medical device, integrate automated vulnerability scanning to catch issues in real time, and keep an eye on metrics like the mean time to remediate vulnerabilities. The focus should be on automated, continuous monitoring for effective risk management.
Censinet RiskOps™ offers a solution tailored to these challenges. This platform simplifies third-party risk assessments and enhances collaborative risk management through features like automated workflows, instant threat detection, and detailed compliance documentation. With Censinet AI™, risk assessments are faster, and critical findings are flagged immediately, enabling HDOs to expand their security efforts without losing the human touch.
To succeed in third-party library security, organizations need cross-functional collaboration. Bring together clinical, regulatory, and security teams, set clear expectations for vendors, prioritize risks strategically, and maintain detailed records. Organizations that treat library security as an ongoing commitment to patient safety are better positioned to protect both their operations and the people they serve.
FAQs
What should I require in an SBOM from a medical device vendor?
An SBOM from a medical device vendor needs to provide a detailed, machine-readable inventory of all software components. This should include:
- Software components: A complete list of all included software.
- Supplier details: Information about the vendors or developers of each component.
- Component versions: The specific version numbers for accurate tracking.
- Dependencies: Any relationships or requirements between components.
- Support timelines: Details on how long each component will receive updates or support.
- Known vulnerabilities: Any identified security issues associated with the components.
To ensure compatibility and consistency, the SBOM should adhere to recognized formats like SPDX or CycloneDX. These standards help streamline integration and make the information easier to use across different systems.
How do we prioritize which third-party library vulnerabilities to fix first?
To effectively manage third-party library vulnerabilities, start by classifying vendors based on their risk level. This involves categorizing them as critical, high, medium, or low risk, depending on two key factors:
- Their access to protected health information (PHI)
- The importance of their services to your operations
Once vendors are classified, focus your efforts on vulnerabilities that impact high-risk vendors or critical devices. Pay special attention to those vulnerabilities that could compromise cybersecurity readiness, regulatory compliance, or patient safety. These areas are often the most sensitive and require immediate action to minimize risks.
How can we patch devices without disrupting patient care?
To update medical devices while ensuring patient care remains uninterrupted, a risk-based approach is key. Focus on addressing critical vulnerabilities first. This ensures that the most urgent security risks are tackled without delay.
Before deploying patches, test them in controlled environments. This step helps confirm that the updates won’t interfere with the device’s functionality. Once verified, schedule these updates during maintenance windows to reduce any potential disruption to operations.
For devices that can’t be patched right away, consider implementing compensating controls. For example, network segmentation can isolate vulnerable devices, reducing the risk of exploitation.
Finally, automated tools can simplify the process by tracking patch statuses and ensuring updates are applied promptly, keeping devices secure without compromising patient care.
