Allow ADP container cpes array without requiring product/version or collectionURL/packageName

[ccoffin]

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:

cve-schema/schema/CVE_Record_Format.json

Lines 95 to 108 in 30f59c7

	"allOf": [
	{
	"anyOf": [
	{"required": ["vendor", "product"]},
	{"required": ["collectionURL", "packageName"]}
	]
	},
	{
	"anyOf": [
	{"required": ["versions"]},
	{"required": ["defaultStatus"]}
	]
	}
	],

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.

[andrewpollock]

I'll repeat what I said over in CVEProject/quality-workgroup#12 (comment) 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]

We are discussing the CPE issue during the PSIRT SIG meeting today, Thursday. This is a really problematic issue. Many of the PSIRTs are in fact CNAs. P

…

On Wed, Jun 5, 2024 at 6:59 PM Andrew Pollock ***@***.***> wrote: I'll repeat what I said over in CVEProject/quality-workgroup#12 (comment) <CVEProject/quality-workgroup#12 (comment)> 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 <https://github.com/MrMegaZone> — Reply to this email directly, view it on GitHub <#321 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOLITHBIGTAFUKCWLUXBV2DZF6J3BAVCNFSM6AAAAABITGSKQWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJRGA4TKNZZHA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[amanion-cisa]

Is the affected array validated upon submission to CVE Services?

A proposal: Allow a set of ADPs to submit affected arrays that only contain the cpes list. The set of ADPs today is just the CISA Vulnrichment ADP.

A workaround: When analyzing a new CVE Record, copy the affected array from the CNA, only add data to the cpes list (do not modify the rest of the affected data copied from the CNA, then publish. cc @esarneso.

[MrMegaZone]

Is the affected array validated upon submission to CVE Services?

Minimally at best. We know, for example, you can submit a version number 'type' (such as semver) with version numbers that aren't of that type. All of the vendor & product names, platforms, package names, etc., are free text fields so there's not really a way to validate those. There are no constraints other than post-hoc rule enforcement if a CNA misbehaves and, say, submits a CVE for another vendor, etc.

A proposal: Allow a set of ADPs to submit affected arrays that only contain the cpes list. The set of ADPs today is just the CISA Vulnrichment ADP.

A workaround: When analyzing a new CVE Record, copy the affected array from the CNA, only add data to the cpes list (do not modify the rest of the affected data copied from the CNA, then publish. cc @esarneso.

As a CNA I would rather provide my own CPEs (once we solve the issue of how to represent them in the schema - hopefully NVD's CPE Match format). If we want to allow someone else, as an ADP, to provide their take (as NVD already does), that's fine - but CNAs need to be able to speak for themselves.

The QWG is aware of the problems today with needing to provide an 'Affected' block to provide anything else, and I believe that's on the slate of issues to be addressed.

[pete2160]

Like MZ, I prefer that a CNA provides their own CPE (and/or purls) as that maps directly. We have had issues with NVD mapping due most to a lack of understanding and knowledge. Even working with Vuln Scanners, we find a great lack of understanding of product listings or composition. I do, as MZ pointed out, believe we need more structure around this [note, I am looking for an aware individual working on the CPE update to come speak to the PSIRT SIG on Thursday morning - inform them early so they adopt easily]. I personally do not believe this is an area for ANY ADP to delve into. Pete

…

On Tue, Aug 27, 2024 at 6:10 PM MegaZone ***@***.***> wrote: Is the affected array validated upon submission to CVE Services? Minimally at best. We know, for example, you can submit a version number 'type' (such as semver) with version numbers that aren't of that type. All of the vendor & product names, platforms, package names, etc., are free text fields so there's not really a way to validate those. There are no constraints other than post-hoc rule enforcement if a CNA misbehaves and, say, submits a CVE for another vendor, etc. A proposal: Allow a set of ADPs to submit affected arrays that only contain the cpes list. The set of ADPs today is just the CISA Vulnrichment ADP. A workaround: When analyzing a new CVE Record, copy the affected array from the CNA, only add data to the cpes list (do not modify the rest of the affected data copied from the CNA, then publish. cc @esarneso <https://github.com/esarneso>. As a CNA I would rather provide my own CPEs (once we solve the issue of how to represent them in the schema - hopefully NVD's CPE Match format). If we want to allow someone else, as an ADP, to provide their take (as NVD already does), that's fine - but CNAs need to be able to speak for themselves. The QWG is aware of the problems today with needing to provide an 'Affected' block to provide anything else, and I believe that's on the slate of issues to be addressed. — Reply to this email directly, view it on GitHub <#321 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOLITHAUQTZ3XHCIYLWJHXLZTT2MZAVCNFSM6AAAAABITGSKQWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJTGY3DGNJWGA> . You are receiving this because you commented.Message ID: ***@***.***>

[MrMegaZone]

I am looking for an aware individual working on the CPE update to come speak to the PSIRT SIG on Thursday morning - inform them early so they adopt easily]. I personally do not believe this is an area for ANY ADP to delve into. Pete

The schema changes haven't been finalized, and probably won't be usable until 5.2 releases, so there won't be anything to adopt in the short term. But we can go over the current discussion and how things are headed.

What time Thursday?

[pete2160]

10:30 AM to 12 Noon. We can cover other questions or subjects so no need to cover all 90 minutes. But they likely will have questions and being able to discuss now about direction, thoughts and potential challenges would be appreciated and a big win.

…

On Tue, Aug 27, 2024 at 6:32 PM MegaZone ***@***.***> wrote: I am looking for an aware individual working on the CPE update to come speak to the PSIRT SIG on Thursday morning - inform them early so they adopt easily]. I personally do not believe this is an area for ANY ADP to delve into. Pete The schema changes haven't been finalized, and probably won't be usable until 5.2 releases, so there won't be anything to adopt in the short term. But we can go over the current discussion and how things are headed. What time Thursday? — Reply to this email directly, view it on GitHub <#321 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOLITHGOXCUAPRFXJ6FQZRDZTT5A7AVCNFSM6AAAAABITGSKQWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJTGY4DQNJRGM> . You are receiving this because you commented.Message ID: ***@***.***>