SBOM VEX

What is VEX and What Does it Have to Do with SBOMs?

By Derek Kruszewski on August, 12 2021

Back

Recently, we have been fielding many inquiries here at aDolus regarding “VEX.” If you are not familiar with this mysterious abbreviation, you’ve fortunately landed in the right place. This blog post explains what VEX is and the crucial role VEX plays within the Software Bill of Material (SBOM) space.

To understand VEX, it’s best to go through an example of how it came to be. Suppose an ICS asset owner has a particular product used in a critical system and needs to provide a report on how secure that product is. The owner, being responsible, likely goes to the vendor/OEM and requests the product’s SBOM (and if they are lucky, the vendor provides it). Then, with SBOM in hand, the asset owner can check all the components and component vendors and do an assessment of the vulnerabilities within. (This process can be agonizing to do manually.)

Through the assessment, the owner discovers there are over 200 vulnerabilities in the product! Furthermore, some of these vulnerabilities are marked as critical in the National Vulnerability Database (NVD), so panicking, the asset owner rushes back to the OEM demanding solutions.

The OEM customer support rep, who is also being bombarded by 100 other customers on the same product, emails each customer explaining that the critical vulnerabilities do not affect their product and only a few of the 200 vulnerabilities are actually exploitable. Relieved, the asset owner moves forward only to have the cycle of panic repeat no less than a month later. A new critical vulnerability is discovered in the product’s subcomponents, and the owner, along with all those other customers, rushes once again to the OEM demanding answers. Much time is wasted all round. Clearly, this scenario is not ideal for either party.

Enter VEX.

VEX stands for Vulnerability Exploitability eXchange. It is what NTIA describes as a “companion artifact” to an SBOM and is the idea that product manufacturers and software suppliers can discover (using tools like FACT) vulnerabilities within third-party dependencies of their products and preemptively assess the exploitability of these vulnerabilities. This is important because not all vulnerabilities merit panic. In many cases, a vulnerability may exist in a component, but for the specific product in question, it is inaccessible to attackers or missing entirely. For example, the famous HeartBleed vulnerability in OpenSSL required specific features to be activated in a product in order to make the vulnerability exploitable in ICS products like firewalls.

Once the assessment is completed, the suppliers can export the results into a standardized, machine-readable “VEX document” that customers can access and easily interpret.

Let's revisit the above scenario, but this time with VEX documents available. The asset owner obtains the SBOMs and vulnerability assessment per usual but this time also obtains VEX documents from their OEM and sub-suppliers if needed. Incorporating all 3 documents, they use their asset management system (or FACT) to process the VEX documents to determine which of the 200 vulnerabilities are actually exploitable. And happy day! They determine that only 20 vulnerabilities are indeed exploitable. That’s a number that the asset owner can actually deal with: it’s actionable rather than paralyzing. Furthermore, the VEX documents contain various remediations for these 20 vulnerabilities and the asset owner can quickly review options to mitigate risk without having to contact the OEM.

Wow. That was a long example, so here is a summary of said process courtesy of NTIA:

VEX + SBOM Flowchart of Components

If that all made sense and you can see how incredibly useful VEX is, stay tuned for my next blog post where I’ll go into a deeper technical dive on the format of a VEX document.

Derek Kruszewski

Derek Kruszewski is a data scientist and mechanical engineer with a passion for automating control systems using AI, particularly at oil and gas facilities. Derek leads the vulnerability management innovations at aDolus and (with his extensive yoga background) can fix your back if it hurts.