Why do we need VEX?

Software bills of materials (SBOMs) are one of the brightest prospects in supply chain safety. To understand them, think of SBOMs as a list of all the parts that go into creating programs.

However, since we are showing EVERYTHING, regardless of how components are utilized, false positives when running a security scanner against it might easily come up. This is one drawback of the full openness made possible by SBOMs. Even if the component is not used, a scanner may flag the entire application as insecure if a piece of software contains a component, like a library, that is known to have a vulnerability in the linked version.

But just because a software component has a vulnerability doesn't mean that it can be taken advantage of. The Vulnerability Exploitability eXchange (VEX) enters the picture in this situation.

What is VEX?

Vulnerability Exploitability eXchange (VEX)  is a machine-readable artifact that contains product and vulnerability details. It can also be considered as 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 vulnerabilities are risky and which are not.

A profile for VEX has been added to the Common Security Advisory Framework (CSAF). The OASIS Open CSAF Technical Committee created the CSAF standard, which is used for security advisories that can be read by computers. The CSAF's definition of VEX also allows suppliers, systems integrators, and operators to give comprehensive information such as remediation, workarounds, restart/downtime requirements, scores, and hazards. Additionally, VEX can be integrated into other frameworks or standards.

How VEX works?

The asset owner still gets the vulnerability assessment and SBOMs from their vendor, but this time they also get the VEX papers. They process the VEX documents using their asset management system, incorporating all 3 documents, to ascertain which of the 200 vulnerabilities are indeed exploitable. They find that only 20 vulnerabilities—all of the low criticality—can actually be exploited. The asset owner can actually address that amount since it is actionable rather than paralyzing. The VEX documentation may also provide fixes for exploitable vulnerabilities, allowing the asset owner to swiftly assess risk-mitigation options without having to get in touch with the vendor.

Let us understand how VEX and SBOM can work together:

Consider the example,

• Suppose there is a susceptible component in software.
• After analyzing the software vendor finds that the flaw doesn't harm the finished product.
• After that, Suppliers issue a VEX stating that no action is necessary because the component is "not affected."
• Later on, the consumer combines VEX, SBOM, and vulnerability data to arrive at a risk-based decision.

A VEX asserts that a vulnerability exists in particular items. According to the status:

• 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.

Challenges with VEX?

The first issue to think about when reviewing a VEX document is the role of the individual providing an impact statement. Would you rather believe a software engineer working on the project or a stranger claiming that certain software is not affected by CVE-2022-WHATEVER?

A VEX document's credibility is based on the authenticity of the identity making the claim.

Even while we might be able to back up our statements with machine-verifiable evidence, doing so isn't always feasible or even practicable. Since VEX is intended to provide an expert's perspective, however, the inability to confirm effect statements shouldn't reduce confidence in VEX.

Final thoughts

VEX is an important next step in helping SBOMs become actionable, By offering contextual information and statements from product vendors on the exploitability of vulnerabilities found in their products, Software developers can enable software consumers to make risk-informed decisions to drive their vulnerability management activities as part of more comprehensive cybersecurity programs.

However, there are some areas where VEX can improve like:

• Automating the VEX generation, update, mapping, sharing, and consumption processes will make it simpler to integrate VEX into workflows.
• Additional information/values regarding status justifications must be included.
• Must improve the format compatibility for simple interchange and use of VEX.

‍

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.