andrewpollock
commented
3 months ago I'll repeat what I said over in https://github.com/CVEProject/quality-workgroup/issues/12#issuecomment-2151089553 here:
My knowledge about CPEs is largely informed by https://en.wikipedia.org/wiki/Common_Platform_Enumeration because I find it easier to consume than anything else...
Separating vulnerable version identification from vulnerable product identification for a moment, in the light of CPEs (I believe) not yet being widely present on CVE List CVE records, I'd been wondering if the vendor and product components of a CPE string could be derived from the vendor and product fields in the affected object?
That would require tightening up the definition of what is expected to appear in vendor and product. My thought here was to say that it SHOULD correspond with what is defined in the NVD's CPE Dictionary when it exists, and where possible, vendor CNAs SHOULD correspond with the NVD to obtain a CPE Dictionary entry as part of their product's lifecycle (i.e. before a product's first CVE is required).
It is my understanding that while there is a perception that there's a bootstrapping/chicken-and-egg problem with CPEs (until a product has its first CVE, it doesn't have a defined CPE) this is something of a myth, and it's possible to proactively request CPEs (in bulk even) from the NVD. This would mean that in line with the Secretariat's request for (vendor) CNAs to start adding CPEs to their CVEs, they should also be requested to obtain CPE Dictionary entries for products they own that have not yet had CVEs reported for.
/cc @MrMegaZone
pete2160
amanion-cisa
MrMegaZone
One of the identified use cases for becoming an ADP is to provide enriched vulnerability information to existing CVE records that were originally created by other CNAs. CPEs are a common use case for enriched vulnerability information as they can be provided by an ADP on top of the product and version information that was previously provided by the original CNA. With CPEs, the CVE record could be more easily automated if it includes machine-readable affected product information included in the CPE(s). To add CPE(s), they must be included within the cpes array. The cpes array is a child element of affected.
The current CVE schema has the following requirements block for affected:
https://github.com/CVEProject/cve-schema/blob/30f59c7de92fbc77bddade302601cb500c66f718/schema/CVE_Record_Format.json#L95-L108
This enforces the requirement that all CVE records must have an affected product and version, or collectionURL and packageName. affected is NOT a required element for an ADP, but if affected is included as part of an ADP record then it must meet the requirements above. This makes sense for CNAs who are defining the original CVE record, but maybe not so much for ADPs. An ADP may wish to just introduce one or more CPEs to a CVE record where the original vendor CNA has already provided text product and version info (but NOT CPEs). The cpes array for providing the CPE strings exists under affected, and because of this, the ADP is also required to enter product and version, or collectionURL and packageName information. This not only creates additional burden on the ADP to provide this information, but could also result in conflicting or inaccurate product and version information when compared with the original CNA container information.
The current schema already includes separate definitions for CNA and ADP containers. If others agree that ADPs should be allowed to provide CPEs without also having to define additional product and version information, we could create a new definition for ADP affected information that allows inclusion of the cpes array and does not require additional product and version information.