A Proof of Concept for including purl identifiers in CVE Records #161
Description
_Note 4/16: What is below was written before this week's on-again-off-again activity with the CVE Program and MITRE. Everything here is still quite relevant.
The CVE Program has started preparing to make purl an alternative software identifier to CPE in CVE Records. The CVE Quality Working Group (QWG) is now actively working on modifications to the CVE Record Format (aka ‘CVE Schema’) to accommodate purl. Since CPE will not go away, in the future CNAs will be able to designate affected products in a CVE Record using either identifier (and possibly the OmniBOR identifier as well).
While the QWG had been considering new identifiers for more than a year, their task was lent more urgency by the fact that in 2024, the NVD fell far behind in its job of adding CPE names to indicate vulnerable products in new CVE Records. In fact, the NVD added CPEs to fewer than half the new CVE Records created in 2024.
So far this year, the NVD’s “enrichment” rate has fallen even further, meaning their backlog of CVE Records without CPE names continues to grow rapidly. After missing at least two promised dates to eliminate the backlog in 2024, the NVD has stopped even estimating when they will catch up with this work.
The reason why a lack of CPE names in CVE Records creates a problem is that, without a CPE name, a CVE Record is invisible to automated vulnerability searches (for example, when a user enters a product name in the NVD’s search bar or uses one of the APIs).
This means that a user searching for new vulnerabilities identified in a software product won’t learn about any new CVE Record that doesn’t include a CPE name, even if the text of the record (which can’t be searched in a completely automated fashion) indicates the product is vulnerable.
Even worse, when this happens, the user will simply receive the message, “There are 0 matching records.” This is the same message they will receive if there are in fact zero vulnerabilities identified in the product. Of course, most NVD users, after seeing this message, will probably believe their product has no vulnerabilities – rather than that it likely does have vulnerabilities, but they can’t be identified through automated searches.
For this and other reasons, the QWG is now discussing changes to the CVE Schema to allow purl (and perhaps other identifiers in the future) to be used as an identifier for vulnerable products in CVE Records. While it is important to change the Schema, there are six other steps that need to be taken as well. These should be taken as part of a Proof of Concept, in which various participants in the CVE ecosystem utilize test CVE Records that are based on the proposed new Schema.
- Identify vulnerability databases that are able – and willing – to ingest CVE Records that contain purls, and make it possible for automated searches based on purl to discover those records. Today, there is probably no vulnerability database that can do this without any modification, although some databases will require fewer modifications than others. For example, Sonatype’s OSS Index uses CVE as the vulnerability identifier and purl as the software identifier. However, since there are no CVE Records that include purls now, the database is currently using other means to determine applicability of new CVEs. There are also databases like the NVD, VulnDB and VulDB that are based on CPE and CVE. These databases can ingest CVE Records today, but they will need to be modified to accept purls in CVE records.
- Identify scanning tool vendors that are willing and able to ingest test CVE Records containing a purl identifier, to determine whether the test CVE Records meet their needs, or whether there should be further changes to the format.
- Interview medium- to large-sized end user organizations to learn about their requirements for vulnerability data. While these organizations are unlikely to have fixed opinions about the CVE Record Format, they can certainly describe their need for timeliness, accuracy, completeness, and applicability of vulnerability data. Chris Coffin, co-leader of the QWG, is especially concerned about getting end users involved in the process of extending the CVE Schema to include use of purl identifiers.
- Interview CNAs about how they might use purl, and whether they think the test CVE Record Format is adequate for their needs. Since today purl is only used to identify open source software distributed in package managers and similar repositories, the CNAs most likely to be interested are those that create CVE Records for vulnerabilities that affect OSS. However, all CNAs will be welcome to participate in the PoC.
- The fifth and final step is to execute an end-to-end Proof of Concept based on the test revisions to the CVE Schema. The PoC will consist of the following steps:
- a. CNAs will create test CVE Records in the new format, including purl(s) for vulnerable product(s) described in the text of the record.
b. If possible, those records will be submitted to the test CVE.org database, from where they will be downloaded by vulnerability databases. If this isn’t possible, the records will be submitted directly to the vulnerability databases.
c. The vulnerability databases will ingest the test CVE Records, then ask users to conduct searches using purls that were included in one or more test records.
d. If a search using a particular purl results in the user being shown every test CVE Record that includes the purl, that test will be considered a success.
e. If any test purl search does not reveal one or more test CVE Records that include that purl, the test will be considered a failure. The cause of the failure will be investigated and documented for public viewing.
f. Similarly, scanning tool vendors that wish to participate in this Proof of Concept will develop their own tests using the CVE Records that include purls. If possible, they will publish the results of their tests.
g. The final step of the PoC will be to prepare a document that describes (i) vulnerability reporting needs identified by PoC participants, (ii) whether and how those needs were addressed in the PoC, and (iii) what lessons were learned from the PoC – especially regarding changes needed in the CVE Schema to accommodate use of purl identifiers in the overall CVE ecosystem. -
After the PoC has been completed, the leaders of the project will develop training on use of purl for members of the CVE community. This will include presenting and recording webinars, both for "newbie" users and as technical training for CNAs, vulnerability database operators and scanning tool vendors.