MedTech Terms
    The authoritative reference
    All terms

    Vulnerability Exploitability eXchange

    A machine-readable statement that explains whether a known vulnerability is actually exploitable in a specific product.

    Reviewed by Christian Espinosa, Founder, Blue Goat CyberLast reviewed May 5, 2026

    Definition

    Vulnerability Exploitability eXchange (VEX) is a machine-readable security advisory format that lets a software producer state, for each CVE that appears in their product's SBOM, whether the vulnerability is exploitable in their product ("affected"), not exploitable ("not_affected" with a justification), already fixed, or under investigation. VEX is typically expressed in CycloneDX VEX, CSAF (Common Security Advisory Framework), or OpenVEX formats. CISA publishes the canonical use cases.
    What the regulation says
    FDA's 2023 guidance encourages but does not yet mandate VEX. CISA strongly recommends pairing every SBOM with a VEX feed so operators can triage CVEs that affect components but not the integrated product. EU NIS2 and the upcoming Cyber Resilience Act in Europe move toward expecting VEX-style exploitability disclosures.

    What this means in practice

    Without VEX, every CVE that touches any SBOM component becomes a triage burden for hospitals. With VEX, vendors push the exploitability decision once and operators can filter their device fleet to the truly affected subset. Mature MedTech teams generate VEX as part of the same CI/CD flow that emits the SBOM.
    Common pitfalls
    • •Marking components 'not_affected' without a documented justification - the justification field is the whole value of VEX.
    • •Publishing VEX once at release and never updating as new CVEs are disclosed against existing components.
    • •Using inconsistent identifiers (CPE vs PURL vs SWID) that prevent automated matching against the SBOM.

    Frequently asked questions

    CISA defines five: component_not_present, vulnerable_code_not_present, vulnerable_code_not_in_execute_path, vulnerable_code_cannot_be_controlled_by_adversary, and inline_mitigations_already_exist. Every 'not_affected' status should cite one.

    Cross-references

    See also

    Closely related context worth reading.

    Primary references

    3 sources
    Link health: 3 verified· last checked 2026-05-09
    CISA·1OASIS·1OpenVEX·1
    1. 1
      CISA VEX Use Cases
      Verified
      CISAcisa.gov
    2. 2
      OASIS CSAF 2.0
      Verified
      OASISoasis-open.github.io
    3. 3
      OpenVEX Specification
      Verified
      OpenVEXgithub.com

    Inline markers like [1] jump to the matching reference above.