Skip to main content
Blog
 / 
FDA

Beyond the Basics: Building FDA-Compliant SBOMs for MedTech

Discover how an SBOM factors into cybersecurity measures in software development and why an FDA-compliant SBOM requires more than standard tools.
Gabriel Pascualy
  •  
August 8, 2024
  •  

In medical technology, the security of devices isn't just about safety; it's also about cybersecurity. From patient data breaches to the potential hijacking of equipment, the cybersecurity vulnerabilities in medical devices pose significant risks. This is where a software bill of materials (SBOM) — a comprehensive inventory of all software components and dependencies within a medical device — comes into play. However, not all SBOMs are created equal. When it comes to SBOMs for medical device software, the FDA demands a level of detail that goes beyond standard practices. 

While standard SBOMs provide a static, moment-in-time snapshot of software components, FDA-compliant SBOMs for medical devices are living documents that that require updates with every software update or when new vulnerabilities are discovered. To protect against evolving cybersecurity threats, SBOM tools should integrate with risk management processes, support continuous threat modeling, and enable ongoing vulnerability management throughout a device's entire lifecycle. The ability to generate FDA-compliant SBOMs is critical for companies building MedTech software, but most popular SBOM tools don’t address regulatory compliance requirements. To stay competitive in the market, MedTech companies need a way to generate FDA-compliant SBOMs at pace with software development.

Why SBOMs matter for cybersecurity 

An SBOM is a formal record that details all of the elements of a software application, including its libraries, dependencies, and any third-party components. Software composition analysis (SCA) tools play a crucial role in generating SBOMs. SCA tools scan codebases, dependencies, and project manifests to create a comprehensive inventory of all of the software components within an application. By analyzing both proprietary and open-source elements, SCAs identify each component's name, version, origin, and known vulnerabilities. This information is then compiled into a structured SBOM format, providing details of the software component’s composition.

These SCA tools, such as Synopsys, Black Duck, Mend.io, and Snyk, have become increasingly sophisticated, offering features like automatic updates, integration with development pipelines, and reachability analysis (i.e., determining if a vulnerability can be exercised by an attack using our application). These tools perform in-depth scans of codebases, dependencies, and project manifests, identifying all components and analyzing them for vulnerabilities and dependencies. This comprehensive inventory aids in generating detailed SBOMs that reflect the software's current state.

SBOM standards are also widely recognized across the tech industry. The NTIA Multistakeholder Process on Software Component Transparency, a group led by the National Telecommunications and Information Administration (NTIA, part of the U.S. Department of Commerce), established SBOM standards in 2019 and updated them in 2021. 

The NTIA standards were designed to create a common framework for generating and sharing software component information. The updated version emphasizes the importance of interoperability between different SBOM formats and tools. It outlines minimum elements that should be included in an SBOM, such as the supplier name, component name, version, unique identifiers, dependency relationships, and SBOM authorship information. 

Whereas NTIA SBOM standards focus on enhancing overall transparency and security across industries, FDA cybersecurity-focused guidances are specifically tailored for the medical device industry, incorporating more stringent requirements to ensure patient safety and regulatory compliance (e.g., detailed documentation, rigorous change control, complete traceability, etc.).   

FDA guidances for medical device cybersecurity 

In response to an increasingly complex and perilous cyber threat landscape, the FDA issued new guidance on medical device cybersecurity in September 2023. The guidance mandates that the production of SBOMs for medical devices is part of the premarket submission process. It requires that medical device manufacturers provide an SBOM listing commercial, open-source, and off-the-shelf software used in their devices. Additionally, MedTech manufacturers must submit a plan for monitoring, remediating, and disclosing postmarket vulnerabilities. The FDA also requires that these manufacturers create and maintain processes proving that a device and its related systems are secure, including making updates and patches available after the product has been released. 

Starting October 1, 2023, the FDA gained the authority to refuse premarket submissions that don't include comprehensive and accurate cyber information — including SBOMs. These additional mandates put pressure on MedTech manufacturers who are striving to meet regulatory requirements.

Standard SBOMs vs. FDA-Compliant SBOMs 

While a standard SBOM is a recognized requirement across many industries, FDA-compliant SBOMs for medical devices demand a significantly more thorough approach. Let’s examine the tooling and process differences between the two. 

SCA and SBOM tools generate standard SBOMs   

Several popular SCA and SBOM tools dominate the market. Among these, Black Duck, Mend.io, and Snyk stand out as industry leaders, each offering the ability to create standard SBOMs for commercial software. These tools scan a software project's codebase, dependencies, and manifest files, creating an inventory of all of the software’s components. The gathered information is then compiled into a structured SBOM detailing each component.

While these tools are effective for general software development, they may fall short of meeting the requirements set by the FDA for medical device software. The SBOMs generated by standard SCA and SBOM tools often lack the depth of information and continuous lifecycle integration demanded by FDA guidance. For example, they may not provide the level of detail required for support information on all software components, or they may not fully integrate with the specialized risk management processes that are required for medical devices. 


SCA, SBOM, and the MedTech product lifecycle 

The graphic below illustrates how SCA tools and SBOM tools fit into the steps of the MedTech product lifecycle. 

SCA tools are integral in the early development stages, particularly in conducting software of unknown provenance (SOUP) analysis. This process involves evaluating software components that are not fully known or verified, or developed using unknown methodologies. SCA tools are also instrumental in identifying software vulnerabilities, providing a comprehensive view of potential security risks within a developing project.

Following the SCA phase, an SBOM is generated, either as an output from the SCA tool or a specialized SBOM tool. The SBOM becomes a key document used to mitigate any issues arising from software components that are either not adequately secured or fail to meet FDA requirements. The SBOM, typically formatted in standards like SPDX or CycloneDX, then flows into subsequent development phases.

As development progresses, the SBOM remains a central document, interfacing with product lifecycle management (PLM), application lifecycle management (ALM), or electronic quality management system (eQMS) tools. These systems utilize the SBOM throughout risk assessment and testing, documentation, release, and postmarket metrics gathering. For example, SBOMs help ALMs maintain requirement traceability and they aid eQMS tools in performing risk assessments by providing detailed information on all software components.  

To be truly FDA-compliant, an SBOM must be designed to successfully integrate with each of these later development stages, ensuring continuous tracking and management of software components throughout the lifecycle of the medical device. This ensures that security and compliance are maintained from initial development through to market release and beyond.

The FDA also mandates specific SBOM formatting requirements, including formats that are both human-readable and machine-readable and the inclusion of particular data fields. This level of detail can only be met by more sophisticated tools that can accommodate medical device regulatory compliance. As a result, medical device manufacturers often have to invest in specialized lifecycle management platforms to ensure that they’re effectively meeting FDA requirements. 

Why standard tools aren’t enough for MedTech 

Standard SCA tools usually lack features for continuous lifecycle management, such as version control, risk assessment integration, and postmarket surveillance support. They often don’t integrate with risk assessment processes and lack the traceability that the FDA mandates.

These tools are also not designed to handle the specific documentation needs for FDA submissions. FDA requirements necessitate a more dynamic, context-aware SBOM that recognizes the unique risk profile of medical devices and their potential impact on patient safety. 

The path to creating FDA-Compliant SBOMs 

The path to creating FDA-compliant SBOMs for MedTech requires tooling that integrates with existing development processes while meeting FDA requirements. An FDA-compliant SBOM solution for MedTech should be built on a robust ALM, PLM, or eQMS platform. These systems serve as the backbone for managing software changes, monitoring vulnerabilities, documenting processes, and facilitating releases. The submission process to the FDA typically involves including the SBOM as part of the premarket submission package, ensuring it's readily accessible for regulatory review.

An ideal FDA-compliant SBOM tool for MedTech has real-time update capabilities, ensuring the SBOM reflects the current state of software components at any given moment. It integrates risk assessment functionalities, allowing for the incorporation of risk scores and impact assessments for each software element. Enhanced traceability is another crucial feature, providing detailed provenance information for all software components and maintaining clear links to other device documentation.

The tool must support postmarket surveillance, enabling ongoing monitoring and facilitating quick responses to newly discovered vulnerabilities. It must also generate compliance documentation that aligns with FDA submission requirements, including technical reports and more accessible summaries for various stakeholders. Context is key in MedTech, so the tool must allow for the inclusion of device-specific operational information and potential patient safety implications.

Version control is another essential feature. Manufacturers must maintain a clear history of SBOM changes throughout the device's lifecycle. Finally, the SBOM solution must support easy integration with other FDA-mandated systems and processes. This ensures that the SBOM remains a living document, integral to the entire development and maintenance process of FDA-compliant MedTech devices.

How Ketryx can help 

Ketryx integrates SBOM generation and management directly into medical device development and maintenance processes. Key features include:

  • Continuous SBOM updates: Maintains a living SBOM throughout the device lifecycle.
  • Risk assessment integration: Links SBOM data with risk assessment processes so teams can focus their time on the most important risks and risk controls by quickly seeing critical risks.
  • Traceability: Maintains clear links between SBOM components and other documentation.
  • Vulnerability impact assessment: Evaluates the potential impact of each vulnerability (e.g., how the vulnerability could be exploited, the potential damage it could cause, and the systems or data that might be affected). 
  • Postmarket surveillance support: Aids in monitoring and managing vulnerabilities after deployment.
  • Compliance documentation: Generates FDA-aligned reports and documentation.
  • Third-party component management: Tracks and assesses risks of third-party components.
  • Automated updates: Integrates with popular software development tools to keep vulnerability information current.

Ketryx transforms SBOMs from static documents into dynamic, integral elements of medical device lifecycle management, ensuring FDA compliance. 

Stay compliant, stay competitive

Companies relying on SBOM tools that fail to meet these new standards face significant challenges in bringing their devices to market. The FDA's authority to reject pre-market submissions lacking comprehensive and accurate cybersecurity information means that devices without appropriately detailed and formatted SBOMs risk being denied general release. This underscores the critical importance of adopting FDA-compliant SBOM practices.

The transition from standard SBOMs to FDA-compliant SBOMs represents a fundamental change in software security for medical devices. Success requires not only meeting regulatory requirements but also embracing a proactive stance on patient safety and device security. For medical device manufacturers, investing in robust SBOM and lifecycle management solutions is a necessity in today's interconnected healthcare landscape.

By facilitating the seamless creation of FDA-compliant SBOMs, MedTech companies can keep pace with innovation in the medical device market. In an industry where time to market can make or break a product's success, having the right SBOM solution creates a competitive advantage.

Watch our recent webinar to learn more about SBOMs and FDA-compliant cybersecurity vulnerability management. 

Interview transcript

Gabriel is a cybersecurity subject matter expert at Ketryx. He was a principal investigator at MITRE and worked on AI at Amgen. He holds at MSc and MBA from MIT's Leaders for Global Operations program.