The FDA drops a Cybersecurity Compliance SBOM in 2023
Cybersecurity has been an ever-increasing area of focus for the FDA and other national regulatory bodies. It’s simple to see why: as medicine increasingly becomes digital, patient safety will depend on the vigilance of manufacturers and their cybersecurity programs.
As a way to address this increase in digital health, the FDA has published a new guidance that took effect on March 30th, 2023, notifying manufacturers that the FDA can refuse to accept submissions that do not have proper cybersecurity controls. Now, the increasing pressure on early development and the application process is sending many companies scrambling to confirm the documentation for their cybersecurity and reevaluate their developer practices and SOPs. Here's what you need to know.
A quick summary of 2023 SBOM & FDA cybersecurity updates from CEO Erez Kaminski
When is the new 2023 FDA cybersecurity compliance deadline?
The FDA details in the announcement that there will be a period until October 1st, 2023, where they will collaborate with manufacturers to help them ensure they have the appropriate content in their submission. After October 1st, the FDA expects that submissions will contain the required cybersecurity and SBOM information and may refuse to accept submissions that fail to do so.
Build an updated SBOM and cybersecurity plan for all FDA regulated software
The FDA now has the authority to establish cybersecurity standards for medical device premarket submissions, providing a long-awaited solution to help manage cybersecurity risks. However, it is important to recognize that the responsibility of managing these risks ultimately falls on all stakeholders in the healthcare environment.
This guidance expands what is expected of your cybersecurity strategy. Have a plan for future risks and learn to respond faster when issues do arise. This instruction means having a formal, documented, part 11-compliant plan to help ensure your device and its patients are safe from cyber threats and software risks. Documentation that was once a suggestion of best practices has now become a hard line, and the FDA can refuse your submission if you don’t present proper traceability and documentation.
But let’s go to the guidance itself. It states that applicants must:
- Have a plan to monitor, identify, and address post-market vulnerabilities quickly
- Maintain strong, reliable processes to assure the device and its systems are secure, updating as needed post market when vulnerabilities emerge.
- Provide an up-to-date software bill of materials, including commercial, open-source, and off-the-shelf software components
The last one in particular has been a long time coming for open source software and its use in safety-critical devices. The FDA identifies a software bill of materials (SBOM) as a necessity for any submission involving a “cyber” device.
What is a software bill of materials (SBOM)?
Software applications are more connected than ever, and this process shows no sign of slowing. The option to use off-the-shelf, custom code, or other third-party open source material provides developers more building options than ever before, Frankenstein's-monster style. But as you carefully string more and more unique pieces of code together that were not intended or vetted for medical devices, how can you ensure their source is safe or that you have covered any potential vulnerabilities? What happens if one dependency is not as protected as you thought, and a small change causes a massive security risk in your system?
The software bill of materials is the constantly changing list of open source software that provides a bird's eye view and tracks each software item you bring into your medical device. With the ideal SBOM, developers always know what they are using and can react to changes and risks as they occur rather than hunting them down after damage has been done.
By identifying all of the underlying components that make up a software application or system (the “software composition”), and SBOM provides details that are crucial to organize in order to manage the security risks associated with using third-party software components. The FDA states that all organizations must “provide to the Secretary a software bill of materials, including commercial, SOUP, and off-the-shelf software components.” This time, there’s no room for argument, no questioning what should or should not be included. All vulnerabilities must be addressed and accounted for, including:
- Component name
- Version number
- Software manufacturer
- Level of support provided by software manufacturer
- End-of-support date
- Any known vulnerabilities
This step towards mandatory SBOMs has been in the works for the last two years. The Protecting and Transforming Health Care Act (PATCH Act) first appeared in the US House of Representatives as of 2021, and it now sits with the Health subcommittee for further development. If this bill moves forward, manufacturers will be required to provide a software bill of materials, which includes commercial, open-sourced, and off-the-shelf software components. Building on this expectation for stricter SBOM and FDA cybersecurity compliance, the Consolidated Appropriations Act, which was enacted on December 29, 2022, includes Section 3305 that grants the FDA the long-awaited power to establish cybersecurity standards for medical device premarket submissions. Now, the FDA's new cybersecurity guidance is the result of this bill, and premarket submissions can be rejected if these cybersecurity standards are not met. A big—but necessary—task for complex medical device software.
How to Generate a FDA-compliant SBOM (Software Bill of Materials)
How does an SBOM (Software Bill of Materials) actually help with FDA Compliance in 2023 & beyond?
Despite the potential perception of the SBOM mandate as another compliance obstacle, it should instead be welcomed as a joint effort by the government and industry to make devices more resistant to threats. An SBOM facilitates risk management efforts by identifying devices that have software that could be vulnerable to cybersecurity threats.
The SBOM is a key tool that:
- Helps you identify potential vulnerabilities: Faster recognition means a faster response to any security incidents. For example, if a known vulnerability is discovered in one of the components listed in the SBOM, you can quickly identify which applications and versions are affected and take appropriate action.
- Ensures compliance with licensing agreements: By knowing which components are used in their applications and the associated licenses, you can avoid legal issues related to the use of open-source software or commercial software with restrictive licenses.
- Benefits software developers: By viewing a clear list of components and their versions, developers can more easily manage their dependencies and ensure that they are using the latest and most secure versions of each component.
The U.S. government has recognized the importance of SBOMs and has taken steps to encourage their use in the past, but the FDA’s latest guidance makes it an absolute requirement for medical device manufacturers. It is a new standard practice for the safety-critical software development process.
Cybersecurity’s importance in our expanding (and fast-changing) software world shows that what developers consider “best practices” will always be adapting. An SBOM can help mitigate the risks associated with using third-party software items with a clear list of what is in your system, which is crucial for maintaining reliable and safe software. The FDA’s guidance enforces what many in the industry already knew: cybersecurity and knowing every building block in your system must be managed.
FDA cybersecurity guidance seems straightforward. So why is the new requirement for an SBOM considered a challenge?
While the concept of an SBOM seems straightforward, the actual implementation and maintenance of one can pose challenges.
- Time and resources: Creating and maintaining an accurate SBOM can be a time-consuming process, especially you have complex software systems. Dedicated staff and resources are needed to gather and track all the necessary information. With thousands of potential open source items, this task becomes unwieldy.
- Dependency management: Keeping track of dependencies can be a complex process, especially when multiple teams are involved in developing and maintaining a software system and changes continually slow the building process to a crawl.
- Version control: As software components are updated and new versions are released, keeping track of which versions are used in each application grows and shifts. And the bigger the system, the more complexity you’re dealing with. You must have a process in place to ensure that the SBOM is updated as new versions are released.
- Ongoing maintenance: Unfortunately, creating an SBOM is not a one-time task. You must continually monitor your software systems for new vulnerabilities and ensure that the SBOM is kept up-to-date with any changes or updates. For many, this process includes manually updating or transferring data from their development platform to their documentation application.
What can I do to ensure my company is compliant with the new 2023 FDA cybersecurity standards?
The FDA's requirement for an SBOM is a step in the right direction for improving software security in healthcare and other growing digital spaces, and it introduces challenges that organizations knew were coming. However, software development teams are still running into issues maintaining SBOM because their software tooling has not caught up with regulations.
Tools built over the past few decades are not prepared or adapted to the increasing connectedness of current software, and it shows—more time and resources are being used than ever before and mistakes are still appearing. This gap leaves development teams with the heavy task of manually transferring data and painstakingly tracking each dependency or open source that appears in their system, as well as any changes or updates that are made.
Luckily, there are tools that are adapting to meet this increasing need. Ketryx Software Supply Chain allows you to create and continuously monitor your FDA-compliant software bill of materials directly from your source code. Built to generate your entire SBOM in seconds, this tool simply requires you to upload a Git URL, then hit submit. Your entire up-to-date SBOM is generated in seconds, along with the FDA-required documentation.
Want to learn more? Read these related posts to explore more regulatory software expectations:
.svg)