.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
What is VEX and Why Should I Care?
An SBOM without VEX is like peanut butter without jelly. SBOM is a top buzzword in cybersecurity, but it's important to understand why VEX (Vulnerability Exploitability eXchange) is such a critical companion document.
An SBOM without VEX is like peanut butter without jelly. SBOM is a top buzzword in cybersecurity, but it's important to understand why VEX (Vulnerability Exploitability eXchange) is such a critical companion document.
An SBOM without VEX is like peanut butter without jelly. SBOM is a top buzzword in cybersecurity, but it's important to understand why VEX (Vulnerability Exploitability eXchange) is such a critical companion document.
An SBOM without VEX is like peanut butter without jelly. SBOM is a top buzzword in cybersecurity, but it's important to understand why VEX (Vulnerability Exploitability eXchange) is such a critical companion document.
An SBOM without VEX is like peanut butter without jelly. SBOM is a top buzzword in cybersecurity, but it's important to understand why VEX (Vulnerability Exploitability eXchange) is such a critical companion document.
What is VEX?
VEX, or Vulnerability Exploitability Exchange, is a system for software producers to share with software consumers an assessment on the vulnerabilities present in their software components. VEX is the mechanism through which software producers classify and label the vulnerabilities in their software.
“The goal of Vulnerability Exploitability eXchange (VEX) is to allow a software supplier or other parties to assert the status of specific vulnerabilities in a particular product.” Source - CISA
VEX documents are used to provide a consistent and standardized way to describe vulnerabilities. They include standard details about the vulnerability, such as its severity, the software it affects. They also include an analysis of the vulnerabilities such as if the vulnerability may or may not be exploitable and why, and how the vulnerability can be mitigated or fixed, and any known workarounds that can be used to protect against it.
VEX Makes SBOM Better
VEX itself is a form of security advisory, but improves on traditional security advisories in two ways:
- It’s machine readable, so it can be integrated into other workflows and management tools.
- It proactively allows software producers to answer questions around the due diligence they’ve done on vulnerabilities to communicate if a vulnerability may be an actual risk.
An SBOM is like an inventory of all the components that make up a piece of software. It includes details about each component, such as its name, and version. You can use an SBOM to look up whether a version of a software package has any known vulnerabilities, but the SBOM will only tell you if vulnerabilities impact those software components, not the application. VEX allows teams to communicate not only the vulnerabilities that affect those software components, but also to explain if those vulnerabilities affect the application.
Here is an example snippet from an SBOM. As you can see, it provides basic information about a software component, its version and where the software component comes from:
One of the key benefits of VEX is that it provides a common language and format for exchanging information about vulnerabilities. This makes it easier for different organizations to share information and collaborate on addressing vulnerabilities.
VEX documents can be used to provide context and explanation for the vulnerabilities listed in an SBOM. For example, a VEX document might explain that a certain vulnerability has been fixed in the latest version of a component, or that the vulnerability doesn’t impact the code because the code is not reachable in the application. The below snippet from a VEX document allows organizations to communicate that the code through which a vulnerability is present isn’t reachable in an application and therefore that the application is not affected by the vulnerability.
How to Determine if You’re “Affected”
One of the key things a VEX document tells you, is whether or not a vulnerability affects your application, and gives developers an opportunity to explain why certain dependencies were or were not patched. Doing this manually is a time consuming process that asks developers to investigate each vulnerability and determine whether or not the vulnerable code is being used. Then they must annotate the finding within the VEX document accordingly.
To determine if an application is affected by a vulnerability, developers must manually investigate each vulnerability and determine whether or not the vulnerable code is being used in their application. They will need to examine the codebase, dependencies, and any third-party libraries that are used in the application. They must also take into account any customizations or modifications that have been made to the codebase.
With Endor Labs, this process can be automated. Endor Labs uses static analysis to learn how software dependencies talk to each other, and builds a callgraph to determine reachability. Once your dependencies are mapped, you can generate SBOM and VEX documents that automatically include reachability data, and annotate whether or not an application or libraryis affected.
If you want to see how it works, check out the SBOM and VEX video in our demo library.
How is VEX Used?
First let’s talk about how receiving an SBOM from a vendor without a VEX might look like. The SBOM describes all the dependencies that are included in an application. A security manager might then compare those software versions to a vulnerability database and see that several of those dependencies have critical known vulnerabilities.
Without a VEX document to provide context on whether those vulnerabilities are affecting the application, the security manager must go back to the vendor, and start a back and forth process of either going through each vulnerability and determining why it wasn’t patched, or just demanding the vendor fix every single vulnerability.
With VEX, the process might look like this:
- The security manager receives an SBOM document from a vendor that contains a component that has a vulnerability that hit the news headlines reasonably recently.
- The vulnerable library is listed in the SBOM, the security manager reviews the VEX document to determine the severity of the vulnerability and the likelihood of it being exploited. The VEX document would include information such as CVSS score and the due diligence the vendor has done around the vulnerability.
- Based on this information, the security manager can assess the criticality of the vulnerability and determine the appropriate action. For example, if the vulnerability has a high CVSS score and is exploitable, the security manager may prioritize patching the vulnerability as soon as possible.
- If the vulnerability is determined to be critical, the security manager will coordinate with the operations team to schedule a patch or update or the vendor to ensure a fix is available
- Finally, the security manager will monitor and track the vulnerabilities, and will ensure that the vulnerabilities are being managed effectively.
By using VEX and SBOM together, the security manager can quickly understand the status of the vulnerability and take appropriate action to mitigate,fix, or live with the vulnerability.
Learn about VEX with Endor Labs
Endor Labs Open Source includes SBOM and VEX generation. Because Endor Labs uses your source code as the source of truth, you can have confidence your SBOMs contain every direct and transitive dependency - offering no nasty surprises to your customers. Once your dependencies are mapped, you can generate SBOM and VEX documents that automatically include reachability data, and annotate whether or not an application or library is affected.