Securing Third-Party Libraries in Devices
Post Summary
Third-party libraries are essential for developing medical devices but come with critical medical device security risks like vulnerabilities, outdated components, and supply chain attacks. These risks can compromise patient safety, regulatory compliance, and cybersecurity. The FDA now requires detailed Software Bills of Materials (SBOMs) in premarket submissions to ensure transparency and mitigate risks.
Key Takeaways:
- Risks: 80% of breaches involve third-party components; 72% of applications contain vulnerabilities.
- Regulations: FDA mandates SBOMs under Section 524B and cybersecurity integration into Quality Management Systems.
- Solutions: Automated tools like OWASP Dependency-Check and Censinet RiskOps™ streamline SBOM generation, vulnerability scanning, and risk management.
Actionable Steps:
- Use SBOM tools (e.g., SPDX, CycloneDX) to document libraries.
- Automate dependency scanning with tools like OWASP dep-scan.
- Continuously monitor vulnerabilities and maintain archived SBOMs.
Conclusion: Addressing third-party library risks requires transparency, automation, and collaboration between manufacturers, vendors, and regulators to protect patients and meet FDA guidelines.
Third-Party Library Risks in Medical Devices: Key Statistics and Regulatory Requirements
Regulatory Requirements for Third-Party Libraries
FDA Cybersecurity Guidance for Premarket Submissions
The FDA's "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions" outlines how manufacturers should manage third-party libraries. Updated on June 27, 2025, this guidance addresses the requirements under Section 524B of the FD&C Act for "cyber devices" - medical devices that use software and connect to networks or the internet[1].
"This document provides FDA's recommendations to industry regarding cybersecurity device design, labeling, and the documentation that FDA recommends be included in premarket submissions for devices with cybersecurity risk." - FDA[1]
Manufacturers are expected to integrate cybersecurity into their Quality Management Systems (QMS) and provide detailed information about third-party components in their 510(k), PMA, and other premarket submissions. Failing to meet these disclosure requirements could result in submission rejections[1]. This push for thorough documentation has made Software Bill of Materials (SBOMs) a key tool for regulatory compliance.
Software Bill of Materials (SBOMs) in Regulatory Compliance
An SBOM is essentially a detailed, machine-readable inventory listing all embedded libraries in a device. Under Section 524B, SBOMs are required for premarket submissions, ensuring that regulators have full visibility into components often treated as opaque "black boxes"[2][3].
Research on infusion pumps revealed that vulnerabilities were evenly split - 50% stemmed from the manufacturer's own code, while the other 50% came from third-party libraries and operating systems[3]. With over 76% of medical devices impacted by supply chain vulnerabilities, SBOMs play a critical role in identifying and managing these risks[3]. The FDA requires SBOMs to include seven elements defined by the NTIA: Supplier Name, Component Name, Version, Unique Identifier (e.g., Package URL or CPE), Dependency Relationship, Author, and Timestamp[2].
"The FDA wouldn't allow food manufacturers to sell products without ingredient lists, medical devices should not be deployed without disclosing their software components." - Manifest Cyber[3]
SBOMs not only support regulatory compliance but also strengthen risk management practices. To maximize their effectiveness, manufacturers should adopt machine-readable formats like SPDX or CycloneDX and automate SBOM creation during each software build. Pairing SBOMs with Vulnerability Exploitability eXchange (VEX) data helps filter out irrelevant CVEs, minimizing false alarms[4]. However, SBOMs should remain confidential, shared only with trusted partners and regulators to avoid exposing sensitive details to potential attackers[4].
Post-Market Monitoring of Third-Party Libraries
Regulatory compliance doesn't end with premarket submissions - ongoing monitoring of third-party libraries is essential to maintain device security. Manufacturers must track vulnerabilities that emerge over a device's operational life, as well as monitor End-of-Life (EOL) dates and support statuses for each component[2][4].
Given the prevalence of healthcare data breaches, post-market vigilance is more important than ever[3]. Maintaining archived SBOMs allows manufacturers to cross-reference them with updated CVE databases, enabling proactive risk assessments. This approach aligns with the FDA's focus on continuous risk management rather than one-time evaluations. By keeping detailed, archived SBOMs, manufacturers can ensure they stay ahead of potential threats throughout the lifecycle of their devices[2][3].
sbb-itb-535baee
Methods and Tools for Securing Third-Party Libraries
Automated Dependency Scanning and Vulnerability Management
To catch vulnerabilities before devices hit the market, manufacturers rely on automated tools integrated into their CI/CD pipelines. Tools like OWASP Dependency-Check map dependencies to known vulnerabilities (CVEs) using CPE identifiers. However, because false positives are common, next-generation tools such as OWASP dep-scan take it further by performing reachability analysis for languages like Java, JavaScript, TypeScript, and Python, allowing teams to focus on actual risks.
For medical devices that require full-stack traceability, Dependency-Track uses SBOMs (Software Bill of Materials) to monitor component usage across firmware, hardware, and operating systems. It provides real-time alerts for new vulnerabilities, enabling continuous monitoring even post-market. Tools like Syft and Grype also play a critical role: Syft generates SBOMs from container images and filesystems, while Grype scans those SBOMs to identify vulnerabilities. By configuring CI/CD pipelines to fail builds if SBOM generation fails, manufacturers can ensure undocumented software doesn’t slip through. This automated approach lays the groundwork for effective SBOM practices and strict version control, as discussed below.
SBOM Generation and Version Control Best Practices
On average, medical device projects include 68 dependencies and 5 critical vulnerabilities[5]. A stark example is the Heartbleed vulnerability in OpenSSL, which led to the theft of 4.5 million medical records from a hospital chain[5]. To prevent such incidents, generating SBOMs during the build process - after resolving dependencies but before packaging - ensures the inventory aligns with the final artifact. Tools like OWASP cdxgen simplify this process, supporting the CycloneDX format and even generating Cryptography Bills of Materials (CBOMs) for Java and Python projects, which are essential for auditing encryption.
SBOMs must include key details about components and their dependencies. Using tools like OWASP cdxgen paired with Cosign to generate and sign SBOMs during builds ensures artifact integrity. When vulnerabilities are identified, teams should update components to secure versions - or remove them if nonessential - and regenerate the SBOM to confirm the fix. Pairing SBOMs with Vulnerability Exploitability eXchange (VEX) documents (in CycloneDX or CSAF 2.0 format) helps clarify whether a known vulnerability actually impacts a product under specific conditions, reducing unnecessary alerts. These practices, combined with secure testing strategies, ensure comprehensive component security.
Secure Integration Testing and Runtime Protections
Manufacturers must confirm that third-party libraries integrate securely within the overall device architecture. In line with FDA requirements for ongoing risk management, static analysis identifies issues like hardcoded credentials or insecure API calls by reviewing source code without executing it. Meanwhile, dynamic analysis tests the running application to detect runtime behaviors that could expose vulnerabilities. Tools like dep-scan assist by performing reachability analysis, helping teams focus on vulnerabilities that are actually exploitable within the execution path, cutting down on noise from unused libraries.
For closed-source or SaaS components where source code isn’t accessible, binary-based SBOM tools can analyze compiled code to create a component inventory. Additionally, industry resources like CISA’s Known Exploited Vulnerabilities (KEV) and the Exploit Prediction Scoring System (EPSS) can help prioritize which vulnerabilities to address first. Containerization offers another layer of defense by isolating libraries in controlled environments, minimizing the impact of any compromised component. For third-party software that cannot be directly scanned, requesting SBOMs from vendors provides critical visibility into otherwise hidden components.
Using Censinet RiskOps™ for Third-Party Library Risk Management
Automating Third-Party Risk Assessments with Censinet RiskOps™
Healthcare delivery organizations (HDOs) face the challenge of evaluating device security without direct access to source code. Censinet RiskOps™ bridges this gap by automating the analysis of MDS2 (Manufacturer Disclosure Statement for Medical Device Security) forms. These forms, submitted by vendors, detail a device's security posture, including its use of third-party libraries.
The platform processes SBOM (Software Bill of Materials) data from vendors, scans for known vulnerabilities in third-party components, and generates automated risk scores using CVSS (Common Vulnerability Scoring System) and exploitability metrics. For example, in one case study, RiskOps™ uncovered critical vulnerabilities and compared the vendor’s remediation speed against industry benchmarks. This allowed prioritized patching within 48 hours, effectively preventing potential PHI (Protected Health Information) exposure.
HDOs also benefit from the Digital Risk Catalog™, which provides quick evaluations and comparisons of device risk profiles and their dependencies. Automated Corrective Action Plans (CAPs) streamline the remediation process, reducing manual review time by 70%. According to a 2025 Censinet report, HDOs using RiskOps™ saw a 40% decrease in cybersecurity incident costs, with one organization avoiding $2.5 million in breach expenses by proactively managing vulnerabilities in 50 connected devices.
Building on these capabilities, Censinet AITM leverages advanced AI to further accelerate risk management.
Censinet AITM for Faster Risk Management
Censinet AITM (Automated Intelligence and Threat Management) takes risk management to the next level with machine learning. It analyzes SBOMs to predict risks in third-party libraries and automatically generates remediation recommendations. The platform also checks for open-source license compliance, end-of-life issues, and exploit trends, processing 500 libraries in less than 4 hours with an impressive 95% accuracy in prioritizing risks.
Data from Censinet shows that AITM shortens third-party vendor assessment cycles by 80% on average, with users reporting a 60% drop in high-risk library exposures after implementation. In 2025 benchmarks, AITM identified 92% of critical vulnerabilities (CVSS >9.0) in medical device SBOMs before FDA post-market surveillance timelines. This level of speed and precision is crucial in healthcare, where each patient bed may have 10 or more connected devices, leaving no room for error in security management.
The efficiency of AI-driven assessments naturally transitions into improved vendor collaboration through Censinet Connect™.
Vendor Collaboration with Censinet Connect™
After automating assessments and prioritizing risks with AI, Censinet Connect™ enhances collaboration between HDOs and vendors. This secure portal within RiskOps™ facilitates the sharing of SBOMs, vulnerability reports, and remediation plans. It also supports real-time updates, joint risk scoring sessions, and audit trails in compliance with FDA 21 CFR Part 11, ensuring transparency in addressing issues like unpatched dependencies.
For instance, a U.S. hospital network used Censinet Connect™ to work with an infusion pump vendor after identifying a supply chain attack risk in a third-party JSON library. Through the portal, they conducted shared vulnerability scans, co-developed patch roadmaps, and automated re-testing, resolving the issue in just 72 hours - all while maintaining device uptime. By bringing together IT, Risk, Cybersecurity, and BioMed teams on a single healthcare-focused platform, Censinet Connect™ creates a centralized inventory and evidence repository for third-party risks. This is especially critical as Medical Device Security remains the least-covered area among the ten Health Industry Cybersecurity Practices (HICP) best practices for HDO cybersecurity programs.
Conclusion
Key Takeaways
Third-party libraries can speed up the development of medical devices but come with serious cybersecurity challenges. Between June 2013 and January 2025, the FDA issued 18 cybersecurity safety communications, with 94% of the reported vulnerabilities labeled as high-risk[6]. These vulnerabilities, found in components like Real-Time Operating Systems (RTOS), Apache Log4j, and IPnet software, can lead to unauthorized access, device malfunctions, and breaches, all of which jeopardize patient safety.
Regulatory compliance is no longer optional. The FDA's cybersecurity guidance and the Consolidated Appropriations Act of 2023 mandate that manufacturers maintain Software Bills of Materials (SBOMs)[7]. To meet these requirements, healthcare organizations need to adopt Secure by Design principles, incorporating security measures like regular patching, network segmentation, and thorough risk assessments of all third-party components during the development process.
Automation is the key to keeping up with the growing number of vendors and libraries. Manual methods simply can’t scale. Tools like Censinet RiskOps™ streamline SBOM analysis, vulnerability scanning, and risk scoring, allowing for continuous monitoring and proactive risk management. This is especially crucial as the average cost of a security breach in the U.S. has climbed to $9.44 million[7].
These strategies emphasize the importance of taking a proactive and collaborative approach to cybersecurity.
Building a Secure Future for Medical Devices
To ensure a secure future for medical devices, the healthcare industry must move away from reactive responses and toward proactive security management. Amy Abernethy, Principal Deputy Commissioner at the FDA, emphasized this need:
"The FDA urges manufacturers everywhere to remain vigilant about their medical products - to monitor and assess cybersecurity vulnerability risks, and to be proactive about disclosing vulnerabilities and mitigations to address them"[8].
With the risks and regulatory demands outlined earlier, collaboration has become more critical than ever. Manufacturers, vendors, healthcare providers, and regulators must work together to tackle these challenges. Collaborative platforms like Censinet Connect™ make it possible to share SBOMs, vulnerability reports, and remediation plans in real-time, promoting transparency and accountability throughout the supply chain. Protecting third-party libraries requires ongoing monitoring, advanced automation, and a shared commitment to safeguarding patient safety.
Practical Guide to Cybersecurity and SBOM Management for FDA Approval
FAQs
What is a third-party library in a medical device?
A third-party library in a medical device refers to a reusable software component created by external developers rather than the device's main development team. These libraries often provide pre-built features such as user interface frameworks, encryption tools, or open-source software, which are integrated into the device's software to expand its capabilities.
How do SBOM and VEX work together to reduce false vulnerability alerts?
A Software Bill of Materials (SBOM) is essentially a comprehensive list of all the components, dependencies, and versions used within a piece of software. Think of it as a detailed ingredient list for your software, giving you full visibility into what's inside.
On the other hand, Vulnerability Exploitability eXchange (VEX) takes this a step further by helping identify which vulnerabilities are actually exploitable in a given environment. While an SBOM tells you what’s in the software, VEX tells you which of those components pose a real risk.
When used together, SBOM and VEX allow organizations to cut through the noise of false alarms. They help pinpoint genuine threats, making it easier to focus on critical vulnerabilities while ignoring those that don't pose a danger. This is especially valuable in fields like medical device cybersecurity, where addressing real risks quickly and efficiently can have life-saving implications.
What should we do when a device depends on an end-of-life or unpatchable component?
If your device uses a component that has reached its end-of-life or can no longer be patched, it’s a good idea to either replace it or securely decommission it. To minimize risks, consider network segmentation to isolate these vulnerable devices from the rest of your network. Additionally, conducting regular risk assessments can help identify and address cybersecurity concerns. These measures are key to managing potential vulnerabilities effectively.
