It’s no exaggeration to say that the CVE Program’s recent
near-death experience has set off a flurry of activity in planning for the
future of vulnerability identification programs (like CVE) and vulnerability
databases (like the NVD, as well as many others). In this
recent post, I described three different approaches that different groups are
taking toward this goal today. Of course, none of those approaches is better
than the others; they’re all necessary.
The approach I prefer to take – partly because I don’t see
anyone else taking it now – is to focus on improvements to the CVE Program that
can be made by next March, when the MITRE contract to run the program will come
up for renewal again. Since I lead the OWASP Vulnerability Database Working Group,
we are taking this approach. Instead of focusing on what’s best for the long
term (which is what the broader OWASP group is doing), we’re focusing on
specific improvements to the program that can be realized by next March, all of
which are necessary and many of which have been discussed for a long time.
Perhaps the most important of those improvements is version
ranges in software identifiers. Software vulnerabilities are seldom found in a
single version of a product. Instead, a vulnerability is first present in
version A and continues to be present in all versions up to version B. The
vulnerability is often first identified in B; when it’s identified, the
investigators then realize it has been present in the product since version A;
then they identify the entire range A to B as vulnerable.
For this reason, many CVE Records identify a range of
versions, rather than just a single version or multiple distinct versions, as
vulnerable to the CVE; however, this identification is made in the text of the
record, not in the machine-readable CPE identifier that may or may not be
included in the record.
This omission isn’t the fault of CPE, since CPE provides the
capability to identify a version range as vulnerable, not just a single
version. However, this capability is not used very often, for the simple reason
that there is little or no tooling available that allows end users to take
advantage of a version range included in a CPE name. The same goes for the purl
identifier, which is widely used in open source vulnerability databases. Even though
purl in theory supports the VERS
specification of version ranges, in practice it is seldom used, due to the lack
of end user tooling.
Why is there very little (or even no) end user tooling that
can take advantage of version ranges in software identifiers found in
vulnerability records? I learned the answer to that question when I asked
vulnerability management professionals what advantage having such a capability
in their tools would provide to end users (i.e., what the use case is for machine-readable
descriptions of version ranges).
When I have asked this question, few if any of these
professionals have even been able to describe what that advantage would be. It seems
clear to me that, if few people can even articulate why a particular capability
is required, tool developers are unlikely to try to include that capability in
their products.
However, I can at least articulate how an end user
organization could utilize version ranges included in a vulnerability notification
like a CVE record: They will use it when a) a vulnerability has been identified
in a range of versions of Product ABC, and b) the organization utilizes one or
more versions of ABC and wants to know whether the version(s) they use is
vulnerable to the CVE described in the notification.
Of course, in many or even most cases, the answer to this
question is easily obtained. For example, if the product ABC version range
included in the record for CVE-2025-12345 is 2.2 to 3.4 and the organization
uses version 2.5, there’s no question that it falls within the range. But how
about when the version in question is
1.
Version 2.5a?
2.
Version 3.1.1?
3.
Version 3.41?
More generally, the question is, “Of all the instances of
Product ABC running in our organization, which ones are vulnerable to
CVE-2025-12345?” Ideally, an automated tool would a) interpret a version range described
in a CPE found in the CVE record, b) compare that interpretation with every instance
of ABC found on the organization’s network, and c) quickly determine which
instances are vulnerable and which are not.
How can the inherently ambiguous position of the three
version strings listed above be resolved? The supplier of the product needs to
follow a specific “ordering rule” when they assign version numbers to products;
moreover, they need to inform their customers – as well as other organizations
that need to know this – what that rule is. The portion of the rule that
applies to each of the above strings might be
1.
“A version string that includes a number, but
not a letter, precedes a string that includes the same number but includes a
letter as well.”
2.
“The value of the first two digits in the
version string determines whether that string precedes or follows any other
string(s).”
3.
“The precedence of the version string is always
determined by the value of the string itself.”
Of course, for an end user tool to properly interpret each
version range, it would need access to the supplier’s ordering rule. If these
were sufficiently standardized, rather than always being custom created, it might
be possible to create a tool that would always properly interpret a version
range.[i]
However, they are not standardized now.
This means that the developer of an end user tool that can
answer the question whether a particular version falls within a range will need
to coordinate with the supplier of every product that might be scanned or
otherwise addressed by their tool, to make sure they have the most recent
version of their ordering rule; and they’ll have to receive every updated
version of that rule. Doing this would be a nightmare and is therefore not
likely to happen.
This would be much less of a nightmare if the ordering rules
were standardized, along with the process by which they’re created and updated
by suppliers, as well as utilized by end users and their service providers. However,
that will require a lot of work and coordination. It’s not likely to happen
very soon.
Ironically, all the progress that has been made in version
range specification has been on the supplier side. A lot of work has gone into
making sure that CPEs and purls (and other products like SBOM formats) are able
to specify version ranges in a manner that is easily understandable by human
users. However, that progress is mostly for naught, given that the required
tooling on the end user side is probably years away, due to the current lack of
standards for creating and utilizing ordering rules.
Unfortunately, I have to say it’s probably a waste of time
to spend too much time today on specifying version ranges on the supplier end. The
best way to get version ranges moving is probably to get a group together to
develop specs for ordering rules.
Don’t forget to donate! To
produce these blog posts, I rely on support from people like you. If you appreciate
my posts, please make that known by donating here.
Any amount is welcome!
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] If
you are a fan of “semantic versioning” – a versioning
scheme often used in open source projects - you might think that “ordering
rules” are a primitive workaround. After all, if all software suppliers followed
semantic versioning, they would all be in effect following the same ordering rule.
However, commercial suppliers often decide that semantic versioning is too restricting,
since if only allows a fixed number of versions between two endpoint versions.
Often, a commercial supplier will want to identify
patched versions, upgrade versions, or even build numbers as separate versions.
Semantic versioning provides three fields - X, Y and Z - in the version string “X.Y.Z”;
moreover, the three fields have different meanings (major, minor and patch
respectively), so one field can’t “overflow” into its neighbor. While open source
projects may not find these three fields to be too limiting, commercial
suppliers sometimes want more than three fields.
No comments:
Post a Comment