FDA Open-Source Compliance: Supply Chain Risks
Post Summary
Open-source software (OSS) is widely used in medical devices but introduces significant risks manufacturers must address to meet FDA cybersecurity requirements. Here's what you need to know:
- FDA Requirements: Since October 1, 2023, the FDA can reject device submissions missing detailed cybersecurity documentation, including a machine-readable Software Bill of Materials (SBOM).
- Key Risks: OSS often lacks visibility, formal support, and consistent maintenance, leading to vulnerabilities that manufacturers must actively monitor and manage.
- SBOM Essentials: SBOMs must include details like supplier names, component versions, and dependency relationships. Continuous updates and monitoring are critical.
- Risk Management: Manufacturers should establish OSS governance policies, automate SBOM creation, and monitor vulnerabilities to ensure compliance and protect patient safety.
These practices are now central to FDA compliance and maintaining secure, reliable medical devices.
Webinar: Managing Compliance with the FDA's SBOM Requirements
sbb-itb-535baee
OSS Supply Chain Risks in FDA-Regulated Devices
This section dives into the main risks associated with OSS (open-source software) supply chains in FDA-regulated devices.
Limited Visibility Into Software Composition
Many manufacturers struggle to gain a complete understanding of all the OSS components embedded in their devices. Often, deeply nested OSS components go unnoticed, each potentially introducing vulnerabilities. Without comprehensive Software Composition Analysis (SCA), these hidden risks remain undetected, putting FDA compliance at risk. An incomplete SBOM (Software Bill of Materials) isn't just a minor oversight - it can lead to outright rejection by the FDA.
Now, let’s explore other risks tied to OSS maintenance practices.
Vulnerable and Outdated OSS Components
Unlike proprietary software, OSS components don’t come with a support hotline or a vendor to turn to when a critical vulnerability arises. The responsibility for addressing such issues falls squarely on the manufacturer. This becomes even trickier because OSS projects vary greatly in their level of maintenance. Some are actively updated, while others quietly become dormant.
Manufacturers must go beyond simply cataloging OSS components; they also need to monitor whether each component is actively maintained, no longer supported, or completely abandoned [1]. Unfortunately, this isn’t always straightforward.
"Open source components infrequently include detailed support information; it may need to be inferred based on registry updates or commit history." - FOSSA [1]
If a component is abandoned and a new vulnerability emerges, waiting for a patch is not an option - it may never come. Manufacturers are left with two choices: replace the component or document compensating controls to prove the device remains safe. Both options demand significant time and resources, directly impacting the ability to sustain FDA compliance.
On top of that, inconsistent maintenance practices make these vulnerabilities even harder to manage.
Inconsistent Security Practices Among OSS Maintainers
OSS projects are far from uniform. Some are supported by large organizations with dedicated security teams and formal vulnerability disclosure processes. Others might be maintained by a single developer working on it as a side project, often without any structured security reviews. For medical devices that incorporate components from both ends of this spectrum, the weakest link can pose a serious problem.
This inconsistency introduces compounded risks. If an OSS maintainer fails to address a known vulnerability, the manufacturer must step in to fill that gap. This often requires submitting additional VEX (Vulnerability Exploitability eXchange) statements or creating compensating controls documentation, which increases the burden of compliance [1].
The FDA also takes a broader approach to defining what constitutes a "cyber device." This is important for manufacturers to understand:
"A device with internal components that may be susceptible to supply chain risks, errors, or attacks targeting physical components once a device is on the market can also be classified as a cyber device." This highlights the need for comprehensive healthcare supply chain risk management to prevent disruptions. - Exponent [2]
In other words, even devices that aren’t internet-connected may fall under these requirements if their OSS components introduce supply chain risks. This makes managing OSS risks a critical task for ensuring compliance throughout the entire lifecycle of a device.
FDA Cybersecurity and SBOM Requirements for OSS
Core FDA Cybersecurity Requirements
As of March 29, 2023, the FDA requires SBOM (Software Bill of Materials) submissions for all premarket applications. Starting October 1, 2023, the FDA gained the authority to issue a Refusal to Accept (RTA) for any premarket submission - 510(k), 513, 515(c), 515(f), or 520(m) - that lacks the necessary cybersecurity documentation [1].
Manufacturers must provide "reasonable assurance" that their devices and related systems are secure against cyber threats. This includes submitting a formal postmarket plan to monitor, address, and disclose vulnerabilities. For OSS (open-source software), manufacturers must specify the support status of each component or justify why the status is unknown [1].
These updated requirements place SBOMs at the heart of FDA compliance.
How SBOMs Support FDA Compliance
An SBOM offers a detailed, organized inventory of all software components in a device, helping reviewers quickly identify and trace vulnerabilities. The FDA mandates that SBOMs be machine-readable and formatted in standards like SPDX or CycloneDX, adhering to NTIA's minimum elements [1]. Each SBOM must include:
| Required SBOM Data Field | Description |
|---|---|
| Supplier Name | The creator of the component |
| Component Name | The library or tool's name |
| Version | The specific release version |
| Unique Identifiers | CPE or PURL for precise identification |
| Dependency Relationship | How the component interacts with others |
| Timestamp | When the SBOM was generated |
To enhance their SBOMs, manufacturers should include Vulnerability Exploitability eXchange (VEX) statements. These clarify whether a known vulnerability (CVE) actually poses a risk within the device's specific setup [1]. This is especially helpful when a widely reported OSS vulnerability is irrelevant due to the device’s configuration.
"The FDA wants to make sure manufacturers have the context they need to have confidence in a fix when a vulnerability is identified." - FOSSA [1]
This detailed inventory equips manufacturers to thoroughly test OSS components for compliance with FDA standards.
Testing OSS Components to Meet FDA Standards
Creating an SBOM is just the first step. The FDA also requires manufacturers to provide evidence that their vulnerability assessments are thorough, including details about the methods used for discovery.
Software Composition Analysis (SCA) tools can automate the detection of vulnerabilities in OSS components, including those listed in CISA's Known Exploited Vulnerabilities (KEV) Catalog [1]. Automation is critical given the sheer number of OSS dependencies involved in a device’s lifecycle.
After identifying vulnerabilities, manufacturers must assess their impact and outline any compensating controls that address risks when immediate patches aren’t available. This rigorous testing feeds into the FDA-mandated postmarket monitoring plan, ensuring compliance throughout the device's operational life cycle.
How to Manage OSS Supply Chain Risks
FDA OSS Compliance: SBOM & Supply Chain Risk Management Process
Building an OSS Governance Policy
Creating a formal OSS governance policy is the cornerstone of any compliance strategy. Without it, decisions about OSS adoption become scattered and inconsistent, which can jeopardize FDA compliance efforts.
An effective policy outlines which OSS components are allowed, their approved sources, and the process for gaining approval. Always source OSS from official repositories that offer integrity verification. Using code from unverified mirrors or personal forks increases risks and complicates traceability.
Approval processes should focus on risk. Before integrating any OSS component into a regulated product, teams need to assess its security history, frequency of updates, responsiveness of maintainers, and licensing compatibility. Components that are critical to safety, handle PHI, or interact with network stacks should undergo more rigorous evaluation and continuous oversight.
Clearly defined roles are just as important as the approval criteria. Engineers are responsible for proposing and integrating components, cybersecurity teams evaluate risks and set patch deadlines, quality teams ensure compliance with design controls like 21 CFR 820.30 and IEC 62304, and regulatory affairs decides what needs to be disclosed to the FDA. A cross-functional OSS review board that meets regularly ensures that these decisions are well-documented and consistent. This governance approach lays the groundwork for technical tools like SBOMs and continuous monitoring.
Using SBOMs and Continuous Monitoring
An SBOM (Software Bill of Materials) shouldn’t just be a static document created at submission time. Instead, it should be a living document - updated with every build, version-controlled, and tied to specific device software releases. This ensures clear traceability during FDA reviews and postmarket monitoring.
Integrating Software Composition Analysis (SCA) tools into CI/CD pipelines automates SBOM creation for every official build. These tools must capture transitive dependencies - not just direct ones. The Log4Shell vulnerability (CVE-2021-44228) highlighted how buried dependencies, like log4j-core, can go unnoticed, delaying critical fixes. For detailed requirements on SBOM formats and data fields, refer to the FDA Cybersecurity and SBOM Requirements section.
Continuous monitoring completes this risk management cycle. Teams need to track vulnerability feeds like NVD, the KEV Catalog, and project-specific advisories to identify new threats in deployed components. When a severe vulnerability surfaces, the SBOM pinpoints which products and versions are affected, enabling faster responses. A 2023 Synopsys report revealed that 84% of commercial codebases contained at least one known OSS vulnerability, with 48% having high-risk vulnerabilities scoring 7.0 or above on the CVSS scale. Continuous monitoring ensures these vulnerabilities are addressed before they escalate into patient safety issues.
Healthcare delivery organizations (HDOs) assessing device vendors can leverage platforms like Censinet RiskOps™ for third-party and supply chain risk evaluations. These platforms incorporate SBOM data to help HDOs gauge vendors’ vulnerability management and cybersecurity practices.
Beyond monitoring, securing OSS configurations is critical to reducing potential attack surfaces.
Securing and Hardening OSS Configurations
Selecting a reliable OSS component is just the beginning. The way it’s configured plays a significant role in determining its security within a deployed device.
Here are some essential hardening steps:
- Disable unused services, ports, plugins, and modules: Features like default admin interfaces, sample apps, and unnecessary network services often become entry points for attackers and serve no clinical purpose.
- Apply least privilege principles: Run services as non-root users, restrict file system permissions, and limit application access to only what’s essential for safe operation.
- Enforce TLS, verify certificates, and encrypt sensitive data at rest to protect against data breaches.
- Avoid hard-coded credentials or keys in configurations: These are common red flags during FDA reviews and are easy targets for attackers.
- Ship devices with hardened configurations by default: If less secure settings are needed for clinical reasons, they should require a deliberate, justified opt-in - not be the default state.
Conclusion: Managing OSS Risks and Meeting FDA Requirements
Open Source Software (OSS) plays a critical role in medical devices, offering efficient functionality. However, its risks often stem from management oversights - like incomplete inventories, delayed updates, poorly configured systems, or lack of a proper governance framework.
Since March 29, 2023, the FDA has mandated that new device submissions include comprehensive cybersecurity documentation and a machine-readable Software Bill of Materials (SBOM). Starting October 1, 2023, submissions that fail to meet these requirements can be legally rejected by the agency [1]. This is now the expected standard for compliance.
To meet these requirements, manufacturers are adopting robust measures, including:
- Establishing formal OSS governance policies.
- Producing SBOMs for every build in formats like SPDX or CycloneDX.
- Continuously monitoring vulnerabilities through sources such as the NVD and CISA's KEV Catalog.
- Ensuring secure default configurations.
Maintaining an up-to-date SBOM alongside Vulnerability Exploitability eXchange (VEX) statements allows for quick communication and response when new vulnerabilities surface. These practices not only align with FDA standards but also foster confidence among device evaluators.
For healthcare delivery organizations (HDOs) evaluating device vendors, platforms like Censinet RiskOps™ offer tools to streamline third-party and supply chain risk assessments. By incorporating SBOM data and examining vendor cybersecurity practices, these platforms help HDOs make informed and timely procurement decisions.
Ultimately, the aim goes beyond regulatory compliance. It’s about ensuring that the software embedded in critical devices - whether an infusion pump, imaging system, or cardiac monitor - remains safe and reliable. A well-executed OSS risk management strategy not only meets FDA expectations but also protects patient safety at its core.
FAQs
What OSS components must be listed in an FDA SBOM?
An FDA Software Bill of Materials (SBOM) needs to cover several critical details to meet compliance standards. These include:
- Supplier Name: Identifies the entity providing the component.
- Component Name: Specifies the exact name of the software component.
- Version: Indicates the version of the component being used.
- Unique Identifiers: Includes identifiers like PURL (Package URL) or CPE (Common Platform Enumeration) for precise tracking.
- Dependency Relationships: Outlines how components interact or rely on one another.
- Support Levels: Details the type and extent of support available for the component.
- End-of-Support Dates: Specifies when support for the component will cease.
- Known Vulnerabilities: Highlights any identified security issues associated with the component.
To ensure compatibility and regulatory compliance, this information should be presented in a machine-readable format such as SPDX (Software Package Data Exchange) or CycloneDX. These formats make it easier to share, analyze, and manage the SBOM effectively.
How do I handle an abandoned OSS dependency with a new CVE?
When dealing with an abandoned open-source software (OSS) dependency that has a new CVE, it's crucial to stay proactive. Start by maintaining an up-to-date Software Bill of Materials (SBOM). This document helps you track the support status of all components in your software.
Next, cross-check your SBOM against vulnerability databases to identify potential risks. If you discover that a component is no longer supported, you have two main options: replace it with a supported alternative or implement compensating controls, such as network segmentation, to reduce exposure.
Additionally, keep monitoring for any new vulnerabilities that may arise. Document your mitigation strategies thoroughly to ensure compliance with FDA requirements for managing the OSS lifecycle. This approach not only addresses security concerns but also keeps your processes aligned with regulatory expectations.
When should I include a VEX statement with my SBOM?
Including a VEX statement alongside your SBOM (Software Bill of Materials) is a smart move when you need to clarify whether identified vulnerabilities are actually exploitable in your device's specific environment. This approach helps cut down on unnecessary alerts and ensures that attention is focused on the security issues that truly matter.
