Friday, October 27, 2023

You’ve got a new VEX format? Great! How will it be used?


Red Hat came out with their new VEX format this week and described it in this blog post (Pete Allor of Red Hat also discussed it in today's OWASP SBOM Forum meeting). You might say that VEX is on a roll lately, with Cisco having announced their VEX format in September. Also, Oracle is publishing VEX documents, but I haven’t seen a description of their format yet. However, it’s clear that all three of these formats differ from each other.

Is it a problem that they’re different formats, all carrying the name VEX? There’s certainly no trademark on the VEX name (any more than there’s a trademark on “SBOM”). Moreover, the only published definition of VEX is in the CISA “VEX Use Cases” document. It reads, “A VEX document is a binding of product information, vulnerability information, and the relevant status details relating them.” In other words, any document that mentions a product, a vulnerability, and the “status details relating them” (with status being undefined, so it could mean almost anything) can be called a VEX document. All these documents, as well as OpenVEX documents and probably anything else that’s ever been called VEX, easily meet that low bar.

However, there’s a much higher bar that needs to be met, and I know of no VEX format in use today that can clear it. That bar includes three parts:

1.      There must be a defined use case for the document, and it must be a machine-readable use case. In other words, simply “providing information on vulnerabilities that affect/don’t affect Product A” isn’t a machine-readable use case. If that’s your goal, I can save you a lot of time and effort: You can enter that information into a PDF document and email it to your customers. Only if the document you produce is machine readable and intended to be utilized as part of a larger automated use case – e.g., “allowing customers of Product A Version 2.3 to automatically remove from their list of component vulnerabilities those that have been determined by the supplier not to be exploitable in that product/version”[i] – is it worthwhile to produce VEX documents.

2.      There must be a tightly-constrained specification for the format; specifically, it needs to address only one use case[ii]. Even if the VEX document “sits on top of” a more general vulnerability reporting format like CSAF or CycloneDX, that fact alone doesn’t constitute a specification (and by the way, there will never be a single VEX specification applicable to all the different platforms that currently form the base for documents called VEX – CSAF, CycloneDX, and OpenVEX. They are just too diverse. For that matter, there is no single SBOM specification that encompasses both CycloneDX and SPDX SBOMs; they are too diverse as well).

3.      The specification needs to be tightly enough constrained, that it will be possible to develop two completely interoperable tools. The first is a VEX production tool that allows a supplier to produce a VEX simply by asking a set of questions that can be answered without prior knowledge of the format (e.g., “Which vulnerability/vulnerabilities will be addressed in the document?”).[iii] The second is a VEX consumption tool[iv] that is limited to reading documents produced in the tightly constrained format on which the production tool is based.

As I’ve already advertised, the OWASP SBOM Forum has formed a sub-group, now meeting bi-weekly, that is going to produce a VEX format that meets all three of the above criteria. Our first step is to produce a detailed use case for VEX, which is in progress in this Google Doc. You are invited not only to review the document, but to add comments or suggest changes. No permission is required to do that.

We plan to finalize the use case document within a few weeks and move on to developing the specification. Since we have decided that a CSAF specification is more urgently needed, we will develop that specification, and one of our members might develop prototype tools to produce and consume VEX documents that follow that specification.

Then, we’ll start with the specification based on the CycloneDX platform, and probably produce tools for that format as well (since there are already lots of tools that produce and consume documents using the base CycloneDX format – which underlies CDX SBOM and a number of other BOMs, as well as VEX and VDR documents – and since we will have learned a lot in developing the CSAF specification), we expect the CDX VEX tools will be much easier to produce. In fact, there are already tools that produce and read “VEX” documents based on the CDX platform, but none of these are likely to follow the VEX specification we will develop.  

What is the use case we will base our VEX specifications on? I’ll be honest that I want it to be the one laid out in the Google Doc, which can be summarized in this quotation from the only document on VEX produced by the NTIA VEX working group:

The primary use cases for VEX are to provide users (e.g., operators, developers, and services providers) additional information on whether a product is impacted by a specific vulnerability in an included component and, if affected, whether there are actions recommended to remediate.

Why do I want this use case? Having attended most VEX working group meetings from the second meeting under NTIA until recently, I can attest that this was the only use case even discussed for at least the first year of the group’s existence. VEX was driven by a few very large software (and device) suppliers that were quite concerned that their help desks would be overwhelmed with calls from frantic customers, once they started receiving SBOMs and looking up the components in the NVD.

The great majority of component vulnerabilities they learn about will be false positives, meaning they only affect the component if tested independently; they won’t affect the product itself. The VEX will be ingested by a vulnerability management tool that first ingests an SBOM and then guides the organization’s response to the vulnerabilities identified through that SBOM. Ideally, the VEX will reduce that list to include only exploitable vulnerabilities.

It will be years before there are true end-user tools (licensed commercially so the user organization has just one throat to choke when problems arise) for this purpose, but – as discussed in the use case document – third party service providers should quickly arise to address this use case. But that is unlikely to happen until there is a single agreed-upon VEX specification, although with two variants (CSAF and CycloneDX).

But there’s an even more important reason for this to happen: As I’ve said many times before, there are a small number of “showstopper” problems that are preventing SBOMs from being used to any significant degree by organizations whose primary business isn’t software development. I used to think the naming problem was the number one showstopper, but more recently I’ve come to realize that VEX is number one. I’ve heard a number of suppliers say that they won’t put out SBOMs to their customers with any regularity, until they’re sure they’ll be able to identify for their customers – in a machine-readable fashion – which of the component vulnerabilities they learn about aren’t exploitable in the product itself, and therefore can be safely ignored.

The existence of this tightly constrained spec, as well as at least one service provider that is willing to prototype the service described in the “VEX Use Cases” document, should be enough to at least have a real proof of concept for production and utilization of machine readable SBOM and VEX documents. at that point, it will be much more possible to at least frame the remaining issues. Those issues will have much more to do with practices and processes, not with technical specifications. Since those issues will be much more amenable to being addressed through jointly agreed upon guidelines, we should be able to make much more progress toward widespread use of SBOMs themselves at that point. Perhaps there’s light at the end of the tunnel after all!

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com.

I lead the OWASP SBOM Forum. If you would like to learn more about what that group does, please go here.


[i] This was the original use case for VEX under the NTIA. However, it was never explicitly articulated, with the result that we find ourselves today in the situation where VEX can be anything and is therefore nothing.

[ii]  This isn’t to say there’s only one use case for VEX; there are already a number of them. But it is to say that each of those use cases needs to be addressed in a different specification, and therefore using different tools. If that isn’t done, we immediately get into the situation where it becomes impossible to develop tools, as described in this post. I’m sure that in the future, there will be tools that can create or consume multiple VEX formats; but it’s useless to concern ourselves with them now.

[iii] This is especially important for VEX documents in CSAF, which has a tremendously complex specification. Very few software developers have the resources or time available to learn that spec well enough to create documents on their own, and even fewer end users could learn it well enough to create a useful consumption tool on their own.

[iv] This will always be part of a larger tool, since, as already discussed, simply reading the information in a VEX document doesn’t constitute a use case for VEX. A PDF attached to an email is a much better way to address that use case.

No comments:

Post a Comment