FDA SBOM & Vulnerability Management Compliance: How MergeBase Helps Medical Device Manufacturers

FDA SBOM & Vulnerability Management Compliance

As of 2023, the United States Food and Drug Administration requires medical device manufacturers to include a software bill of materials (SBOM) and plans, processes, and procedures for vulnerability remediation and mitigation in their premarket submissions.

In this guide, we’ll discuss the SBOM-related requirements in Section 3305 (“Ensuring Cybersecurity of Medical Devices”) of the Consolidated Appropriations Act, 2023, and how an advanced software composition analysis tool like MergeBase can help you stay compliant.

Here’s what we’ll cover:


But first, a definition.

What is an SBOM? A software bill of materials is a machine-readable list of every component in a piece of software, including commercial, open-source, and off-the-shelf (OTS) code.


Why the FDA requires SBOMs


In their industry guidance for cybersecurity in medical devices, the FDA states that cyber threats to the healthcare sector have grown “more frequent and more severe, carrying increased potential for clinical impact.” These cyber-threats can make individual devices or entire networks impossible to use, disrupting diagnoses and delaying proper treatment, exposing patients to higher risk of harm and healthcare organizations to greater financial and legal risk.

By requiring manufacturers to produce SBOMs, the FDA is making it easier for governments, manufacturers, and healthcare institutions to monitor for security risks and vulnerabilities affecting the medical device’s software. The increased transparency an SBOM provides enables teams to take a more proactive approach to software supply chain security and address concerns as soon as they become known, rather than waiting for security breaches to alert them to issues, keeping applications more secure.



The Consolidated Appropriations Act’s exact text on cybersecurity requirements can be found in section 524B(b). But in summary, the FDA requires premarket medical cyber device submissions to include the following:

  1. A plan to monitor, identify, and address vulnerabilities in a “reasonable time”

  2. Processes and procedures to provide “reasonable assurance” that the device and related systems are secure and a plan to make updates and patches available postmarket

  3. A comprehensive software bill of materials (SBOM)

Let’s examine these requirements more closely and see how an advanced SCA (like MergeBase) can help you comply with these FDA SBOM regulations.


Making FDA-compliant vulnerability management plans (& the steps to take first)


Software vulnerabilities are inevitable, but implementing the correct security policies and controls can lessen their impact.

To comply with the new FDA regulations for medical devices, companies must create a “known vulnerability” policy that aligns with FDA requirements and outlines the security standards and remediation timelines they’re committing to. They must then put controls in place to track whether the policy is followed correctly.

In addition, medical device manufacturers must have a documented approach for handling the exploits and vulnerabilities (potential exploits) when they happen. The vulnerability management plan must include the following:

  1. How you will monitor your software for vulnerabilities*
  2. How you will identify vulnerabilities*
  3. How you will address both vulnerabilities and exploits in a “reasonable time” postmarket
  4. How you will disclose vulnerabilities and exploits to stakeholders

*Most organizations will use an advanced software composition analysis tool like MergeBase to address requirements one and two from the list. If an SCA is being used, the FDA recommends citing (at a minimum) the name of the tool, the tool’s version information, and the settings or configurations used on the tool at the time of the test in your plan.

Let’s look at an example.

Company X, a medical device manufacturer, has a policy to eliminate all vulnerabilities with a risk level of

  • 9.5 and above within three weeks
  • 8.5-9.4 within two months
  • 8.4 or lower (in order of severity) within six months

To achieve this, they commit to scanning their applications at minimum once a day using an SCA tool, like MergeBase, to identify vulnerabilities quickly and effectively. The results of these scans are fed into Jira, their agile project management tool of choice. The vulnerabilities are assigned to developers in order of importance, and progress is monitored daily via the team scrum.

Two months after the policy’s implementation, it is reviewed to ensure that all the high-level vulnerabilities identified in the first scan have been addressed. From there, the process is revised to prioritize lower-risk vulnerabilities (with the understanding that any new high-risk vulnerabilities that occur in the future are addressed first).

For assistance in developing a compliant vulnerability management plan, use the FDA’s industry guidance document, which outlines ways to approach security risk management, security architecture, testing, and transparency, as a starting point.


How MergeBase helps you maintain an FDA-compliant vulnerability management plan


Any decent SCA tool will help you monitor and identify vulnerabilities, but to meet the third requirement on the list — addressing issues in a “reasonable time” postmarket — you need to reduce your remediation time; this is where MergeBase comes into its own.

There are two main ways MergeBase’s SCA helps teams reduce remediation time: through its industry-leading accuracy and developer guidance feature.

One of the biggest misgivings developers have with other SCA tools is their tendency to raise false alarms. False positives are a big problem for vulnerability remediation because they delay an organization’s ability to deal with real threats and erode morale on and between teams. MergeBase’s tool is renowned for its low false positive rate — many customers switch to us for this reason — meaning your remediation team spends time actually securing your product instead of chasing down false positives.

In addition, while every SCA platform will detect vulnerabilities, the amount of help they give your developers after the fact varies. With many SCAs, the developers are left to hunt down and inspect patches themselves—a time-consuming process that impacts your ability to remediate vulnerabilities in a “reasonable time.”

MergeBase, on the other hand, shows developers what patches are available and provides information on compatibility and popularity so your team has a clearer idea of how well a patch will work for them. You also have the option to set MergeBase to automatically update components in your code library, keeping your software secure in the background and freeing up your developers’ time.


Setting up FDA-compliant security processes and procedures


The Consolidated Appropriations Act also requires medical device manufacturers to “design, develop, and maintain processes and procedures” that can reasonably assure the FDA and customers that the device (and any systems it touches) are secure and will remain secure postmarket.

As part of the FDA regulations, these processes must also make updates and patches available to the entities using these devices postmarket. The act specifies two levels of vulnerabilities these procedures must address: “known unacceptable vulnerabilities” and “critical vulnerabilities.”

  1. “Known unacceptable vulnerabilities” must be patched on a “reasonably justified regular schedule.”
  2. “Critical vulnerabilities”—i.e., vulnerabilities that could cause “uncontrolled risks”—take immediate priority. They must be patched as soon as possible, even outside the regular remediation cycle.

MergeBase enables teams to set policies for the risk levels that should be classified as “unacceptable” vs. “critical” as per your company policies and sorts vulnerabilities accordingly as they arise. The tool continuously monitors your projects and will send alerts when vulnerabilities that meet these guidelines are uncovered in the industry and found to impact your project. These custom policies and vulnerability scoring measures help teams act swiftly and prioritize fixes appropriately — working them into their regular remediation cycle or addressing them immediately to remain compliant. (As part of these custom policies, teams can also set age thresholds to flag updatable or obsolete components.)


Generating FDA-compliant SBOMs


The Consolidated Appropriations Act requires medical device manufacturers to provide a complete SBOM, “including commercial, open-source, and off-the-shelf software components.” These SBOMs should be machine-readable, and include:

  1. The baseline attributes identified by the National Telecommunications and Information Administration, often referred to by the NTIA minimum element set:
    • Author name (the person or people who wrote the SBOM)
    • Timestamp
    • Supplier name (the supplier of each component in the SBOM)
    • Component name
    • Version string (the current version of each component)
    • Component hash (the component’s cryptographic hash)
    • Unique identifier (any additional information to help uniquely define a component)
    • Relationship (where the component “sits” within the software described in the SBOM)
  2. The level of support provided for each component (describing whether or not the component supplier actively maintains the component, no longer maintains it, or if the component has been abandoned or deprecated)
  3. The software’s end-of-support date (if applicable)

When turning in this SBOM, the FDA recommends including a list of “all known vulnerabilities associated with the device and software components,” including those in the Cybersecurity and Infrastructure Security Agency’s Known Exploited Vulnerabilities Catalog. This list should include an assessment of each vulnerability’s risk and a description of how you will address these vulnerabilities.


How MergeBase helps you generate FDA-compliant SBOMs


MergeBase makes generating and maintaining FDA-compliant SBOMs simple: you can generate one with a single click. But MergeBase has a few features that separate it from most other SCAs on the SBOM-generation front as well:

MergeBase exports SBOMs in multiple industry-standard formats. You can generate an SPDX SBOM from the command line interface or export your SBOM in CycloneDX from the dashboard.

MergeBase SBOMs are machine—and human-readable. The tool generates a visual representation of your software supply chain, allowing human developers to quickly trace how vulnerabilities and risks pass through various components and subcomponents. MergeBase clearly and accurately delineates the relationships between software components.

MergeBase tracks component updates. The FDA recommends including information beyond the baseline SBOM attributes, and MergeBase makes this information easier to find. In MergeBase, you can see when a supplier last updated any given component, assess the level of support each component receives, and note any component’s end-of-support date if applicable.

MergeBase automatically updates your SBOMs. Depending on the medical device, you may need multiple SBOMs—sometimes even multiple SBOMs for the same vendor. MergeBase keeps track of your code libraries so you can make current and accurate SBOMs available to clients and regulators whenever they need them.


Keep your medical devices FDA-compliant with MergeBase


MergeBase can help you make and execute your vulnerability remediation plans, remain compliant with your cybersecurity procedures, and generate accurate SBOMs. But that’s just the beginning. MergeBase also helps you execute these plans in the postmarket by giving your developers accurate vulnerability reports and clear, direct developer guidance, so you’re even better equipped to remediate vulnerabilities quickly when they occur.

If you’d like to see how MergeBase can help you comply with the FDA’s cybersecurity requirements, start your free trial today!