CVE Validation Library - problemTypes - cweId

[ccoffin]

Purpose:

This will be one of multiple discussions to query the QWG and others on how best to use the upcoming CVE Services Validation Library for performing additional or more accurate CVE Record Format JSON schema validation during record ingest. The Validation Library will allow the CVE Program to perform programmatic validations beyond what the current JSON schema validation can provide. A simple example might be where we want to validate that a provided CWE ID actually exists by referencing the current CWE List. This is not possible using JSON schema validation, but would be possible with the Validation Library.

Discussion:

The current problemTypes array requires a description and lang property for each item provided, and includes an optional cweId property for providing a CWE ID. If the record author is providing a CWE mapping, this means that they will provide a CWE name/description (required currently) along with the cweId value. A pattern match is used within the current schema to make sure that the cweId value uses the correct CWE ID syntax (i.e., "^CWE-[1-9][0-9]*$"). There is no validation done on the description property value.

Schema Location(s):

https://github.com/CVEProject/cve-schema/blob/main/schema/CVE_Record_Format.json#L887
https://github.com/CVEProject/cve-schema/blob/main/schema/CVE_Record_Format.json#L910

Question(s):

• Can we use the Validation Library to improve the quality and accuracy of the data provided by CNAs within the problemTypes array?
• Can the proposed validation be implemented using only the Validation library, or could it also be accomplished using the JSON schema?

Examples:

• Fail validation when the provided CWE ID does not exist within the current CWE List. (Validation Library only)
• Fail if the provided description value (ID and name) does not match the provided cweId value (e.g., The description lists a different CWE name than the CWE ID specified in the cweId property). (Validation Library only)
• Warn record author when the CWE ID vulnerability mapping value is "discouraged" in the CWE List. (Validation Library only)
• Fail when the CWE ID vulnerability mapping value is "prohibited" in the CWE List (e.g., trying to map to a CWE category). (Validation Library only)

[boblord]

Validating the CWE field should be a priority. We need to make a few decisions first.

• Is it legal to have more than one CWE value in the field?
• If we allow more than one, what does the field look like with multiple values?
• Can we update the CVE Program Rules 5.1.7 to " CVE Record MUST use the Common Weakness Enumeration (CWE™) to classify the type or cause of the Vulnerability."?

Suggested warnings:

• Discouraged CWE values
• No CWE field
• Anything other than a value of "CWE-*" which would catch those submissions that also contain the English text definition.

[ccoffin]

• Is it legal to have more than one CWE value in the field?
• If we allow more than one, what does the field look like with multiple values?

problemTypes/descriptions is an array and can include multiple items, i.e., multiple CWE mappings. This appears to be fairly common and i have included a couple of examples below.

https://cveawg.mitre.org/api/cve/CVE-2026-0204
https://cveawg.mitre.org/api/cve/CVE-2026-1049

The next question would be, how do these CWEs relate to each other within this record? Did the author intend for both CWEs to be mapped? Were they unsure which CWE mapping it should be and included multiple?

[zmiele]

The next question would be, how do these CWEs relate to each other within this record? Did the author intend for both CWEs to be mapped? Were they unsure which CWE mapping it should be and included multiple?

I don't think these are blocking issues or need to be solved before being able to benefit from the consistency of validating the CWE field.

I know there was some discussion in today's meeting about representing relationships, but we might be able to sidestep some of the harder questions raised by considering adding support for CWE Chains and Composites. This would at least give a way for clear representation of some relationships between IDs that we don't need to try and come up with on our own.

However, I really don't think that's necessary and records would immediately benefit from the initial few validation examples.