Blog HackRTU

‹ Regresar

THE VEX CONCEPT AND ITS APPLICABILITY WITH THE SBOM

 

CNA

 

 

The VEX concept or Vulnerability Exploitability eXchange, refers to a standardised format used to transmit information about the possibility of exploiting a vulnerability in a specific product, whether software or hardware.

Broadly speaking, although we will look at this in detail throughout the article, it allows different actions to be prioritised, such as applying patches, mitigations or even scheduling maintenance windows more effectively.

The detection of a vulnerability (CVE) is complemented by the information provided by the VEX, as the Vulnerability Exploitability eXchange focuses on whether the vulnerability in a component can actually be exploited in a specific context, i.e., for an exact model and version.

Unlike EPSS, which predicts the probability of a CVE being exploited in the coming days, VEX provides a standardised format for declaring whether a CVE is exploitable in a specific product and why. The main objective of VEX is to complement the SBOM (Software Bill of Materials) and, as mentioned above, to assist in the prioritisation of actions, although VEX can also be independent of SBOM.

 

VULNERABILITY EXPLOITABILITY EXCHANGE

VEX was created with the aim of allowing software or hardware providers to declare the status of specific vulnerabilities in a given product.

On 27 September 2021, the US National Telecommunications and Information Administration (NTIA) published an informative technical document on the term VEX and its use with CSAF (Common Security Advisory Framework) as an OASIS standard. VEX has materialised as a profile within CSAF, which is a standard for the creation and sharing of security advisories in a structured manner, typically regarding vulnerabilities.

In 2022, the Cybersecurity and Infrastructure Security Agency (CISA) began promoting the use of VEX, and the first open source tools for its implementation and use appeared. Currently, VEX has been integrated into leading tools on the market.

In short, VEX enables the following features:

• Allows a software vendor or other parties to declare the status of specific vulnerabilities in a component of a given product.
• A method for publishing security advisories, similar to those published by CNAs or PSIRTs but with significant improvements:
  • Integration with security tools and vulnerability tracking platforms thanks to the fact that VEX documents are machine readable, i.e. VEX follows a standard structure for organising information and tools can understand all fields without great difficulty.
  • VEX data helps to complement and enrich the use of SBOM.
• Enables increased automation throughout the vulnerability cycle at the level of disclosure, tracking and possible mitigations.

 

POSSIBLE STATES OF ACTION IN RELATION TO THE VEX

As VEX is an indicator of the status of a vulnerability for a specific component or product, hence its relationship with SBOMs, it allows these specific components or products to be classified into various statuses.

• Not affected (No affected): No remediation action is required.
• Affected (Affected): Actions are recommended to mitigate or correct the vulnerability.
• Fixed (Corrected): The product versions mentioned already contain the fix.
• Under Investigation (Under investigation): It is not yet known whether the versions are affected; an update will be provided in a later version.

The combination of an SBOM and the vulnerability status of VEXs provides a powerful, up-to-date view of the security status of products.

 

OPENVEX, OPEN AND SIMPLIFIED IMPLEMENTATION OF VEX

Within VEX standardisation, there are open and simplified implementations such as OpenVEX (Open Vulnerability Exploitability eXchange), currently in its v.0.2.0 specification, which follows the minimum requirements for VEX established in coordination between the VEX Working Group and CISA.

Below is an example for the CVE-2025-64386 vulnerability discovered by our researchers in early 2025.

• CVE: CVE-2025-64386
• Description: The team grants a JWT token for each connection in the timeline, but during a valid active session, token hijacking can occur. This will allow an attacker with the token to modify security settings, access or even steal the session without the legitimate, active session detecting it. The web server allows the attacker to reuse an old session JWT token while the legitimate session is active.
• CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
• Score: 7.7
• CWE: CWE-613 Insufficient Session Expiration

Now, with a basic understanding of vulnerability (more information about the CVE), the JSON-LD is displayed with the corresponding minimum fields:

{   "@context": "https://openvex.dev/context/v1",   "schema_version": "0.2.0",   "author": {     "name": "HackRTU",     "role": "Industrial Security Company"   },   "timestamp": "2025-11-05T09:00:00Z",   "document_id": "https://www.hackrtu.com/blog/cg-0day-003/",   "statements": [     {       "vulnerability": {"id": "CVE-2025-64386"},       "products": [         {           "purl": "pkg:circutor/tcprs1plus@1.0.14",           "type": "firmware",           "cpe": "cpe:2.3:a:circutor:tcprs1plus:1.0.14:*:*:*:*:*:*:*"         }       ],       "status": "affected"     }   ] }

 

The global JSON Schema can be found in its official repository. It lists all the fields that can be defined within the OpenVEX implementation of VEX.

At HackRTU, we see the VEX standard as a possible accompaniment to SBOM, a way to simplify the process and help suppliers provide more information about the possibility of a vulnerability in an asset, software, or SBOM component being exploited. Likewise, there are other terms, standards, and concepts such as EPSS that can help determine the possibility of a vulnerability being exploited but do not provide a list in a language and format that can be automated for integration into security tools related to vulnerability management.

 

 

HACKRTU TEAM