A VEX use case: patching vulnerabilities

Tony Turner of Fortress Information Security suggested to me this week that one thing that has been sorely missing in both “official” and unofficial discussions of VEX is real use cases; he implied that there’s been far too much focus on formats and too little focus on why we need the formats in the first place. That made sense to me, and I decided to explore what I think will be one of the most important use cases for VEX: patching vulnerabilities. As you’ll see below, in the process I came to see that the number of steps that can be taken to describe what might seem to be a simple action can be huge, as can the benefits the supplier can realize from taking those steps.

Here is a scenario, along with steps that can (but don’t have to) be taken when a single serious vulnerability is patched in a single software product:

1.      Vulnerability CVE-2022-12345 has been identified in the NVD as exploitable in Bob’s Browser v4, which is a component of the supplier’s Product A.

2.      The supplier confirms, through their own testing, that this is indeed the case. They also confirm that Bob’s Browser v4 has been a component of Product A in every version, starting with v3.0.0 through the current version 3.5.2 (the supplier follows a best practice called semantic versioning, which requires a version string structure of [Major release].[Minor release].[Patch]).

3.      When they investigate the exploitability of CVE-2022-12345 in Product A, the supplier discovers that the vulnerability was not exploitable until version 3.2.0, due to a code change in version 3.2.0. They also discover that, in all versions from 3.2.0 through 3.5.2, the vulnerability is exploitable.

4.      The supplier develops a patch that fixes CVE-2022-12345 in versions 3.3.1 through 3.5.2 of Product A.

5.      At the same time, the supplier determines that a fix for versions 3.2.0 through 3.3.0 would be very difficult, and they decide to recommend that users of those versions upgrade to the current version as soon as possible.

6.      The new version created by applying the patch to version 3.5.2 is 3.5.3. When a customer patches their instance of 3.5.2, the version number is automatically incremented to 3.5.3.

7.      Similarly, when the patch is applied to any other version “A.B.C”, the version number will change to “A.B.(C+1)”. This is the normal procedure with semantic versioning.

8.      The supplier creates a VEX (in either the currently available CycloneDX VEX format or the upcoming CSAF-based VEX format) that indicates the following:

a)      CVE-2022-12345 is exploitable in Product A versions 3.3.1 through 3.5.2. The new patch should immediately be applied to all of these versions.

b)     CVE-2022-12345 is also exploitable in Product A versions 3.2.0 through 3.3.0. However, due to technical problems, the vulnerability will not be fixed in these versions. Users of these versions need to upgrade to the current version as soon as possible.

c)      CVE-2022-12345 is not exploitable in versions 3.0.0 up to (but not including) 3.2.0.

d)     The supplier has not tested for CVE-2022-12345 in versions before 3.0.0, since all of these versions are now unsupported. The supplier makes no assertion regarding whether CVE-2022-12345 is exploitable in unsupported versions of Product A.

Are you surprised that there are so many steps? After all, VEX has been advertised as a simple yet machine-readable way for a supplier to alert their customers that a vulnerability that is exploitable in a component of their product is not in fact exploitable in the current version of the product. These steps go far beyond that mission.

I agree with this analysis, but remember: The main reason why VEX is being developed is that some large suppliers are concerned that, when they start regularly providing SBOMs to their customers, their support lines will be overwhelmed with calls. This will happen when a serious vulnerability in a component in the current version of a product has been identified and customers want to know if it is exploitable in the product itself. If that were the only concern, a VEX would only need to state – in the above example – that CVE-2022-12345 is exploitable in the current version 3.5.2, and that a patch is available.

But should this be the supplier’s only concern? When customers learn that a vulnerable component has been included in the product through a number of versions, won’t they also call with questions like:

1.      “I’ve heard a lot about the new serious vulnerability CVE-2022-12345. Have you released a patch for it yet?”

2.      “I’m running [a non-current version] of Product A. Is CVE-2022-12345 exploitable in this version? And if it is, is there a patch for it?”

3.      “I work for an integrator, and we have customers running a number of versions of Product A. In which of those is CVE-2022-12345 exploitable, and in which is it not exploitable? Of those versions where it’s exploitable, for which ones is a patch available and what’s the URL to download it? And is the only solution for the other exploitable versions to upgrade to the latest release?”

4.      “I’m running [an unsupported version] of Product A. Will a patch for CVE-2022-12345 be released for my version?”

5.      “I’m running [a supported version] of Product A. I noticed you’re not patching this version, even though it’s under support. What’s the deal?”

All of these questions – and potentially a lot more - are likely to be asked, as a result of the above scenario. Without a VEX, the supplier will have no choice but to hold on and hope there aren’t too many of these calls. With VEX, the supplier will be able to answer some percentage of these questions, without tying up a single support person.

So it’s very likely that releasing a VEX will lead to a significant reduction in support calls for most products, after SBOMs have been made widely available. But here’s another consideration: What if Product A has 4,500 components, as some products do? There might be scenarios like this one every day, or even every hour. Without having recourse to VEXes, will the supplier of Product A even release an SBOM for it? After all, to do so might literally open the gates to a flood of support calls that could threaten the financial stability of the supplier.

This is why I have said repeatedly, “As long as suppliers can’t release VEXes in volume, they won’t release SBOMs in volume.” And that’s why getting VEX right is so important.

Here’s an extra credit question for you, based on an issue that has come up in VEX discussions: If the VEX weren’t able to handle version numbers and especially version ranges, would the above scenario be at all feasible? Of course not. There’s no way that the patch application use case could ever be addressed without having the ability to specify version numbers in the VEX.

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. Nor are they necessarily shared by CISA’s Software Component Transparency Initiative, for which I volunteer as co-leader of the Energy SBOM Proof of Concept. 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.