Support PURL as identifier

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

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

@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?

Hi, I just looked at the CVE Record format here:
https://github.com/CVEProject/cve-schema/blob/main/schema/CVE_Record_Format.json

... and there is STILL no reference to pURLs. Why isn't that in there yet? I thought purls were in the interchange format, but they appear to still be lacking.

Discussion has kicked off again that the current solution is insufficent.

There is a pending proposal #397 addressing this. It relies on #391 to first make the existing cpeApplicability structure generic.

#397 was superseded by #407, which is now before the CVE Board. If approved it would be part of version 5.2.0 of the Record Format.

Excellent, thanks a lot fot the issue and thanks for having pointed it to me from

❔ About endoflife.date identifiers and opencve vendor endoflife-date/endoflife.date#8311 (comment)

Added support for PURL identifiers in 5.2.0 (https://github.com/CVEProject/cve-schema/releases/tag/v5.2.0)

Navigation Menu

Repository navigation

Support PURL as identifier #173

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Support PURL as identifier #173

Description

Activity

kurtseifried commented on Sep 13, 2022

redlinejoes commented on Sep 14, 2022

pombredanne commented on Oct 1, 2022

chandanbn commented on Oct 1, 2022

juliancoccia commented on Jan 12, 2023

Pizza-Ria commented on Jan 24, 2023

hibbardc commented on Jan 24, 2023

chandanbn commented on Mar 23, 2023

mehradn7 commented on Jan 5, 2024

Pizza-Ria commented on May 2, 2024

david-a-wheeler commented on Oct 24, 2024

jayjacobs commented on Jan 17, 2025

alilleybrinker commented on Apr 9, 2025

alilleybrinker commented on Aug 15, 2025

adriens commented on Sep 2, 2025

ccoffin commented on Nov 12, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions