Repository navigation
Underwhelmed by the misuse of versionType and version to support purl #320
Description
Like many, I was very excited to explore the 5.1 release with purported support for package url. But it turned out to be just a couple of string attributes versionType and version, that can be used to populate with any values without any validations. In fact, versionType could be purl, package url, PURL, anything. While purl specification has no limit on the length, version attribute has a max length of 1024, which would limit the number of qualifiers (Example repository_url=full url) that can be used.
I think if we are serious about replacing CPE with purl, it deserves a first party attribute with correct validation rules. I would appreciate if you revisit the purl support for 5.2 release.
Activity
chandanbn commentedon May 30, 2024
Is it possible to check if something is a valid PURL using JSON-schema rules?
prabhu commentedon May 31, 2024
Thank you for the prompt response. If the attribute is called
purlthat alone is usually sufficient for the downstream tools to use appropriate validation.Below is how CycloneDX handles the various identifiers.
https://github.com/CycloneDX/specification/blob/master/schema/bom-1.6.schema.json#L972-L999
CVE spec could support an array of purls, omnibor, and swhid etc similar to cpes.
mprpic commentedon Jun 3, 2024
Fwiw, the CSAF spec has a basic regex validator for purls:
alilleybrinker commentedon Aug 15, 2025
There is an RFD proposal for more direct support for PURLs, currently under consideration by the CVE Board. If approved, it would be merged with the 5.2.0 release, not yet scheduled.
See #407