#supplychainsecurity Vulnerability Tracking VEX

A Deeper Dive into VEX Documents

By Derek Kruszewski on April, 15 2022

Back

At the end of last summer, I wrote a blog post explaining the merits of Vulnerability Exploitability eXchange (VEX) documents. Almost 8 months later, I stand by the importance of these documents when it comes to efficient management of vulnerabilities. With our CTO, Eric Byres presenting on this very topic at S4x22, it seems like a good time to come back to VEX documents and dig into what they actually look like.

There are currently two standardized formats available for VEX documents:

The Common Security Advisory Framework (CSAF) was the first format available. This format is released by OASIS Open, which is an international not-for-profit dedicated to producing open-source standards for cybersecurity, blockchain, IoT, and other areas. For those already familiar with OASIS, CSAF is a renaming of and major revision to the Common Vulnerability Reporting Framework (CVRF) v1.2, which was released by OASIS in 2017.

Cyclone DX, a standardized format for SBOMs by OWASP (Open Web Application Security Project), has recently been adapted to also create VEX documents.

Either schema can be used as a standardized format for releasing a security advisory or a VEX document. In this post, I’ll go over CSAF in detail, but the general anatomy of a VEX document holds for either format.

When CSAF is used to release a VEX document, there are three main sections: document, product_tree, and vulnerabilities. Take a look at the summary below to see how these sections and the information they contain are related:

anatomy_of_vex2

The document section contains typical document information, such as document timestamp, csaf_version, and author.

The product_tree section includes details on the products that have been assessed for vulnerability exploitability.

The vulnerabilities section includes information on a vulnerability (or vulnerabilities) with details on the status as it relates to the products listed in the product_tree section.

By combining the information provided in these three sections, a VEX document lays out a path that asset owners can follow to identify which products they need to address — the vendor products that actually contain exploitable vulnerabilities.

While this diagram does a good job of explaining the information included in a VEX document, it doesn’t prepare you for what you’ll see in an actual CSAF VEX document. But don’t let that worry you; in reality, VEX documents are intended to be machine-readable rather than human-friendly. Nevertheless, it’s useful to see and understand the structure, so let’s dive into a CSAF JSON schema and look at some of the key fields. At the head of the JSON, you can clearly see the three sections we’ve already discussed:

CSAF sections of a VEX document

Expanding the document section, you can see the document properties, which are all straightforward:

CSAF document section of VEX document

The product_tree section is more complex, so let’s focus on the branches property.

csaf_prod_section2

The branches property contains a hierarchy of products grouped together into families/product lines. Take a look at the following example to make sense of things:

CSAF product_tree example

Notice how the product tree becomes increasingly specific until landing on a distinct product. These trees typically start at a vendor and cascade through product groupings (i.e., branches) ending at enumerated products — each one with a unique product_id (the product_id being the attribute used to associate the product to a vulnerability).

The CSAF specification also has a product_identification_helper attribute that VEX producers can use to help communicate what a product name refers to. A product's CPE string, file hash, PURL, serial number, component ID, and SBOM ID are all encouraged additions to a VEX document. Nothing is as challenging (or as frustrating!) as a security advisory with the specificity of “Intel Drivers.” These attributes help consumers ensure that the product they have in hand is the same product that was analyzed for vulnerability exploitability.

Finally, we have the vulnerabilities section, where the product_status property details which products are affected by what vulnerabilities:

CSAF vulnerability section of VEX document

The primary categories of this section are known_affected, known_not_affected, under_investigation, and fixed. These categories are self-explanatory, so I won’t go into too much detail. However, it’s worth pointing out that when a product is known_affected, the remediations property provides details on what product users can do regarding the vulnerability (sometimes nothing). And when a product is known_not_affected, the threats property’s impact category provides details as to why a vulnerability is not exploitable in a product.

So with that, hopefully this brief tour of the anatomy of a VEX document provides insight and removes some of the mystery around what you’re seeing in these machine-readable documents. At aDolus we’ve been very fortunate to have some fantastic partner vendors that are using FACT for vulnerability detection and are also piloting the creation of VEX documents through FACT, so I look forward to sharing more details in the future. Until then, stay tuned and don’t hesitate to reach out if you’d like to explore more with FACT.

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.