One of the best reasons to move to purl: version ranges

The OWASP SBOM Forum wants to see purl become the primary software identifier for databases based on CVE. This includes the National Vulnerability Database (NVD), but also any other database that uses CVE as the vulnerability identifier. One big driver for this is the fact that the current serious problems with the NVD have essentially made completely automated vulnerability management impossible, unless the user’s vulnerability management tool looks up vulnerabilities in an open source vulnerability database like OSV or OSS Index.

Why are those two databases doing so well, while the NVD is almost on life support? Because OSV and OSS Index (as well as almost any other vulnerability database that focuses on open source software products) are based on the purl software identifier, while the NVD, and databases based on it, utilize only the CPE identifier (OSV has its own software identifier, but supports purl as an optional identifier). NVD staff members used to add a CPE identifier to every CVE report; however, starting on February 12, the NVD drastically reduced the number of CVE reports that it “enriches” with CPE names. There is currently a backlog of above 18,000 “unenriched” CVE reports, meaning that a user searching for recent vulnerabilities in a software product they use is unlikely to learn about most CVEs that have been identified since February.

Purl (which stands for “package URL”) offers a number of advantages over CPE. Some of them are described in this post, as well as in the OWASP SBOM Forum’s 2022 white paper titled “A proposal to operationalize vulnerability management”. However, there’s one capability that’s in principle offered by purl (and not CPE), but which is not in wide use now – it’s the capability to specify a version range. It has yet to be implemented in purl, even though it was developed by the purl team.

Why are version ranges so important in vulnerability management? It is because a software vulnerability seldom appears in one version of a product, then disappears in the next version. Instead, it usually remains in the product for multiple versions (or even multiple years), until it is finally patched or removed for other reasons. This means that vulnerability management is likely to work much better if it can be based on version ranges, not individual versions.

Today, CVE reports often state that a vulnerability applies to a range of versions in a software product, not just to one version or multiple individual versions. However, that assertion is strictly in text; there is no way to specify a version range in a machine readable format, since CPE (the only software identifier currently available for CVE reports) does not support version ranges. This means that, if a user performs an automated search on the NVD, they will not learn that a CVE affects a range of versions, unless they also read the text of the CVE report.

Ideally, a software identifier should be able to specify a version range in a machine-readable format that states, for example, “Versions 3.4 through 5.6 of product XYZ are affected by CVE-2024-12345. Other versions are not affected.” A user tool that parses that identifier will identify every version that falls in that range and mark each one as affected by the vulnerability. That is, the user tool will understand the above statement to mean, “Versions 3.4, 3.5, 3.6…5.5, and 5.6 are affected by CVE-2024-12345.”

Currently, if a user notices a version range in a CVE report that applies to a product they utilize, and they want to make sure every version within the range is noted to be affected in their vulnerability tracking system, they will have to annotate each version manually. Since a multiyear version range could easily contain hundreds of versions (including minor versions, patch versions, separate builds, etc.), this could turn into a very time-consuming process.

Recognizing this problem, a few years ago, the purl community developed a “version range specifier” called “vers”. It provides a simple specification for version ranges. For example, a range that includes version 1.2.3, as well as versions greater than or equal to version 2.0.0 and less than version 5.0.0, would be specified as “1.2.3|>=2.0.0|<5.0.0”.

The simplicity of vers comes at a cost: It only applies to certain versioning schemes in which the elements of a range can be specified using simple arithmetic. For example, if I have version 3.2.5 of the product to which the above range applies, I can easily determine that my version falls within that range, whereas version 5.4.6 falls outside of the range. On the other hand, a versioning scheme that uses letters is not supported by vers, since there is no way to be certain whether “version 4.6B” falls within the above range or not. The vers specification lists versioning schemes that are supported. However, it is possible that a scheme that isn’t on the list, but in which versions can be compared using just addition, subtraction, and greater than/less than operators would work fine with vers.

One of the main reasons why CVE.org should move to purl as the primary software identifier (from the current CPE) in the future is that when vers is integrated into purl (which I admit won’t be an easy lift), a purl in the database could identify an entire version range, not just a single version of the product. When this happens, it will constitute a huge improvement in automated vulnerability management.

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 and its Vulnerability Database/purl Working Group. These groups work to understand and address issues like what’s discussed in this post; please email me to learn more about what we do or to join us. You can also support our work through easy directed donations to OWASP, a 501(c)(3) nonprofit, which are passed through to the SBOM Forum. Please email me to discuss that.

My book "Introduction to SBOM and VEX" is available in paperback and Kindle versions! For background on the book and the link to order it, see this post.