What does the future hold for VEX? And how would it affect you?

The rate at which new vulnerabilities are disclosed is constantly increasing. It currently stands at an average of 15,000 CVEs per year. 2022 stands out with over 26,000 new CVEs reported. Obviously, not all vulnerabilities are relevant to your software. To figure out if a particular vulnerability is a problem, you first need to figure out if you are using the library or product that contains the vulnerability, then figure out if you’re using the problematic version and module of that library. Finally, you need to consult with your development team to see if that vulnerability is relevant to your particular product and the way you’ve used that vulnerable library or product.

The process of figuring all this out is not simple and can take quite a lot of time. Tom Alrich, a well-known cybersecurity expert, estimates that about 95% of all CVEs present in a particular software product are not exploitable . But, if you’re an end user or a company about to integrate third-party software into their system, how can you identify the problematic 5% so that you can ask for proper remediation or patching?

This is where the idea of Vulnerability Exploitability Exchange (VEX) comes in . VEX’s purpose, as defined by from the U.S. National Telecommunications and Information Administration (NTIA) in 2021, is “to provide users (e.g., operators, developers, and service providers) 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.”

Right now you’re probably thinking — so how can I get these VEX documents, and start checking my components? Well, the reality of VEX use is, as usual, complicated.

Discover the purpose of VEX

Put simply, VEX is supposed to quickly and easily answer the question ‘is my version of this software exploitable to this vulnerability?’ .

The answer to that question is supposed to be one of four major options:

• Not affected: No remediation is required regarding this vulnerability.
• Affected: Actions are recommended to remediate or address this vulnerability.
• Fixed: These product versions contain a fix for the vulnerability.
• Under investigation: It is not yet known whether these product versions are affected by the vulnerability. An update will be provided in a later release.

Since VEX is supposed to be both machine-readable and machine-generated, the idea is to have a searchable database of these documents somewhere so that any interested party could query it and get the needed answer.

Since the assumption is that 95% of vulnerabilities are not exploitable in any given software product, this system is meant to thin down the massive lists of vulnerabilities found for each product to only those that the user should keep an eye on or request remediation or patching for.

There are a number of interesting facts about VEX’s history

Back in 2020, NTIA ( the U.S. National Telecommunications and Information Administration ) started discussing the idea of VEX as an accompanying tool to the (Software Bill Of Materials). In September 2021, the NTIA released a one-page introduction and explanation of what VEX is supposed to do.

Later, the effort to refine the requirements of the new advisory format moved under the auspice of CISA — the U.S. Cybersecurity and Infrastructure Security Agency, which released its own in early 2022 going into a bit more detail as well as some use cases that the VEX document was supposed to help with. The document, a draft, defined the minimum required fields of the VEX document in the same way that NTIA defined the minimum required fields of the SBOM.

Since then there were 2 major attempts at actually creating a machine-readable VEX documentation format:

CSAF is a comprehensive format but in order to actually use it successfully you need to include multiple fields and a lot of meta information making an actual adoption unlikely. The CyclonDX VEX initiative is much slimmer so when considering which VEX standard to use most would probably go with the CyclonDX format.

Why VEX has hit a roadblock — Uncovering the issues sabotaging its success

VEX is a good idea and could provide the valuable ability to quickly check if a particular vulnerability is in fact exploitable in a particular software product.

There are several problems, however, that are so far stifling its implementation:

• Filing responsibility — who should be in charge of filing the required VEX documents? Is it the software producers? Third-party security firms or non-profit organizations? A government agency? What would happen if multiple sources filed contradicting information?
• VEX database — who or what should save and categorize the VEX information? Assuming some of the documents would describe exploitable issues in software, isn’t there a danger that the information would fall into the wrong (malicious) hands?
• The current formats do not cover properly the question of versions and even less so the problem of combined versioning. Combined software/package versions refer to the practice of bundling multiple software packages or components together into a single release or installation package.

When it comes to vulnerability patching, combined software/package versions can both help and hinder the process. On the one hand, having a single installation package that includes all the necessary components can simplify the process of identifying and patching vulnerabilities. Instead of needing to manually identify and patch each individual component, you can simply apply the patch to the entire package.

However, the flip side of this is that if one component within the package is vulnerable, the entire software is vulnerable. This means that even if some of the components within the package have been patched, the overall package may still be at risk if a single unpatched component is present.

Let’s say that version 1 of library A in your software has a vulnerability. That problem is only manifest when library A is present with version 2 of library B. There is a security patch but not everyone would have installed it. That means that the VEX document for that vulnerability in your software needs to cover all possible combinations of the product, its versions, its contained libraries, their versions, and the possible patches released. That’s a lot of complex information that is not easy to express simply.

These are only some of the problems that any automatic tooling for dealing with VEX would need to understand and take into account.

Conclusion

Remember that any decent scan these days of a software product would produce hundreds if not thousands of possible vulnerabilities. Most people cannot deal with such a number. Alert fatigue sets in and the number of vulnerabilities becomes just that — a number.

The possibility of reducing the number of detected problems to a manageable amount would be a boon to software producers and users. The aim is to only focus on the real problems so that the software producer would be able to patch and remediate them as soon as possible.

Automated tools, like offer an easy way to see only the relevant vulnerabilities for each of your projects and builds, information that you can easily share, making the mountain of vulnerabilities significantly smaller and much more manageable.

An important caveat though is that this future, where we can easily see and respond only to the relevant vulnerabilities, would not be possible without the active participation of the open-source community. Most code these days is comprised of significant amounts of open-source software so we need the maintainers and developers of such libraries to take part in the discovery and remediation of the exploitable vulnerabilities plaguing their code.

The problem of relevant, exploitable vulnerabilities is not going away so it behooves us all to find the most efficient, cost-effective way to get the answer to the question: ‘is my version of this software exploitable to this vulnerability’ .

You can Learn more here.

Originally published at https://scribesecurity.com on February 15, 2023.

*** This is a Security Bloggers Network syndicated blog from Stories by Barak Brudo on Medium authored by Barak Brudo. Read the original post at: https://medium.com/@mr.lightning_54863/what-does-the-future-hold-for-vex-and-how-would-it-affect-you-121eddfabf7b?source=rss-48bdf18a8d23------2