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 guidance 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 SBOM (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 document 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:
- The Common Security Advisory Framework (CSAF) was the first format available. This format was released at the end of 2022 by OASIS Open, an international not-for-profit dedicated to producing open-source standards for cybersecurity, blockchain, IoT, and other areas.
- Cyclone DX, a standardized format for SBOMs launched by OWASP (Open Web Application Security Project), that was adapted to also create VEX documents.
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.
- How would VEX cover software that is embedded in hardware with all possible versions and patches available there? Whose responsibility would it be to patch this software considering you can’t readily open the hardware and patch things yourself?
These are only some of the problems that any automatic tooling for dealing with VEX would need to understand and take into account.
Wouldn’t it be easier if you could request and obtain information for any version?
The assumption that the best way to share this important information is with a document is possibly an erroneous one. Producing enough VEX documents to cover every combination of version, patch, and vulnerability is a momentous task that, understandably, no one wants to undertake.
Scribe has built a platform for tracking and sharing security-related information for each build of a particular software project or product. As part of that, each build generates an accurate SBOM and a list of vulnerabilities that were discovered in the product.
Scribe enables the software producer to add advisories in VEX format to each of these vulnerabilities to note if they are not exploitable, under investigation, etc. Once a version is released all the security information about that version can be shared with interested third parties, users, regulators, and so on. Including the vulnerability list as well as the VEX advisory list means that the recipient should be able to look at only those vulnerabilities that are a potential problem in this particular product. It takes a lot of the burden off both the software producer who can “whitelist” their product and the software consumer who understands exactly what level of risk is involved in a specific software product.
As the software producer is the only one who can definitively say if a particular vulnerability is, in fact, relevant to a particular version of the product, they are the only ones who can add and modify advisories on their own products. The software producer’s judgment in this regard is final and non-contestable. The decision on who to share this information with is the software producer’s prerogative as well.
Since the full history of the product’s builds, SBOMs, and security information is saved by Scribe, users can easily request and get this information for any version they might be using throughout the entire software life cycle.
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 Scribe 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’.
This content is brought to you by Scribe Security, a leading end-to-end software supply chain security solution provider – delivering state-of-the-art security to code artifacts and code development and delivery processes throughout the software supply chains. Learn more.
Related posts
