Closed fortresslabs closed 1 year ago
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:
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:
@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
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?
Please add PURL as a unique identifier to the schema as there is currently no way to identify software component vulnerabilities without a PURL lookup. https://github.com/package-url/purl-spec