SBOMs for Medical Devices – Everything You Need to Know

The US Food and Drug Administration (FDA) has mandated SBOMs for medical devices running any kind of software must create and maintain a Software Bill Of Materials (SBOM) starting on October 1, 2023.The good news for Medical Device Manufacturers (MDMs) is that SBOM generation tools are ubiquitous. The bad news is the fact that SBOM best practices are still evolving, meaning manufacturers (and their customers) will experience growing pains as they learn to improve supply chain and cybersecurity with them.

The initiative aligns well with President Biden’s Executive Order, which mandates adoption of supply chain security best practices for US government vendors, including SBOMs. While critical vendors were given a compliance date of June 2023, the majority of government software vendors were expected to comply by September 2023. Given that US Federal health spending is 28% of the $4.3 trillion US healthcare spend (primarily due to Medicare and Medicaid, but also the Veterans Health Administration), MDMs would do well to get onboard as quickly as possible.

Recall that an SBOM:

• Lists all the software components that comprise an application, service, API, or runtime environment on which (for example) the software in a medical device runs.
• Contains detailed information about each software component (both proprietary and third party) as well as third-party integrations.
• Is a machine-readable official record.

In short, SBOMs provide MDMs and their customers with a transparency mechanism that allows them to more easily track software components usage across multiple seemingly unrelated devices that contain common components. The result allows MDMs to identify vulnerabilities more quickly and efficiently, which means they release fewer vulnerable devices and resolve security issues that arise in the field faster.

SBOMs for Medical Devices Benefits for Healthcare

Healthcare environments are all too frequently targeted by ransomware attacks due to their use of legacy platforms, as well as increasing reliance on network-connected medical devices that all too easily get out of date since they are rarely directly update-able by healthcare staff. After all, it’s not like medical providers can just shut down life sustaining devices if they get compromised by a cyberattack.

All of which means healthcare providers must:

• Include SBOMs as a key component in each contract for systems/devices they purchase.
• Employ those with the skillset to make use of SBOMs in order to track out-of-date and vulnerable open source components in the systems/medical devices they deploy. Today, too many healthcare IT professionals are not familiar enough with SBOMs to be able to make informed judgements about risky software they should not be bringing into their environments
• Work with device manufacturers to expedite remediation of outdated/vulnerable components as/when identified.

At the same time, MDMs must ensure their devices are not only hardened against cyberattack, but that their firmware and software are easily updatable in the field in order to expedite remediation

Yet even with all these processes in place, the healthcare industry may continue to struggle due to the fact that SBOM best practices are still evolving, making it difficult to work with multiple MDMs since each of them may have their own way of working with SBOMs – or even different types of SBOMs. Three competing standards (SPDX, CycloneDX and SoftWare IDentification tag[SWID]), all with different approaches increase complexity and make it even more difficult that healthcare’s domain-specific needs be addressed any time soon (such as identifying HIPAA non-compliant components, for example).

SBOMs for Medical Devices Best Practices

ActiveState provides a simple, standard way for any software vendor to create and track SBOMs over time (whether for traditional software applications or embedded devices), as well as identify and remediate vulnerabilities quicker.

ActiveState automatically builds Python (as well as  Perl, Ruby and Tcl) runtime environments securely from source code, and programmatically generates a JSON and SPDX SBOM for each of them. ActiveState also maintains a history of each runtime and SBOM generated, allowing MDMs to seamlessly recreate development environments (including native libraries) for devices they may have shipped years ago.

Unfortunately, while MDMs are increasingly generating SBOMs, they rarely do anything with them, which is a shame since they can act as a key enforcement mechanism. For example, you can use ActiveState SBOMs to:

• Verify runtime environments inside CI/CD containers to ensure the container is built with all required packages – no more, and no less.
• Verify the absence of severe or critical vulnerabilities.
• Let customers know when shipped vulnerabilities have been verified as “not exploitable” via SBOM metadata (i.e,.  Vulnerability Exploitability eXchange or VEX).

While these capabilities can help MDMs improve the cybersecurity of the devices they ship, vulnerabilities will inevitably crop up in the field. For this reason, ActiveState also ensures that MDMs can remediate vulnerabilities quicker by:

• Flagging and notifying stakeholders when a vulnerability is detected.
• Updating an extensive catalog of open source components on a regular basis, ensuring that fixed versions are readily available.
• Automatically rebuilding the runtime environment when a fixed version is selected, ready for testing/deployment.

All of which can help reduce Mean Time To Remediation (MTTR) from days or weeks to a matter of hours.

Read Similar Stories