Allow ADP container cpes array without requiring product/version or collectionURL/packageName #321
Comments
|
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 |
|
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: ***@***.***>
|
|
Is the A proposal: Allow a set of ADPs to submit A workaround: When analyzing a new CVE Record, copy the |
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.
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. |
|
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:
***@***.***>
|
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? |
|
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:
***@***.***>
|
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
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.
The text was updated successfully, but these errors were encountered: