There’s an interesting multithreaded discussion about version ranges going on in the CVE program’s Consumer Working Group (CWG) mailing list. In one of the threads, one of the participants asserted that version ranges are useless for identifying affected versions (i.e., versions of a software product that are affected by a particular vulnerability identified with a CVE number) by saying
“Here is a real world example using OpenSSL to show that it is not practical to use version ranges to identify affected versions:
OpenSSL had 13 releases between versions 1.0.2 and 1.1.0c. Can you tell me if 1.0.2d is one of those releases? How about 1.0.2k?”
Of course, the answer to the question this person asked is, “No, there’s no way to determine if 1.0.2d or 1.0.2k is one of those releases.” Does this mean it’s a waste of time to specify version ranges in a machine readable form? If so, that’s bad news for vulnerability management, since vulnerabilities often (and maybe usually) occur in a range of versions in a software product, not just in one version.
This is because a software supplier often goes through multiple new versions of a product before they realize there is a vulnerability and track down where in the code the vulnerability occurs. If stating a version range is useless, then the only way for a supplier to report a vulnerability that occurs in a range of versions of a product is to list every version in that range in the CVE record. And if there are a thousand versions in the range – well, the supplier (or the CVE Numbering Authority, or CNA, that creates the new CVE record) may have to spend a whole afternoon listing every one of those versions.
Fortunately, the person who wrote the four or five sentences quoted above was wrong, although – as is usually the case in discussions about software – the correct answer has an asterisk. Here is how I replied (I’ve revised my words to make them intelligible to a wider audience):
There are two types of version identification schemes: those (like semantic versioning) that are monotonically increasing and those that are not. Briefly (and not entirely accurately), a monotonically increasing function is one whose value increases in each new instance; that is, the fourth instance is always greater than the third, the fifth instance is greater than the fourth, etc.
Version ranges are very useful for monotonically increasing versioning schemes, since it's easy to determine whether a version identifier falls within a range. For example, 3.5 falls within the range of 3.2 to 4.6, while 2.7 does not. On the other hand, it's impossible to determine whether for example 12.4(8e) precedes or follows 12.4(9d). This is how Cisco used to specify IOS versions. It's not monotonically increasing.
In the OpenSSL example provided, 1.0.2 is a monotonically increasing version identifier, while 1.1.0c is not. If a software supplier mixes version identifiers like that, it's true there will be no way to determine whether or not any particular version number falls within a range. That's why all suppliers should use monotonically increasing version identifiers. Fortunately, a large proportion of them do (perhaps fewer in open source than in commercial software).
As a side note, this is just one example of a 2500-year-old paradox articulated by the ancient Greek philosopher Zeno, who asked "If I set out from point A to point B and in every minute I travel half of the remaining distance between A and B, when will I arrive at B?" The answer is never, since there are always an infinite number of points between any two points, no matter how close or far apart they are. But if I ask "Point A is one mile from Point B. If I start at A and travel at 2 miles per hour, when will I arrive at B?", the answer is easy - 30 minutes.
Fortunately, the primary use case for version ranges is to answer a question of the second kind: “I use a certain version of Product X; the supplier of X has reported that CVE-2026-12345 is found in all versions of X within a certain range. Can I learn for certain whether or not the version I use falls within that range? The answer is “If the supplier uses a monotonically increasing version numbering scheme, the answer is Yes. If not, the answer is No, unless the supplier has made publicly available the procedure they follow to increment a version number.”
Do most software suppliers use monotonically increasing version numbers? My guess is yes, but if yours doesn’t, I suggest you have a conversation with them. In fact, you should also strongly suggest that they create CVE records that include a version range that follows the version range specification that is part of the CVE schema – rather than just describe the version range in the text of the record, which isn’t machine readable.
And if they’re not reporting vulnerabilities to the CVE program at all? That’s another conversation, which needs to be much more forceful.
Tom Alrich’s Blog, too is a reader-supported publication. You can view new posts for two months after they come out by becoming a free subscriber. You can also access all of my 1300 existing posts dating back to 2013, as well as support my work, by becoming a paid subscriber for $30 for one year (and if you feel so inclined, you can donate more than that and/or become a founding subscriber for $100). Whatever you do, please subscribe.
If you would like to comment on what you have read here, I would love to hear from you. Please comment below or email me at [email protected].