VDR or VEX – Which Do I Use? Part 1

VDR or VEX – Which Do I Use? Part 1

Part 2 covering ISO 30111 Part 1

The topic of Vulnerability Disclosure Reports (VDR) has risen to the fore as of late, largely due to the mention in the new NIST 800-161r1 Supply Chain guidance document. VDRs are not a new concept at all, and in fact are the topic of ISO 29147, 2nd edition last updated in 2018 covering Vulnerability Disclosures.

Unfortunately, with the advent of software bill of materials (SBOM) in the wake of EO 14028, and the subsequent need for Vulnerability Exploitability Exchange documents, or VEX, as a companion document to the SBOM, there is a lot of confusion occurring within industry. As this seems to be constantly evolving, I wanted to share my thoughts on the topic. I’ll share what we “know” based on guidance documents and call out my own personal opinions on the topic, but they are just that, opinions. Use your best judgement.

Why Did We Need VEX?

First, a bit of background on why we even needed a VEX in the first place. The concept was coined in the early days of the NTIA’s efforts in evangelizing SBOMs, because the SBOM was touted as a means to identify vulnerabilities in a component, as it relates to a given product. But in many cases, just having a component with a CVE did not mean the product was vulnerable, or exploitable. Backported fixes that did not update version numbers, code that never called the vulnerable function, or was not reachable or influenced by a user or process, or even mitigations implemented in code that would break the kill chain for exploitation, all resulted in scenarios where the SBOM said one thing, but the VEX could clarify whether it was truly a problem or not.

Like an SBOM, a VEX is designed to be machine readable, and is natively supported by the CycloneDX BOM format as well as the CSAF format. Most commonly, CSAF becomes a companion for SPDX SBOMs, but is also supported as a linked object with CycloneDX. But the purpose of the VEX is simply to clarify if the vulnerability identified in the SBOM is affected or not. This is achieved by defining the status of the vulnerability in that product as:

[Retrieved from https://cisa.gov/sbom/resources]

• NOT AFFECTED – No remediation is required regarding this vulnerability
• AFFECTED – Actions are recommended to remediate or address the 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

This now provides a simple, and easily automated way to trigger actions based on the status of exploitability, as it relates to an SBOM for a given product, and when correlated to assets, a very rich way to drive this process for Operators.

Now let’s look at VDR, as described in NIST 800-161r1

“…Enterprises, where applicable and appropriate, may consider providing customers with a Vulnerability Disclosure Report (VDR) to demonstrate proper and complete vulnerability assessments for components listed in SBOMs. The VDR should include the analysis and findings describing the impact (or lack of impact) that the reported vulnerability has on a component or product. The VDR should also contain information on plans to address the CVE. Enterprises should consider publishing the VDR within a secure portal available to customers and signing the VDR with a trusted, verifiable, private key that includes a timestamp indicating the date and time of the VDR signature and associated VDR. Enterprises should also consider establishing a separate notification channel for customers in cases where vulnerabilities arise that are not disclosed in the VDR…”

It is noteworthy that the NIST guidance, while a great start, does not capture the content of what should be in a VDR as succinctly as the ISO 29147 document, but the scope is a little different as well. If we extend the concept a bit using the cross-section of both documents, it’s clear that best practice for a VDR should include:

• General
• Identifiers
• Date and Time
• (New) Authenticity - Signed
• Title
• Overview
• Affected Products
• (New) Affected Components
• Intended Audience
• Localization
• Description
• Impact
• Severity
• Remediation
• References
• Credit
• Contact Information
• Revision history
• Terms of Use

A few takeaways here of note that distinguishes the VDR from the VEX:

There is no mention of machine-readability. Its not forbidden, but we need VDRs that humans can easily understand. And if you combine this with the guidance from ISO 29147, it becomes clear this is designed to inform humans there is an action they should perform or awareness they should incorporate into their risk management program.

The addition of signing is interesting, and almost implies machine-readability since verification of that signature is best suited for machine processes. Again, not required, but its safe to say that VEX could also stand to gain from signing the attestation. No reason why not, though existing VEX guidance does not call for it.

VDRs cover both components, and products, while VEX is focused on the product. The problem with component-centric analysis without product context is akin to why we needed VEX in the first place. Implementation matters. The same vulnerable component implemented in one product may not be exploitable, but it is in another, or maybe it’s the same product configured in different ways. Once you dive into the world of SBOM, there are so many scary things that bubble up, you can’t possibly fix them all.

VDRs cover both known and unknown vulnerabilities, while VEX is scoped to just the knowns. All of this above really starts painting the picture that VDRs cover more scope than the VEX, which begs the question, do I really need both? As Suppliers are accustomed to issuing VDRs already, though they are typically not signed, it will make sense for many to only issue the VDR. But its important to note that these statements by a Supplier may not convey enough context for the software consumer to understand if the vulnerability is really a concern. And if there is not a standard format for VDR defined, automation scenarios will suffer.

At the S4 industrial security conference in 2022, CISA and INL staff conducted a workshop with attendees where these topics were explored. In some cases, where only the attestation was provided, attendees did not trust the statements made by the suppliers and wanted more evidence. Whether that comes in the form of an SBOM or rationale as to why the vulnerability might not be an issue. Its clear that consumers need strong evidence supporting their decision-making.

Additionally, we’ve seen scenarios such as in the CISA document that indicate that a valid VEX response is that the component is not found so the vulnerability does not exist. This starts to feel much more like a VDR scenario than VEX. In my opinion, this should have never been part of the VEX flow, because the SBOM would have never flagged that vulnerability in the first place. It’s the perfect use case for a VDR though. What is needed is more clear understanding of when and how to use the VDR, and likewise, the VEX. These are likely companion concepts. My personal opinion is this:

Use VDR When

• A vulnerability needs to be disclosed that was previously unknown
• A vulnerability needs to be communicated at the component level
• A statement about vulnerability applicability needs to be made, such as “NOT AFFECTED” by log4shell
• A lengthy, or qualitative description of the vulnerability and supporting metadata is called for
• An update to a known vulnerability previously communicated should be issued
• A vulnerability disclosure needs to be communicated to humans

Use VEX When

• Automation and machine-readability is called for, such as enriching the SBOM to reduce false positives
• Clear and consistent language is needed to answer the “why” about exploitability, providing the context needed for defenders to make informed decisions
• Consistent mechanisms for communicating versioning, again this is an automation use case.
• Lastly, enrich VEX with signing. This is extremely important to validate the authenticity of the attestation

Closing Thoughts

Its clear more discussion is needed here, as these very closely related, but different concepts are both needed. We know the CycloneDX community is hard at work on VDR concepts in addition to existing VEX support, and its clear that other formats exist as well. There are existing tools, both open source and commercial to both generate, as well as consume VEX documents. More tooling would be welcome, as this space is immature, but tooling does exist today, regardless of the VEX naysayers. But the confusion parroted by some solution providers is not helpful, and no single entity can decide for the industry what the best approach is. This feels like a really great call to action for CISA as part of the ongoing VEX community effort and emerging SBOM workgroups. Let’s figure this out together and stop spreading confusion.