Do Not Allow N/A as Product or Vendor

[jgamblin]

Listening to Andrew Pollock at Vulncon say that nearly 20% of products and vendors are listed as n/a, this update to the schema stops that from being allowed.

[jgamblin]

There are 2,595 CVEs published in the last 365 days that do not meet the minimal CVE publishing standards and should have not been published. This PR will no longer allow these CVEs to bypass the publishing rules by using n/a.

combined_na_product_vendor.csv

[attritionorg]

Big, big upvote for this! Hold CNAs accountable.

[zmanion]

I'm in favor of better quality and standards. For those records with "n/a" do they provide vendor/product/version information in the prose description? One could argue that the requirement is met through the description or the affected JSON.

At a glance, yes, the "n/a" records do have vendor/product/version information in the descriptions. So preventing "n/a" would probably involve a rule change (e.g., MUST use affected orcpeApplicability or other appropriate JSON).

I believe these are the core requirements from the current rules:

5.1.3 MUST identify at least one affected Product using information such as Supplier and Product names, versions, and dates.

5.1.4 MUST identify at least one Product as “affected” or “unknown” (with the possibility of being affected).

5.1.7 MUST identify the type of Vulnerability. The CVE record SHOULD use CWE...

5.1.9 MUST contain a prose description (see 5.2).

5.1.10 MUST contain at least one public reference (see 5.3).

[attritionorg]

There are CVEs published that consistently lack a vendor or product, and many that do not have versions.

Further, rule 5.1.10 has been violated more than once in the past year.

[jgamblin]

Even if the rule permits the data to be included in the description, there remains a concern regarding data quality that needs to be addressed. If these fields are not mandatory, they should not be marked as required. Allowing "N/A" complicates overall data handling.