Open ElectricNroff opened 1 month ago
This looks like it's blocked, or possibly just influenced by, this upstream issue in CPE-land: https://github.com/CVEProject/cve-schema/issues/321 . More cycles shall be spent on this to figure out how to best solve this issue for everyone, not just ADPs or CVEs.
An option is to document the behavior (in the README), at least until a more lasting solution or decision is in place.
Still blocked by https://github.com/CVEProject/cve-schema/issues/321 .
The CISAADP container has the affected.vendor, affected.product, and affected.versions fields in at least several hundred CVE Records, but nothing in https://github.com/cisagov/vulnrichment/blob/034bc878aecbbc99cc211b0ceafa3fc53ddb5459/README.md mentions that this should be occurring. Also, in at least a few cases, the vendor/product/versions data is inaccurate relative to both the CNA container and the references. For example, here is an off-by-one error (for the version 24.0.1) caused by erroneous replacement of lessThanOrEqual with lessThan: https://github.com/cisagov/vulnrichment/blob/4395c94d8d03a63ab67976dd9c820fb3c6152169/2024/20xxx/CVE-2024-20794.json#L18-L25 https://github.com/cisagov/vulnrichment/blob/4395c94d8d03a63ab67976dd9c820fb3c6152169/2024/20xxx/CVE-2024-20794.json#L139-L148 If enriching vendor/product/versions is currently less important than CVSS/CWE/CPE, then one might consider an alternative design of the affected property:
in which collectionURL/packageName/defaultStatus would be the same in all CISAADP containers that provide an affected property. Then, https://github.com/cisagov/vulnrichment/blob/develop/NULL-collection.md could offer a brief explanation that it is not really a collection, that CISA is not enriching vendor/product/versions in the initial production rollout, but (because of the current design of the CVE Record Format) JSON validation requires perfunctory non-blank values for collectionURL/packageName/defaultStatus.