Require “cweId” Field

[patrickmgarrity]

I shared a data visualization on LinkedIn regarding CWE data, highlighting gaps in coverage by CNAs (Common Vulnerabilities and Exposures Numbering Authorities) in the context of CVEs (Common Vulnerabilities and Exposures). During discussions about the post, an observation was made regarding the presence of blank CWE information in the National Vulnerability Database (NVD), which seemed unusual. (Highlighted in the darker RED on the data visualization)

Upon analysis, I discovered instances where CVEs were listed in the NVD without any associated CWE information. Specifically, my analysis identified 825 CVEs. This has implications for all consumers, not just the NVD use case.

Following a discussion with Jay Jacobs regarding these observations, we looked into the CVE records within the CVEProject/cvelist5 Github Repository. Upon review, we found that the CWE data for these CVEs was incomplete compared to other records where the information was present. While the CWE data seemed to exist within the JSON blobs for the sampled CVEs, it was incomplete, leading to the omission of CWE information in the NVD. Additionally, I noticed that most of these CVEs were published in 2023 and all were in a modified status.

While I haven't completed the CNA process to issue a CVE myself, I suspect this issue may be attributed to an input validation problem mismatching required attributes with NVD’s requirements. At a quick glance it appears the CWE requirements submitted by the CNAs in the example below meet the JSON required fields.

So my gut is that NVD requires the “cweId” which is missing from all the CVE examples provided below in order for CWEs to be processed and displayed in NVD. From a consumption standpoint an ID field and not an open description field should be required. This is the equivalent of providing consumers without a CVE ID and only a CVE description to work off of.

Example CVEs:
CVE-2022-2933: https://nvd.nist.gov/vuln/detail/CVE-2022-2933
CVE-2023-2352: https://nvd.nist.gov/vuln/detail/CVE-2023-2352
CVE-2020-2307: https://nvd.nist.gov/vuln/detail/CVE-2020-2307
CVE-2023-0441: https://nvd.nist.gov/vuln/detail/CVE-2023-0441
CVE-2022-45121: https://nvd.nist.gov/vuln/detail/CVE-2022-45121

[jayjacobs]

I think what Patrick is highlighting is that those sample records have the CWE ID in the "description" field and not in the intended "cweId" field. In fact there are 22 CNAs across 4,381 CVEs (as of this afternoon) that have put the CWE ID into the description and not the expected "cweId" field.
Note that some CVE records do not leverage the "type" field for the problemType, and the "type" field does not appear to be strictly enforced.

so this proposal is actually two distinct proposals:

• "clean up" the data quality enforcements around this section. enforce that a proper CWE string be included in the cweId field, validate the type to be either "CWE" or "other" (or whatver).
• If allowed (and it seriously should be for examples like this), we should do a data clean up and complete the cweId field for those CVEs that clearly have a CWE ID in the description but not the cweId field.

Additionally, there are 173,373 instances of the "problemType" section, where "type" = "text" and that's the only data in the entire section. That's another candidate for cleanup.

More additionally, there are 16 unique values under "type", which I think is generally meant for "CWE" or "other" right now (microsoft has some with "impact" that may be valid as well, but they are old)

Oh, and there are 15 CVEs from the CNA "odoo" that have a "cweid" field instead of "cweId" field (e.g. CVE-2021-23166), those should be modified as well.

[patrickmgarrity]

Yeah that sounds about right. I would personally break this out like this...

1. Require the CWE ID for all Problem Types
2. Cleanup the data quality
3. Autogenerate the description from the CWEID field - Maybe this could happen at the tool submission level.

[ScottMooreIBM]

Not sure if this helps, but all of those examples above had their CWE removed on 11/06/2023.

[andrewpollock]

I'm very much in favour of making more things mandatory for them to be successfully accepted and schema-valid. This is essentially part of what I'd proposed in #384