Vulnerability Exploitability Exchange (VEX): A Guide
What is VEX?
If you are a cybersecurity professional, especially with a focus on software security, and have not heard of VEX, it’s time to familiarize yourself with it. VEX is an acronym for Vulnerability Exploitability eXchange. The concept for this companion document for a Software Bill of Materials (SBOM) was developed by the National Telecommunications and Information Administration (NTIA) as a means to make the SBOM a lot more usable.
The VEX offers five key benefits:
- Vulnerability details: Provides additional information on a specific vulnerability, such that it can serve as a comprehensive list of associated vulnerabilities to a specific vulnerable component.
- Vulnerability context: As a companion document to the SBOM, it also provides additional vulnerability context to discovered components (as part of the SBOM) in software products and whether they are exploitable in that particular environment. In essence, the VEX is a diagnostic tool that pinpoints what vulnerabilities really matter.
- Remediation guidance: In case these components are exploitable, available remediation options are recommended.
- Automation support: Supports automation for effective vulnerability management, tracking, and remediation.
- Focus on what matters most: Enables organizations to focus on vulnerabilities that are exploitable and save time by not fixing vulnerabilities that pose no risk to the organization.
What You Need to Know About VEX: A Deeper Dive
VEX is a machine-readable artifact that contains product and vulnerability details. It can also be considered a form of a security advisory that provides context to whether a component is present in a product or if the product is affected by one or many vulnerabilities. It can easily integrate with existing tools and can be shared for use. CISA requires that the VEX document contain the following minimum elements.
- VEX metadata such as VEX Format Identifier (whether it is in CycloneDX or CSAF format), identifier string for the VEX document, author/publisher/vendor, a title, and a timestamp.
- Product details such as
- Product identifier(s)
- Product family identifier
- Supplier name
- Product name
- Version string
- Vulnerability details must have the following fields
- CVE or other identifiers
- Vulnerability description
- Vulnerability Context: In terms of a product and its software components relative to a particular vulnerability (CVE), the vulnerability context provided in a VEX includes the following four classifications:
- Not affected – A particular software component is not affected by this vulnerability and thus requires no remediation. In the VEX document, reasons for the “not affected” status are provided by a machine-readable field.
- Affected – The component is affected by the vulnerability and remediation actions are recommended.
- Fixed – This outlines that an available fix has been applied to a specific vulnerability in the specific version for which the SBOM has been created.
- Under Investigation or To Be Researched – Just as the name states, whether the components are affected by a specific vulnerability is not known and updates will be provided as available.
Currently, the VEX is available in two formats:
- The Common Security Advisory Framework (CSAF) was developed by OASIS Open.
- CycloneDX, developed by the OWASP foundation.
Either of these formats can be used to communicate with customers and regulatory agencies. It is important to note that VEX provides additional context only for known vulnerabilities.
Understanding VEX Status Justifications
If a particular software component is not affected, it is only logical for security teams to understand the reasons why that assertion was made by the software vendor in the VEX document. These assertions, or reasons, are known as status justifications.
Status justifications are clarifications or pre-defined sets of reasons that are expressed in the form of values as an optional machine-readable field of the VEX document. Like all other fields in a VEX document, it is up to the user to either accept or not accept this additional context while determining any remediation or mitigation action. It is important to remember that VEX provides additional context around known vulnerabilities/risks to software components, not unknown or new vulnerabilities for which the VEX will have to be updated.
In a recent publication titled Vulnerability Exploitability eXchange (VEX)– Status Justifications, CISA has provided pre-defined status justification values for “NOT Affected” vulnerability status for a specific software component of a specific software product version. This is very important as it helps customers understand the reasons and circumstances why that component has been deemed not affected.
How VEX and the SBOM Work Together
VEX and SBOMs are companion documents. Though they can be independently used, they provide a complete picture of risk in a specific context when used together.
A static SBOM and VEX can be used together by following these steps:
- Step 1: Create a comprehensive inventory or SBOM of all the software components present in an environment from applications to the cloud and at different stages of the DevOps lifecycle from development to production.
- Step 2: Map software components to known vulnerabilities using the National Vulnerability Database (NVD) and optional threat intel. This step creates a complete list of all vulnerabilities present in an environment (whether exploitable or not).
- Step 3: Apply analytical methods or other techniques to ascertain which of the vulnerabilities are actually exploitable and actually pose a risk.
- Step 4: Issue a VEX with justifications of “not affected” for software components that are not exploitable.
Examples of VEX Use Cases
On the surface, it may seem that the VEX has only one use case providing additional context around a specific vulnerability associated with a specific component of a software product, but it does much more. A VEX contains many combinations of products, versions, vulnerabilities, and statuses, which are nicely summarized in the Vulnerability Exploitability Exchange – Use Cases document by CISA. The following table provides a quick view into these combinations which drive the different VEX use cases.
Key VEX Use Cases
By using the information contained in a VEX document, product security teams, developers, software vendors, security engineers, and researchers can drive the following use cases:
- Additional exploitability context for specific or multiple vulnerabilities in different products, or products and associated versions. This allows us to confirm exploitable vulnerabilities and remove any false positives.
- Get information around available patches for specific vulnerabilities that can be applied ensuring security and lower operational costs and risks including crashes or downtime. This will also reduce alert fatigue from false positives.
- Create a realistic attack surface view to bring focus to remediation efforts.
- Use VEX for vulnerability advisories for potential customers and regulators when new patches or new vulnerabilities associated with software components are discovered.
- Use VEX with software audits by providing component inventory and associated vulnerabilities at a specific point-in-time to auditors.
In addition, VEX can also be used to address the same use cases in Operational Technology (OT) cybersecurity, which will help safeguard critical infrastructure.
VEX in the Future
As the VEX stands today, it is yet another artifact that provides information. In order for it to be broadly adopted and used, there needs to be work done in four key areas.
- Developing trust around the information contained in the VEX, after all the entire purpose of the VEX was to eliminate the vulnerabilities that are not exploitable.
- Automating the VEX process of creation, updating, mapping, sharing, and its consumption so that it can easily be integrated into the workflow.
- Additional details/values around status justifications.
- Format compatibility so that VEXes can be easily exchanged and used.