For audio summary click below
Similar to the growing importance of threat modeling, Software Bill of Materials (SBOM) and Vulnerability Exploitability eXchange (VEX) are becoming essential components of medical device cybersecurity. The Food and Drug Administration (FDA) is in the process of making SBOM a labeling requirement for premarket submissions of medical devices, at the same time the industry is learning that SBOMs alone are only part of the solution and gradually adopting the use of VEX to further enhance the utility of the SBOM in real life use.
Although having an SBOM on hand is beneficial for cybersecurity, how to use one effectively is another matter. The effectiveness of medical device security practice can be challenging to accomplish without first fully understanding how the use of VEX documents complement the SBOM throughout the product lifecycle. Therefore, let’s take a deep dive into these two concepts and how you can make the best use of them.
What is an SBOM?
A Software Bill of Materials, or SBOM, is a formalized list of all components required to build a piece of software, including its drivers, software licenses, operating systems et cetera. The concept was a collaborative community effort driven by the National Telecommunications and Information Administration (NTIA) in 2018, fostering transparency within the software ecosystem. An SBOM can facilitate quicker responses to any new disclosed vulnerabilities from both software producers and users (by helping security teams quickly identify impacted systems).
What is VEX?
Vulnerability Exploitability eXchange (VEX) is a structured advisory format for communicating information about a known vulnerability in an SBOM or as a separate electronically accessible document. The VEX section of an SBOM document helps software users prioritize their vulnerabilities and avoid wasting time with non-exploitable flaws that will have no effect on the final product. The status of a particular vulnerability falls into one of the following categories: Not affected, Affected, Fixed and Under Investigation.
How do SBOM and VEX documents interlink?
An SBOM offers a wealth of information on a software’s components that allows users to easily discover potential vulnerabilities. The more vulnerabilities that are discovered, theoretically the greater the concern for the cybersecurity of that device.
In fact, not all vulnerabilities create identical impacts in every case. A vulnerability that is exploitable in one context is not necessarily a cause for concern in another. Depending on the situation, a disclosed vulnerability may have a greater and lesser impact (or no impact at all) on the operation of the final product. Therefore, in many circumstances, SBOM itself is insufficient to enable risk-based decision-making. Software users need to have the context to utilize SBOM to its full potential.
This explains why employing SBOM and VEX together can maximize the effectiveness of cybersecurity practices for medical devices. VEX communicates and categorizes the status of a disclosed vulnerability in the components listed in an SBOM. It helps to eliminate false positives and indicates the progress of how a vulnerability can be mitigated. Using VEX greatly boosts the value of an SBOM to software users.
How do you implement SBOM and VEX throughout the product lifecycle?
SBOMs and VEX, together, help identify potential vulnerabilities in medical devices. The following scenario is what the risk assessment process looks like when both are included:
- With SBOM, the asset owner has access to the complete list of a product’s components and can identify potential vulnerabilities.
- Through the assessment, plenty of vulnerabilities may be discovered. The asset owner needs to identify which of disclosed vulnerabilities need to be prioritized and fixed.
- To achieve this, contextual information is needed to clarify which vulnerabilities are exploitable and which ones do not pose a risk. This is where they need a VEX.
- The asset owner can then filter all vulnerabilities on the list using the VEX information and concentrate on remediating the ones that pose the most risk in that given situation.
Both the SBOM and the VEX data or documents need to be updated continuously throughout the product lifecycle to deliver the best practice of medical device cybersecurity. An up-to-date SBOM must be created whenever a Medical Device Manufacturer (MDM) makes modifications to the software and new vulnerabilities also need to be added into the VEX. Despite being updated separately, the content of each document remains aligned due to their interconnectivity.
SBOM and VEX are not the new MDS2!
A common mistake made by MDMs is assuming that the work involved in creating and maintaining these two documents, particularly an SBOM, is similar to that required to establish the Manufacturer Disclosure Statement for Medical Device Security (MDS2) form.
SBOM and VEX are living technical documents that require specific tooling as well as input from product security, engineering and safety teams. Over the course of the product’s lifetime these teams will be the ones that make the most use of the information provided by the SBOM, by matching new vulnerabilities and their software components as well as assessing the exploitability for their VEX advisories. This is strikingly different from the MDS2 form that is intended to be used by healthcare providers in an operational manner, helping them understand the risk profile of a device and the security lifecycle policies.
To conclude, even though an SBOM is only now becoming a mandatory document, when the VEX information is included, organizations will be able to achieve more comprehensive protection for their medical devices. It is therefore better to start planning on how your organization can implement the VEX framework into its SBOM approach to ensure a smooth and speedy mitigation of new security risks.
Hungry for more about medical device cybersecurity?
Follow our blog for more discussions on SBOM and VEX!