What is VEX?

Vulnerability Exploitability eXchange (VEX)  is a machine-readable artifact that contains product and vulnerability details. It is also a form of security advisory that aims to inform users about the potential for exploiting components with known security flaws within the context of the product in which they are utilized. Software vendors and other parties can convey the exploitability status of vulnerabilities using VEX, making it clear which exposures are risky and which are not.

The VEX report is mainly focused on identifying whether a vulnerability is exploitable or not in the product. And this information can be identified by looking at the sub-field “status” of the vulnerabilities field of the report.

The “status” displays the following options in the report:

1. Exploitable: If so, the publisher believes there is a potential that a malicious actor could exploit the vulnerability. In this case, it is advisable to take the proper measures before integrating the product into your system and keep a track of it to update it as soon as the patch is available.
2. Resolved: This indicates that the publisher has made a code or configuration update that closes the relevant vulnerability.
3. Resolved_with_pedigree: Similar to the previous status, this one signifies that a component listed elsewhere in the SBOM underwent a code change that resulted in a new version.
4. In_triagle: This indicates that the publisher is still evaluating the problem. In this case, it's better to introduce the product in a secure environment, and it's important to monitor it continuously as you are not aware of the problem yet.
5. False_positive: This indicates that the alleged vulnerability in the involved SBOM is false.
6. Not_affected: This indicates that the aforementioned problem cannot affect the component or service.

Analyzing a VEX Report

The defined format for VEX documents is the Common Security Advisory Framework (CSAF) which was released by OASIS. So in this blog, we are going to analyze the VEX report according to the CSAF format.

Let us understand the VEX document with the help of an example of VEX document by the OASIS CSAF Technical committee on GitHub: https://github.com/oasis-tcs/csaf/blob/master/csaf_2.0/examples/csaf/csaf_vex/2022-evd-uc-01-a-001.json

VEX report is a binding of 3 important elements which are:

Document: 

The document section includes standard document data. This data consists of the CSAF version, publisher information, and revision history. You can see the example of the following information present in the document section of the JSON format of VEX document:

Product_Tree:

The product Tree section consists of the product detail that has been assessed for vulnerability exploitable. It basically Lists all products referenced in the CSAF document. 

From the above example, you can see that the product_id is mentioned which is used to map the vulnerability in the VEX document.

Vulnerabilities:

The vulnerabilities section displays the list of vulnerabilities affecting one or many products it consists of its CVE_ID, a short description of the vulnerability, any possible remediation, and most important part the status of the vulnerability which is used to identify whether it is actually important to focus on this vulnerability or not. This status can be any of the following:

• Not Affected - There is no need to address this vulnerability.
• Affected - The remediation or addressing of this vulnerability is advised.
• Fixed - States that the vulnerability has been fixed in these product versions.
• Under Investigation - It is not yet known if the vulnerability affects these product versions. A subsequent release will include an update.

From the above example, you can see that CVE-2021-44228 is showing the status affected for the product_id CSAFPID-0001 which means instant remediation is required in that product against this vulnerability.

Gaps in VEX document:

• A VEX document is a claim about whether a software product is affected by a given vulnerability. So, it is left to the reader whether or not to believe the publisher.
• If there is no CVE or common Bug ID for a vulnerability, referencing it could be challenging.

Additionally, there is no subcomponent metadata to indicate which CVEs might be found in the product's subcomponents. Although it doesn't directly address the problem, CSAF 2.0 does offer a URL link to get an SBOM from the product tree. However, This comes with the standard set of problems in URLs, such as broken links and a lack of non-repudiation.

Conclusion

VEX provides us with a promising standard format to declare whether a product is vulnerable to a given vulnerability. In the future VEX can become a common tool that helps security analysts and service operators assess risk and prioritize vulnerabilities.

‍

SecOps Solution is an award-winning agent-less Full-stack Vulnerability and Patch Management Platform that helps organizations identify, prioritize and remediate security vulnerabilities and misconfigurations in seconds.

To schedule a demo, just pick a slot that is most convenient for you.