Seconded. Had I known that Purl would take off I would have added it to the original CVE JSON specification I wrote.

Thirded. Thanks, Steve, for your excellent writeup at OWASP New Recommendations to Improve The NVD.
I'm excited about the feature to query the NVD directly using the native package coordinates or purl of the software and receive accurate vulnerability information.

As the original purl author I support this of course! and I am available to help as needed.

The schema currently does indeed support PURLs. The work pending in 5.1 is to allow versionType field for non-range versions (so one can say versionType="PURL"

What may be useful:

• Code to auto generate PURLs based on individual fields in the affected structure
• regex to validate PURLs.

You can currently (CVE JSON v5.0) supply them in the list of versions eg.,

  "affected": [
    {
      "collectionURL": "https://rubygems.org",
      "packageName": "ruby-advisory-db-check",
      "versions": [
        {
          "status": "affected",
          "version": "pkg:gem/ruby-advisory-db-check@0.12.4"
        },
        {
          "status": "affected",
          "version": "0.12.4"
        }
      ],
      "defaultStatus": "unaffected"
    }
  ],

For the record, we have just released our entire CPE <-> PURL dataset here:

https://github.com/scanoss/purl2cpe

@chandanbn It sounds like your suggestion to address purls is simply to add an extra version to the "affected" list pending the release of the CVE JSON 5.1. Is there any work in process on your other ideas of

• Code to auto generate PURLs based on individual fields in the affected structure
• Regex to validate PURLs

Also, any idea when CVE JSON 5.1 will be released?

impatiently awaiting CVE 5.1 for this. This will go a long way to solve the industry package Naming Problem.

will be addressed via #201

Hello, is there a way to track the progress of NVD adopting CVE JSON 5.1 and supporting queries with pURL ?
Thanks!

Any update on this?