The FDA recently published a new guidance on Cybersecurity and software in medical devices: “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions”.
The new guidance has pushed software composition and vulnerabilities up in importance when making a submission to the FDA. As such, Software Bills of Materials (SBOMs) have become a required output for all submissions.
Integrating the generation and analysis of SBOMs into our automated software build system improved the quality of the software we create for clients without weighing down our development team.
What is an SBOM?
An SBOM is a list of all the software components within a software system or product. The SBOM contains the meta data for each component including the name, author, version, what license it is released under, and other details to help identify each component within the scope of all available components that it could be compared with, Figure 1. All the SBOM information is made available to developers allowing them to track software dependencies.
Figure 1: Snippet of an SBOM
There are two main formats for creating SBOMs. The OWASP sponsored CycloneDX project (Figure 2), and the Linux foundation’s SPDX format. We use the CycloneDX JSON SBOM standard for cataloging many different types of software: firmware, cloud services, mobile apps and embedded operating systems such as QNX.
SBOMs can also be saved in two different formats: JSON or XML files. While XML was initially the most widely supported format, JSON has recently overtaken XML as the format of choice for most systems according to a number of sources.
Figure 2: CycloneDX tool center has a number of open source tools for SBOM creation
Why an SBOM?
Gathering all this information into an SBOM has a number of key benefits. First, an SBOM can help organizations identify and track the software components used in their systems. This is important because many software vulnerabilities are found in third-party components, and organizations may not be aware of which components they are using. By maintaining an SBOM, organizations can have a clear understanding of their software ecosystem and be better prepared to address any vulnerabilities that arise.
Second, an SBOM can be used to assess the security posture of a software system. By analyzing the components listed in the SBOM, organizations can determine which components are outdated, have known vulnerabilities, or are no longer supported by their developers. This information can be used to prioritize security updates and ensure that the software system remains secure.
Third, an SBOM can facilitate communication between different stakeholders. For example, medical device manufacturers can use the SBOM to communicate the components used in their software to hospitals and stakeholders that can then use the information to assess the security risks associated with the software. Additionally, security researchers can use the SBOM to report vulnerabilities to the appropriate parties (Figure 3), who can then take steps to address the issues.
Figure 3: Vulnerability Detection in Cybeats Studio
Creating SBOMs
We created an automated build pipeline to include the creation of SBOMs and to upload them for automatic analysis. Our system currently uses a number of open source and third-party tools. The CI server uses Lib4SBOM to manually generate SBOMs for C and C++ based firmware (Figure 4). The system uses CycloneDX tools to automatically build SBOMs based on project files for any software that uses a package manager.
Figure 4: Build Automation is essential for keeping SBOM information up to date.
After the SBOMs are created, they are uploaded to the Cybeats SBOM Studio portal, which runs analysis and identifies vulnerabilities. The list of vulnerabilities is provided back to the development team for further analysis and potential mitigation. The CI server then collects the vulnerabilities findings from SBOM Studio and documents them, and then provides the feedback directly to our developers to warn them in case they need to update some of their dependencies.
Once an SBOM has been created it can be continually monitored to see if any new vulnerabilities are detected. If any vulnerabilities are detected, they can be passed to the developers to be addressed as needed. Other options supported by SBOMs include monitoring of End of Life and End of Support for different software components. All this information can be useful when creating an FDA submission. Automating this process has made getting useful and timely information from our SBOMs quick and reliable (Figure 5).
Figure 5: Vulnerabilities are identified and corrected.
Conclusion
The use of SBOMs as part of our build process has brought significant value both internally and for clients. Our developers are given an indication of where some of the vulnerabilities that must be addressed are located, while our clients get a clear picture of what their software contains, including vulnerabilities which they can provide to the FDA or other regulators as needed.
If you would like to know more about how StarFish Medical can help with your SBOM regulatory compliance, please contact our Business Development group. They would be happy to discuss how Starfish can help you succeed in creating robust, secure medical devices.
Russell Haley is a StarFish Medical Senior Software Engineer. He is a software and IT veteran with over 20 years of start-up experience designing IoT systems that collect data through Wi-Fi, Bluetooth and MICS (implantable) radios and store vital records in the cloud from oceanographic buoys, financial institutions, passenger trains and most recently, medical devices.
James Sease is a QA Engineer at StarFish Medical with a background in both Mechanical and Software Engineering. He has worked primarily medical and aerospace engineering across several different roles. James enjoys working on automation of devices, tools, and processes.
