User Story: How can we automate consumer use of CVEs with machine readable version ranges? #19
Description
In the form of: "As a role performing task, I struggle with problem because reason."
As a consultant to end user organizations that consume CVE records, I struggle with the problem that, when a CVE record contains a textual description of a version range, that information isn’t made machine readable. The reason this is a problem is that, if those organizations want to have complete information about known vulnerabilities in, for example, five versions of a product that fall within a range in a CVE record, they need to create a CPE name for each of those versions and add each CPE to the record. In practice, nobody has time for this, so they don’t do it.
Since probably most vulnerabilities apply to a range of versions, not just one, this is clearly a major problem. I was struck by the statement in Story no. 13: “If the OSV team could fix just one thing, it would be ensuring that version ranges are consistently and accurately represented—that single improvement would dramatically increase the reliability of automated vulnerability matching. Other attributes such as CVSS scores and CWE identifiers are useful for triage and classification, but consistent version information is the foundation on which all other automation depends.”
I agree with this statement. Note that this problem isn’t due to not having a format that represents a version range in a machine-readable form. There are multiple formats available for representing a version range; VERS is probably the leading format. The CVE Schema does not currently support any version range format, so today a version range can’t be represented in a machine readable form in a CVE record. It would certainly help if the CVE Schema supported one format and that format were consistently used.
However, the fact that CVE doesn’t support a version range format isn’t the real problem. The real problem is that currently it is not clear how end user organizations would make use of CVE records that include machine-readable version ranges if they did have access to them. My working hypothesis is that an important goal of end user vulnerability management is to learn which vulnerabilities affect any software product/version that is installed in their environment. This process needs to be automated as much as possible, including being able to utilize machine readable version ranges.
To illustrate this whole process (and show that it can be completely automated), let’s assume that the CVE Schema has been modified so that it supports the VERS format for version ranges (although which format is supported doesn’t matter). A CNA creates a new CVE-2026-12345. This CVE affects versions 2.0 to 4.5 (inclusive of the endpoints) of Product ABC. The CNA uses VERS to represent that range. Of course, the CNA also provides a textual description of the range.
An end user organization uses a vulnerability management tool that contains an up-to-date inventory of all software products in use by the organization, including the version number of each product. The organization utilizes versions 2.2, 2.6, 3.1,3.9 and 4.2 of Product ABC. When the tool ingests CVE-2026-12345, it first determines that this CVE is relevant to the organization, since the vulnerability affects Product ABC. The tool, which supports VERS, then compares each of the five version numbers in use to the VERS range and determines that each of those five instances of ABC is affected by the vulnerability. Therefore, the tool reports that each of the five instances of Product ABC is vulnerable to CVE-2026-12345 (although this needs to be confirmed, usually by scanning them).
If the end user organization has an up-to-date software inventory but it does not include complete version information for some products, including ABC, it might follow an alternative (and more labor intensive) process to achieve the same result: learning what CVEs affect software product/versions they utilize.
In this alternative process, the vulnerability management tool first ingests CVE-2026-12345 and notes that five instances of Product ABC are used by the organization. However, since the tool does not include version information for those instances, it cannot determine whether the version number of any of those instances falls within the range of affected versions represented in the CVE record with VERS.
Instead, the tool creates a text description of the range, e.g. “All versions of Product ABC that fall between v2.0 and v4.5, including v2.0 and v4.5.” Staff members then determine manually which of the five versions of ABC that are in use by the organization fall within that range; they determine that all five versions do.
While this second process is not as automated as the first, it still achieves the same result: identifying any instances of a product that is used by the organization, whose version number falls within the range specified in a CVE record that lists that product as affected. And it's still much better than the current situation, in which, whenever a user notices a new CVE that affects a product used by their organization, they need to read the text of the record to determine whether or not their version(s) of the product is affected.
Note that the above discussion does not necessarily reflect a vulnerability management process that is used by many end user organizations, or even one that would be desirable. Questions like this can only be decided by discussions among vulnerability management stakeholders, including representatives from software developers, CVE program participants (including CNAs), scanning tool vendors, software end user organizations, and interested consultants.
The OWASP SBOM Forum (a group I lead) is starting to discuss this question at our bi-weekly meetings. Anyone with an interest is welcome to join us. Please email me at tom@tomalrich.com.