Do Not Allow N/A as Product or Vendor #399
Conversation
Does not allow n/a as the vendor or the product.
Fix pattern using this information. https://stackoverflow.com/questions/49102792/regex-find-n-a-word
|
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. |
|
Big, big upvote for this! Hold CNAs accountable. |
|
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 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 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). |
|
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. |
|
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. |
| @@ -125,13 +125,15 @@ | |||
| "type": "string", | |||
| "description": "Name of the organization, project, community, individual, or user that created or maintains this product or hosted service. Can be 'N/A' if none of those apply. When collectionURL and packageName are used, this field may optionally represent the user or account within the package collection associated with the package.", | |||
| "minLength": 1, | |||
| "maxLength": 512 | |||
| "maxLength": 512, | |||
| "pattern": "^(?!(n\/a)$).*" | |||
There was a problem hiding this comment.
I think this regular expression isn't quite right (see here, it fails to match n/a). I believe it should be ^\s*[nN]\/[aA]\s*$ (see here, it matches all intended test cases).
There was a problem hiding this comment.
Aha, I was wrong. I forgot the regex needs to be negated.
Here is a corrected one: ^(?!(\s*[nN]\/[aA])\s*$).* (with explanation)
| }, | ||
| "product": { | ||
| "type": "string", | ||
| "description": "Name of the affected product.", | ||
| "minLength": 1, | ||
| "maxLength": 2048 | ||
| "maxLength": 2048, | ||
| "pattern": "^(?!(n\/a)$).*" |
There was a problem hiding this comment.
Same regular expression comment as my other one.
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.