Healthcare industry proof of concept successfully uses SPDX as a software bill of materials format for medical devices
The Linux Foundation | 05 August 2020
Overview
Software Package Data Exchange (SPDX) is an open standard for communicating software bill of materials (SBOM) information that supports accurate identification of software components, explicit mapping of relationships between components, and the association of security and licensing information with each component. The SPDX format has recently been submitted by the Linux Foundation and the Joint Development Foundation to the JTC1 committee of the ISO for international standards approval.
A group of eight healthcare industry organizations, composed of five medical device manufacturers and three healthcare delivery organizations (hospital systems), recently participated in the first-ever proof of concept (POC) of the SPDX standard for healthcare use.
This blog post is a summary of the results of this initial trial.
Why do we care about SBOMs and the medical device industry?
A Software Bill of Materials (SBOM) is a nested inventory or a list of ingredients that make up the software components used in creating a device or system. This is especially critical in the medical device industry and within healthcare delivery organizations to adequately understand the operational and cyber risks of those software components from their originating supply chain.
Some cyber risks come from using components with known vulnerabilities. Known vulnerabilities are a widespread problem in the software industry, such as known vulnerabilities in the Top 10 Web Application Security Risks from the Open Web Application Security Project (OWASP). Known vulnerabilities are especially concerning in medical devices since the exploitation of those vulnerabilities could lead to loss of life or maiming. One-time reviews don’t help, since these vulnerabilities are typically found after the component has been developed and incorporated. Instead, what is needed is visibility into the components of a medical device, similar to how food ingredients are made visible.
A measured path towards using SBOMs in the medical device industry
In June 2018, the National Telecommunications and Information Administration (NTIA) engaged stakeholders across multiple industries to discuss software transparency and to participate in a limited proof of concept (POC) to determine if SBOMs can be successfully produced by medical device manufacturers and consumed by healthcare delivery organizations. That initial POC was successfully concluded in the early fall of 2019.
Despite the limited scope, the NTIA POC results demonstrated that industry-agnostic standard formats can be leveraged by the healthcare vertical and that industry-specific formats are unnecessary.
Next, the participants in the NTIA POC explored whether a standardized SBOM format could be used for sharing information between medical device manufacturers and healthcare delivery organizations. For this next phase, the NTIA stakeholders engaged the Linux Foundation’s SPDX community to work with the NTIA Healthcare working group. The goal was to demonstrate through a proof of concept whether the open source SPDX SBOM format would be suitable for healthcare and medical device industry uses. The first phase of that trial was conducted in early 2020.
Objectives of the 2020 POC
The stated goals of this 2020 proof of concept (POC) were to prove the viability of the framing document created by the NTIA SBOM Working group (of which the Linux Foundation was a contributor) from their earlier POC for the medical device and healthcare industry.
This NTIA framing document defines specific baseline data elements or fields that should be used to identify software components in any SBOM format, which can be mapped into corresponding field elements in SPDX:
NTIA Baseline | SPDX |
Supplier Name | (3.5) PackageSupplier: |
Component Name | (3.1) PackageName: |
Unique Identifier | (3.2) SPDXID: |
Version String | (3.3) PackageVersion: |
Component Hash | (3.10) PackageChecksum; |
Relationship | (7.1) Relationship: CONTAINS |
Author Name | (2.8) Creator: |
The 2020 POC conducted by NTIA working group had a stated objective to determine if SBOMs generated by Medical Device Manufacturers (MDMs) using SPDX could be ingested into SIEM (Security, Information and Event Management) solutions operated by the participating Healthcare Delivery Organizations (HDOs).
The MDMs included in this POC included Abbott, Medtronic, Philips, Siemens, and Thermo Fisher. The HDOs included Cedars-Sinai, Christiana Care, Mayo Clinic, Cleveland Clinic, Johns Hopkins, New York-Presbyterian, Partners/Mass General, and Sutter Health.
Execution and implementation of the SPDX SBOMs
- The participating HDOs provided an inventory of the deployed medical devices in use within their organizations.
- A best-effort approach was used to determine software identity as the names that software packages are known by are “ambiguous” and could be misinterpreted.
- An example SPDX was created along with a guidance document for the MDMs to follow for use with the medical devices identified by the HDO inventory exercise.
- The MDMs produced 17 distinct SPDX-based SBOMs manually and with generator tooling.
- The SBOMs were delivered via secure transfer using enterprise Box accounts, simulating delivery via secure customer portals offered by each MDM.
Consumption of the SBOMs in the SPDX POC
As a result of the 2020 POC, all participating HDOs successfully ingested the SPDX SBOM into their respective SIEM solutions, immediately making the data searchable to identify security vulnerabilities across a fleet of products. This information can also be converted into a human-readable, tabular format for other data analysis systems.
Multiple HDOs are already collaborating with vendor partners to explore direct ingestion into medical device asset/risk management solutions as part of their device procurement. One of the HDOs is working with one of their vendor partners to explore direct ingestion into a healthcare Vendor Risk Management (VRM) solution, and another has developed a ”How-To Guide,” focusing on how to correctly parse out the Packages fields using regular expressions (regex).
As a positive indicator of SPDX’s suitability when used with asset management systems, two HDOs have begun configuring their respective internal tracking systems to track software dependencies and subcomponents. Additionally, multiple HDOs are collaborating with vendor partners to manage devices into medical device asset/risk management solutions through the device’s life by allowing for periodic updates and an audit trail.
Ongoing considerations for SPDX-based SBOMs for medical devices in healthcare organizations
Risk management, vulnerability management, and legal considerations are ongoing at the participating HDOs related to the use of SPDX-based SBOMs.
Risk management
All of the responding HDOs are exploring vulnerability identification upon procurement (i.e., SIEM through initial ingestion of the SBOM) and on an on-going basis (i.e., SIEM, CMDB/CMMS, VRM). The participating HDOs intend to explore mitigation plan / compensating control exercises that will be performed to identify vulnerable components, measure exploitability, implement risk reduction techniques, and document this data alongside the SBOM.
The SPDX community intends to learn from these exercises and improve future versions of SPDX specification to include requested information determined to be needed to manage risk effectively.
Vulnerability management at HDOs
An HDO is already working with its Biomed team to manually perform vulnerability management processes on information extracted from SBOM data.
Another is working with their Vulnerability Management team to evaluate correlated SBOM data to credentialed/non-credentialed scans of the same device, which may prove useful in an information audit use case. A second HDO is currently working with their Vulnerability Management team on leveraging the SBOM data to supplement regular scanning results.
Legal
Participating HDOs have been developing SBOM product security language to add cybersecurity safeguards to the contract documentation.
Conclusion
The original POC was able to validate the conclusions of the NTIA Working Group that proprietary SBOM formats specific to healthcare industry verticals are not needed. This 2020 POC showed that the SPDX standard could be used as an open format for SBOMs for use by healthcare industry providers. Additionally, the ability to import the SPDX format into SIEM solutions will help HDOs adequately understand the operational and cyber risks of medical device software components from their originating supply chain.
There is work ahead to improve automation of SPDX-based SBOMs, including the automated identification of software components and determining which component vulnerabilities are exploitable in a given system. Participating HDOs intend to perform compensating control exercises to identify and implement risk reduction techniques building on this information. HDOs are also evaluating how SPDX can support other improvements to vulnerability management. In summary, this POC showed that SPDX could be an essential part of addressing today’s operational and cyber risks.
Similar Articles
Browse Categories
Cloud Computing Compliance and Security Open Source Projects 2024 Linux How-To LF Research Open Source Ecosystem and Governance Blog Diversity & Inclusion Research Newsletter Data, AI, and Analytics linux blog Training and Certification Linux Cross Technology Cloud Native Computing Foundation cybersecurity software development Announcements Decentralized Technology Legal OpenSearch Sustainability and Green Initiatives cloud native generative AI lf events Finance and Business Technology Networking and Edge cncf industries Emerging Technology Health and Public Sector Interoperability Kubernetes Topic: Security Web Application & Development amazon web services aws community tools confidential computing challenges decentralized AI decentralized computing eBPF funding japan spotlight kernel license compliance openssf ospo research survey skills development state of open source tech talent