When a CVE Isn’t Your Vulnerability: Assessing CVEs in Medical Devices

Assessing a CVE in a Medical Device: Practical Example

Let’s consider a hypothetical medical device with embedded software and a Bluetooth interface. The device measures pressure, temperature, and water flow, transmitting only this non safety and data privacy critical data with timestamps to a companion app for documentation purposes. The app cannot modify the device’s configuration; the only information it sends to the device consists of embedded software updates.

An SCA tool identifies a vulnerability that could allow specially crafted Bluetooth messages to cause memory corruption or, under certain conditions, code execution.

The development team must now assess the actual product risk by answering several questions:

• Is the vulnerable functionality used? Is the affected component or function present and active in the product?
• Is the vulnerable code reachable via Bluetooth? Can an attacker trigger the vulnerable functionality through the device’s exposed interface?
• Are the prerequisites for exploitation met? Does the attack require specific configurations, privileges, or other conditions that are present in the product?
• Which product functions could be affected? Could exploitation compromise data confidentiality, integrity, or availability, or affect the device’s essential performance or safety?

These questions cannot be answered by relying on the scanner output alone. The CVE assessment must be supported by technical evidence, such as dependency analysis, source code inspection, configuration details, or targeted testing.

Three Acronyms, One Goal: Separating Vulnerabilities from Risks Using VEX, EPSS and CISA KEV

One way to structure and communicate this assessment is through Vulnerability Exploitability eXchange (VEX). VEX is a machine-readable format for communicating the applicability and exploitability status of known vulnerabilities in a particular product. It helps manufacturers explain whether a product is affected by a reported vulnerability and why.

VEX defines several status categories, including Not Affected, Affected, Fixed, and Under Investigation. For example, a manufacturer may classify a product as Not Affected if the vulnerable code is not present, the affected functionality is not used, or the vulnerable code cannot be reached under the product’s actual configuration.

However, assigning a Not Affected status must never be a shortcut for dismissing a finding. Every such conclusion needs to be supported by documented technical evidence and a clear rationale.

The Exploit Prediction Scoring System (EPSS) estimates the probability that a vulnerability will be exploited in the wild within the next 30 days, helping teams prioritize their efforts. The CISA Known Exploited Vulnerabilities (KEV) Catalog, on the other hand, lists vulnerabilities known to have been exploited in real-world attacks.

Both provide valuable input for risk assessment, but neither determines whether a vulnerability affects a specific product. EPSS supports prioritization, while KEV provides evidence of known exploitation. Ultimately, product-specific technical analysis remains essential to determine applicability and actual risk.

Building the evidence: Verification activities

Depending on the nature of the finding and the architecture of the medical device, different verification activities can help establish whether the vulnerable code is present, reachable, and exploitable in the product context.

Typical activities include:

• Source code analysis: Is the vulnerable function called, and under which conditions can it be executed?
• Configuration analysis: Is the vulnerable functionality enabled in the product’s actual configuration?
• Build analysis: Is the vulnerable code actually included in the released software?
• Dynamic testing: Can the relevant processing path be reached under controlled conditions?
• Fuzz testing: How does the component respond to invalid or deliberately crafted inputs?
• Penetration testing: Can the identified attack paths be exploited in the context of the actual product?
• Integration testing: Do security mechanisms and clinically relevant functions remain effective, even when errors or unexpected inputs occur?

These activities provide different types of evidence and should be combined.

The choice of verification activities should be proportionate to the potential risk and the technical characteristics of the vulnerability. Not every finding requires every test method, but every conclusion – particularly a Not Affected status in VEX – must be justified by sufficient, traceable evidence.

Ultimately, the objective is not simply to reduce the number of findings in a vulnerability report. It is to distinguish genuine product risks or other risks such as privacy risks from irrelevant or non-exploitable findings – and to make that distinction transparent, reproducible, and defensible.

An Additional Layer of Protection: Hardware Safeguards and Medical Device Risk Assessment

Finally, let’s return to our hypothetical medical device and look at another important aspect of the risk assessment: the system’s perspective.

Our software analysis indicates that the vulnerable code in the affected third-party dependency is never reached in the product’s actual configuration. This provides an important argument for concluding that the vulnerability does not affect the product. But we have another ace up our sleeve: the hardware itself.

Consider the device’s pressure regulator, waterflow regulator and heating element. All are designed with independent safety limits to prevent pressure, water flow or temperature from reaching damaging levels. Even if a software malfunction were to request an unsafe operating condition, these hardware safeguards would prevent the device from entering the corresponding hazardous state.

These mechanisms provide an additional layer of protection that complements our software-level analysis. Rather than relying exclusively on the assumption that the vulnerable code cannot be reached, we can also assess whether the device’s physical design limits the consequences of a potential software failure.

Of course, these safeguards must also be verified. Their independence from the potentially affected software, their operating limits, and their effectiveness under relevant fault conditions need to be supported by technical evidence.

This distinction is important: hardware safeguards do not automatically make a software vulnerability irrelevant. They can, however, provide additional evidence that the vulnerability cannot lead to a hazardous situation in the specific product context.

Conclusion

Assessing vulnerabilities in medical devices requires more than automated scanning. From SCA and SBOM analysis to vulnerability assessment and verification, manufacturers need a structured approach supported by technical evidence.

The key takeaway is that vulnerability assessment should consider the entire system – not just the software component flagged by the scanner. The combination of dependency analysis, verification activities, and independently effective hardware safeguards can provide a much stronger basis for a risk-based decision than the CVE finding alone.

Frequently Asked Questions

1. Does identifying a CVE in a third-party component mean that a medical device is vulnerable?

No. A CVE identified in a third-party software component does not automatically mean that the medical device is affected. Manufacturers need to verify whether the vulnerable component and version are actually present, whether the affected code is reachable, and whether the conditions required for exploitation exist in the product’s actual configuration. The assessment should be supported by technical evidence.

2. Does a high CVSS score mean that a medical device is at high risk?

Not necessarily. A high CVSS score indicates the severity of a reported vulnerability, but it does not establish whether a particular product is affected or whether the vulnerability can be exploited in its specific environment. Product-specific analysis is essential to determine actual exposure and risk. EPSS and the CISA Known Exploited Vulnerabilities (KEV) Catalog can provide additional information for prioritisation, but neither determines product applicability.

3. Is a SOUP list under IEC 62304 the same as a Software Bill of Materials (SBOM)?

No. Although both provide information about software components, they serve different purposes. The SOUP list is part of medical device software lifecycle management, while an SBOM provides a more comprehensive and structured inventory of software components and their relationships, including dependencies. An SBOM therefore provides a broader basis for software composition analysis and vulnerability identification.

4. What is VEX and how does it help with medical device vulnerability management?

Vulnerability Exploitability eXchange (VEX) is a machine-readable format used to communicate whether a known vulnerability affects a specific product and why. It defines status categories such as Not Affected, Affected, Fixed and Under Investigation. VEX helps manufacturers communicate the results of their vulnerability assessments. A Not Affected status must always be supported by documented technical evidence and a clear rationale.

5. How can manufacturers verify whether a vulnerability affects their medical device?

Depending on the vulnerability and product architecture, several verification activities can be used:

• Source code analysis to determine whether vulnerable functions are called and under which conditions.
• Configuration and build analysis to establish whether vulnerable functionality is enabled and included in the released software.
• Dynamic testing to investigate whether relevant processing paths can be reached.
• Fuzz testing and penetration testing to assess potential exploitability.
• Integration testing to verify that security mechanisms and relevant product functions remain effective.

The selection of activities should be proportionate to the potential risk and technical characteristics of the vulnerability. Not every finding requires every test method, but conclusions should be supported by sufficient, traceable evidence.

By Verena Wieser, Medical Device Consultant