VEX, A Primer
VEX is an acronym for Vulnerability Exploitability eXchange, developed by the National Telecommunications and Information Administration (NTIA).
According the guidance provided by NTIA , the primary use cases for VEX are to provide users (e.g., operators, developers, and services providers) with additional information on whether a product is impacted by a specific vulnerability in an included component and, if affected, whether there are actions recommended to remediate. According to Vulnerability Exploitability Exchange use cases by CISA, the goal of VEX is to allow a software supplier or other parties to assert the status of specific vulnerabilities in a particular product.
Why VEX ?
Just because a vulnerability in a software component is present does not mean that it is exploitable. A VEX framework provides additional context around the exploitability of that specific vulnerability in that specific component of a software product version. VEX offers four 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’s in a VEX?
VEX is a machine-readable artifact that contains product and vulnerability details. Currently, the VEX is available in two formats:
- The Common Security Advisory Framework (CSAF), developed by OASIS Open.
- CycloneDX, developed by the OWASP foundation.
Either of these formats can be used to communicate with customers and auditors. As per CISA, the VEX document must contain the following minimum elements
- VEX metadata such as VEX Format Identifier, 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 another identifier
- Vulnerability description
- Vulnerability Context: In terms of 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;
- 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.
Key VEX Use Cases
By using the information contained in a VEX document, users* can drive the following use cases:
- Additional exploitability context for specific or multiple vulnerabilities in different products associated with different versions.products or products and associated version or versions. This allows 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 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.
* Product security teams, developers, software vendors, security engineers & researchers.
In addition, VEX can also be used to address the same use cases in Operational Technology (OT) cybersecurity, which will help safeguard critical infrastructure.
Rezilion’s Dynamic SBOM and VEX
Rezilion’s approach to VEX aims to provide immediate value to customers by:
- Embedding VEX data right in the Ddynamic SBOM provides actionable insights into the discovered and exploitable vulnerabilities. Rezilion is able to do so because of the Dynamic SBOM, this may not be possible with a traditional static SBOM.
- Continually updating as changes happen in the software environment.
- Offering the Dynamic SBOM and VEX as exportable, machine-readable documents for easy sharing and collaboration.
The Rezilion platform uses runtime analysis to reduce the total attack surface from hundreds of vulnerabilities to a few vulnerabilities that require attention. Using the Rezilion platform, customers can automate the component inventory, vulnerability mapping, runtime analysis, and VEX with a Dynamic SBOM that is updated whenever there is a change in the customer’s environment. Using the Rezilion approach customers can:
- Reduce their software attack surface by up to 85%.
- Reduce the steps it takes to prioritize vulnerabilities.
- Get a unified contextualized view to drive cybersecurity posture by prioritizing vulnerabilities that need to be patched.
- Reduce remediation timelines from days to hours.
- Continuously see additional status justification values providing customers with additional details.
Get Started With Rezilion’s Dynamic SBOM and VEX