#S4 Vulnerability Tracking SBOM VEX

S4x23 SBOM Challenge — Part 3: VEX Document Ingestion

By Derek Kruszewski on March, 16 2023

Back

Three weeks ago I reported on the first part of the S4x23 SBOM Challenge run by Idaho National Laboratory (INL), which focused on SBOM Creation. Last week I reported on the second part: SBOM Ingestion. Today’s blog post reports on the final goal of the S4x23 SBOM Challenge, where the participants were provided with INL-generated VEX documents for each target and asked to ingest them.

Unfortunately, these VEX documents had one main issue that made them problematic to ingest:

They weren’t VEX documents.

Let me explain…

When an end user obtains an SBOM for a device or creates one themselves using a tool like FACT, the SBOM is typically scanned for vulnerabilities. These vulnerabilities are then provided back to the user through a separate Vulnerability Disclosure Report (VDR).

A VDR is a document that lists all the vulnerabilities discovered in an SBOM for a single product. A great example of such a report format is contained within the CycloneDX specification. Important to note is that a VDR can also contain exploit information on the vulnerabilities detected in the SBOM, but the vast majority of VDRs out there are unlikely to contain this information. There are two reasons for this:

It is usually much harder to assess exploitability than it is to detect possible vulnerabilities. Figuring out whether a function is called in an application or whether inline mitigations exist is much more difficult than matching up package BusyBox 1.33.0 to cpe:2.3:a:busybox:busybox:1.33.0:*:*:*:*:*:*:*, so most tools out there don’t do this without expert human help.
If you’re wrong, there are consequences. Including exploitability information in a VDR requires a higher degree of confidence than just associating vulnerabilities to packages. Plenty of tool providers will not want to take on the liability of stating a product is not affected — what if a litigious user chooses to not patch based on this information and is later compromised?

It’s safer for tool providers to omit all information about exploitability and leave the unfortunate end users to assume a vulnerability is exploitable… and to do a whole lot of patching. (Note that aDolus appreciates the pain involved in unnecessary patching — the additional cost and labor, the potential for downtime, and the risk of installing less secure or robust versions).

What INL provided for this competition was more of a synthetic VDR that was presented within the Common Security Advisory Framework (CSAF) specification format and then called a VEX document. It’s an easy mixup. Both documents are new concepts, convey similar information, and are somewhat fluid since their structures and use cases are still being finalized.

So What Then Is a VEX Document?

A Vulnerability Exploitability eXchange (VEX) document is a document that simplifies the vulnerability intelligence found within a product, or many products (i.e., product families), to help end users quickly focus on the vulnerabilities that are most critical. Generally these are the vulnerabilities that are actually exploitable in a product — with particular attention to those vulnerabilities that are being actively exploited in the wild. VEX documents are great for a user who is trying to quickly find out if their product is affected by a high profile vulnerability, such as CVE-2021-44228 (Log4j). VEX documents are generally created by suppliers who have detailed insight into how their applications are actually using specific components. (Readers interested in a deep-dive can read another of my posts on the Anatomy of VEX documents.)

Here is a good example we’ve seen:

😱 Cisco releases the Meraki MR26 device and it is installed by an end user named Bob. Bob decides to check all his company’s devices for vulnerabilities and obtains an SBOM from either Cisco or a 3rd party like aDolus. Bob then scans the SBOM for vulnerabilities (or uses FACT to do this) and sees, say, 140 vulnerabilities. Bob freaks out and rushes to Cisco demanding answers.

😏 Cisco has already anticipated the panic. Before release, they used their own tooling to create an SBOM and analyzed it for vulnerabilities (note that for many suppliers, these SBOMs do exist but are considered “private”). Cisco then triaged those vulnerabilities and identified which ones were actually exploitable and which ones weren't. They assembled all this information, along with the assessments for all the other Meraki products, into one Meraki product line VEX document.

😌 Panicked Bob checks Cisco’s website and sees that they have a VEX document for Meraki devices. Bob opens it up, finds the products he’s worried about, and sees that 95% of the vulnerabilities detected by their tooling are not exploitable per Cisco for reasons X, Y, and Z. Phew.

🥰 Bob, being a clever chap, then requests that his company’s asset management system monitor Cisco’s VEX documents so that next time they get a VDR, the VEX document can be used to filter down the list of vulnerabilities demanding their attention (more examples here for those who are curious).

To showcase this workflow to INL, we used FACT to generate three VEX documents for each of the targets, just like we did for our customers in December 2021 during the Log4j fiasco. Here’s an example of one that we produced for them:

S4x23 SBOM Challenge Part 3 Screenshot

Notice how the document is simple. It basically tells us that “Cisco Meraki M26” firmware is not affected by the vulnerability “CVE-2022-22965.” The VEX document doesn’t go into detail as to where vulnerabilities exist within a product (although this information can be included for specific cases) because the end user typically doesn't care. The end user just wants to know what vulnerabilities they can ignore because they aren’t exploitable and what they can do about those vulnerabilities that are exploitable.

Note that we didn’t include impact or remediation statements in the above VEX document, which would typically be there for CVE-2022-22965, as we just wanted to get something out for demonstration/conversation purposes with INL.

Compare this demo file to one of INL’s VDR-but-named-VEX documents:

Notice how this document is enumerating every single sub-package within the SBOM and there are hundreds of packages listed. This information doesn’t need to be in a VEX document. Well, why not?

Why Have Both VDRs and VEX Documents?

Why not just combine VDRs and VEX documents? It seems complex to have two different vulnerability documents.

There are a few reasons:

VEX documents can contain vulnerability information for multiple products or product families. For example, Cisco might host one VEX document updated monthly for all of its Meraki devices that end users could fetch and periodically check if their specific product is impacted by the latest vulnerabilities. In contrast, VDR documents are only for one specific version of a single product.
VEX documents are usually created by suppliers or a partner like aDolus who captures their exploit assessments and bundles them up with a button click. This is because performing exploit assessments is difficult without expertise and source code. Alternatively, VDRs can be made by anybody and everybody by matching CVEs to SBOM components. One VDR can vary significantly from the next depending on whether the vulnerability analysis provider used a source code or binary SBOM.
VEX documents are a publicly-facing consolidation and simplification of data designed with the end user in mind. They typically don’t contain long lists of which subcomponent contains which vulnerability because this information isn’t useful for end users who just want to know if they need to deal with a vulnerable version of BusyBox in their product. They don’t care where in the product BusyBox was found unless it is in relation to a remediation.
An SBOM is not required to utilize a VEX document. You don’t need an SBOM to utilize the information “This Cisco device is not impacted by this Log4j vulnerability, even though it uses Log4j, because of XYZ reason.” A VDR is a time-slice companion to an SBOM as to where vulnerabilities were detected within the bill of materials. It will lack information pertaining to any vulnerabilities disclosed after its production.

Read our White Paper on VEX Documents for a Deeper Dive

Final Recap

Wow, that was a lot. Thank you for bearing with me.

Hopefully it is apparent to you that this S4x23 SBOM Challenge was made more interesting by some of these curveballs. Big kudos to INL and Dale Peterson for hosting this event. The Challenge has brought up several important talking points that are actively being discussed today. SBOMs, VEX, VDR, CycloneDX, CSAF… we’ve got an alphabet soup of standards and they are all evolving quickly. Executive Order 14028 lit something of a fire under participants in the software supply chain and now both industry and government stakeholders are innovating at breakneck speed.

If you find VEX interesting and want to get involved in its evolution, Allan Friedman at CISA hosts VEX working sessions, as does the principal blogger, Tom Alrich. Many of the points made in this post on VDRs versus VEX documents are being actively discussed now, so I encourage anyone with an opinion to reach out to those individuals or us, and we’d be happy to facilitate.

Looking forward to hearing further opinions from others on the event.

As always, if you are interested in seeing a demo of how FACT presents enriched SBOMs and generates NTIA-compliant SBOMs for compliance, attestation, etc., we’d be very happy to oblige. And if you are an OEM/Vendor, we’d be happy to show you how FACT automatically generates VEX documents that you can provide to your customers when the next log4j-type vulnerability crisis occurs:

And if you would like to see how FACT generates SBOMs, as always, we'd be happy to show you!

Cheers,

Derek

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.