Validate problemTypes (CWE-like) beyond what the JSON schema can do

[kernelsmith]

Summary

I hear people stating that a CWE is a requirement to publish a CVE. It is mentioned in the 4.1 Rules (emphasis is mine):

5.1.7 *MUST identify the type of Vulnerability*. The CVE record *SHOULD* use the Common
Weakness Enumeration (CWE) to classify the type or cause of the Vulnerability. A CVE Record
*MAY contain multiple types* or causes of the Vulnerability.

Another ref from meeting notes

Based on this description and the limitations of JSON Schema definitions, the schema can only require "problemTypes" as an array of objects of length 1 or more. Those objects are required to have a "lang" and a "description", they CAN have a cweId, but it's not required. The description must have a length of at least 1 and up to 4096. Therefore, someone can satisfy this requirement with

        "problemTypes": [
          {
            "descriptions": [
              {
                "lang": "en",
                "description": "C",
              }
            ]
          }
        ],

We should either 1) validate problemType beyond the schema (like content validation) or 2) just require a real CWE that matches an existing CWE with a type of either Class (discouraged), Base (Preferred), or Variant (Preferred). CWE Type of "Pillar" should not be allowed. I guess there is an option 3) which is to increase the min required length of the problemType string, but how long is long enough? What's to stop them from putting in "abcdef"? You could argue that a min length of 6 is the most you could require. That's enough to put "CWE-20" (I don't know if any CWE's are a single digit, like "CWE-9", if so, the min length would have to be 5. Obviously this does nothing to prevent the use of "abcdef" or "CWE-000", so I don't know that option 3 is really "worth the rub".

Motivation

Real CWE data

Describe alternatives you've considered

Mentioned as option 1 and 2 above

Additional context

This is a common misconception, even among CVE folks at MITRE and elsewhere.