Companies increasingly adopt fast-paced security-related processes to their software supply chain. The sheer number of security tools makes it pretty easy to scan every artifact that travels through the CI/CD pipelines from development to production. Yet the number of security warnings, misconfigurations, and run-time events demand time and effort by a large number of security experts. Let alone responding to vulnerabilities, whether they are exploitable or not. Not detecting serious vulnerabilities leads to a so-called “false sense of security” whereas reporting too many false positives leads to “alert fatigue” of the security teams. Since vulnerability-related information also needs to travel through different departments of the company, it’s important that everyone “speaks the same language”. VEX documents stand for Vulnerability Exploitability Exchange and gain traction in many companies. Why VEX documents are relevant to your security strategy.
What and Why
VEX documents are an addition to the well-known SBOM (Software Bill of Materials). It was developed by the NTIA (National Telecommunications and Information Administration) to make the usage of SBOM easier and the actions derived from it more effective. In short, VEX documents pose the following characteristics / key benefits that act as a starting point for everything else that is related:
- Top most important: focus on exploitable vulnerabilities instead of all vulnerabilities. This leads to a laser focus on things that actually requires action. Don’t loose time fixing vulnerabilities that are not relevant to your IT product or pose no risk to your organization in another way.
- Adding the right context of vulnerabilities in terms of your IT product from an application as well as an infrastructure (environment) perspective. Again, only focus on exploitable vulnerabilities.
- Enrich the existing SBOM with vulnerability details, divided per component.
- Guidance on remediation: provide options and practical examples on how to actually remediate exploitable vulnerabilities.
- Support for automation for effective and efficient vulnerability management. This includes tracking and remediation.
Since VEX documents are written in a (machine-readable) standard format (keep in mind there are actually two standards), they enable an organization to exchange these documents using automated processes. Therefore they make it possible to accelerate the discovery, distribution, and exchange of the “need to fix vulnerabilities”. The collective knowledge of vulnerabilities and how to handle them becomes a “common understanding” in the organization.
Vulnerabilities or VEX?
Perhaps this all sounds familiar to you. It’s not so difficult to obtain a list of (potential) vulnerabilities in software applications. However, VEX is different here and that is also the true power. There is a brilliant article on the website of Energycentral.com. In this article, the differences between regular vulnerability lists and VEX are explained in greater detail.
As always, there are multiple standards that make up the specification in charge. Two are relevant here:
The CVRF (Common Vulnerability Reporting Framework) version 1.2 was released in 2017 and this acts as the foundation for the Common Security Advisory Framework (CSAF). This is an open-source format for security-related aspects of IoT, Blockchain, and other areas of Cybersecurity.
- The Open Web Application Security Project (OWASP) has standardized the Cyclone DX standardized format for SBOMS, thus acting as the base for VEX documents.
Characteristics of a VEX document
Which standardized format you choose, it’s important to know the structure of a common VEX document before you dive deeper into it. Every VEX document consists of the following elements which have (nested) branches:
- Document: mainly metadata about the document itself such as name, publisher, timestamp, version, category, etc.
- A mapping of the product tree. Every IT project consists of 1 or more IT products within turn versions of them. And those versions contain zero or more vulnerabilities.
- Vulnerabilities: those are split into multiple statuses that relate to the previously mentioned product in the product tree. Statuses include “known affected”, “known not affected” and “under investigation”.
Combining those 3 elements with the subset of additional information about you have a good way to go about managing your vulnerabilities. It acts as a “decision path” for every application/workload that poses security-related information in a structured format.
A little bit more details about the status of vulnerabilities:
- Known affected: proof exists that the component is actually affected by a vulnerability and there are practical remediation actions available at hand.
- Known not affected: No action is needed since the component is not affected by a particular vulnerability. This is a machine-readable format, so you can automate the processing of this field. Skip manually looking into it!
- To be researched or under investigation: it is not yet clear if the component is actually affected by the vulnerability. Monitor the vulnerability to find out if there are updates in the future.
- Fixed: a fix is available and/or applied to the version of the component in the current SBOM.
It does not matter which standard you use since the above-mentioned classifications are present in both of them.
Details of the document
CSAF offers a JSON file that presents all of the details of what you can expect in a VEX document. The complete JSON file can be found on their website. The sample below presents the metadata of various CVE-related elements which you can expect in a VEX document.
VEX documents are structured in JSON format. Despite the nested structure and thus an increasing complexity of (long) VEX documents, their processing of them can be easily achieved. Use the following hints as a starting point to create your business case(s).
Filtering and drilling down
- Filter VEX documents on IT products that actually have a fixed (set of) vulnerabilities so the security experts know how to remediate the issue. Suppose there are 10 teams that need to assess if a vulnerability applies to them and if it’s fixed or not, you can perhaps save 10 times 1 hour. If there’s more communication around a potential issue, you can save even more time.
- Focus on a single VEX document: an application owner (this can be an external vendor or an internal software team) only needs to maintain a single VEX document this is checked into source control. Potential use cases are an entire product line with all relevant vulnerabilities or updating the existing VEX document once there is a new vulnerability is discovered. This list should not be sent across the entire organization but the respective teams can just get a notification in case of a relevant update.
- Only process CVEs with high-risk scores. Only process issues that have a certain risk score & a recent release date. This filters out a lot of vulnerabilities that are not relevant here.
- Automatically send a notification to a message bus (pub/sub) or even to a chat channel in Slack or Teams to bring new threats to the attention of the respective teams. This saves time and effort to manually let them poll for new information. It also helps to better interpret the results of the vulnerability.
- One step further: automatically create new User Stories on the backlog of the IT team in charge. Therefore, the ticketing system (with the product ID) should match the product ID that is referenced in the VEX document. This gives an immediate insight into the impact of the vulnerability on the actual workload and burndown rate of the DevOps team.
Given these tips as a starting point, you can start to quantify the (proposed) benefits, create a business case, and present to the management why you need a budget to start processing VEX documents. Don’t forget to estimate the time and effort to create an MVP (Minimum Viable Product) as the very first practical implementation.
A practical example
The following screenshot of a sample VEX document in the CycloneDX format provides a great example of the elements and (nested) fields you can expect.
Here you’ll find the information about the vulnerability itself, the (external) references, the rating, and other information. These are followed by the (list of) CVEs that hold the create & updated date as well as a thorough description and deep links to the remediation. Two of the most important fields:
- Analysis with their ancestors (state, justification & response)
- Affects the component which is actually being impacted by this CVE.
Due to the increasing popularity of VEX document and their usage throughout companies, there are a number of professional companies that offer their help. A couple of them are CSOonline, Rezilion, and Ad.
The security advisory is all about trust. Do you trust a certain patch or solution and is this solution accepted by the “wider audience” as well as independent security experts? In case you require more detailed information about VEX (documents) and their structure as well as how to gain trust amongst all respective parties, check out the following whitepapers:
- Vulnerability Exploitability eXchange (VEX) – Status Justifications, presented by CISA (published June 2022) and
- Vulnerability Exploitability eXchange (VEX) – Use Cases, also from the CISA (published April 2022).
Both research papers contain a lot of references that present further information on numerous topics.
VEX document can greatly help you accelerate the set of activities around risk management and vulnerability management. It’s a (standard) to describe which vulnerabilities can actually be exploited given a certain product. Practically speaking it’s a JSON document and it’s an addition to a more traditional SBOM. Teams can focus on the vulnerabilities that matter most, and everything around VEX can be automated as much as possible and also integrated with workflow tools that you already use in your organization.
If you have questions related to this topic, feel free to book a meeting with one of our solutions experts, mail to email@example.com.