CVE Validation Library - versions - status and defaultStatus

[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:

Each versions array item is required to contain a status property that defines whether the specified version or version range is affected, unaffected, or unknown. Related to this, a defaultStatus property exists at the product definition that provides the default status of affected, unaffected, or unknown for all versions not otherwise listed in the versions specific within the versions array. For example, you can specify a defaultStatus equal to 'unaffected,' and then define a versions array item that includes a range of versions with the status value equal to 'affected.' In that case, anything that falls outside of the versions array range would be considered unaffected. If the defaultStatus property is not specified, the default value is 'unknown.'

Past efforts to check CVE records for common issues has found that there were many cases where CNAs used a defaultStatus equal to 'affected' while also defining one or more versions array items with a status of 'affected.' It was found that what was originally intended was for the defaultStatus to be 'unaffected' in those cases. There may be some legitimate cases for both defaultStatus and status to be affected, but they are likely very rare. We will need to discuss and determine if these cases should be a Fail or a Warn for this reason.

Schema Location(s):

https://github.com/CVEProject/cve-schema/blob/main/schema/CVE_Record_Format.json#L282
https://github.com/CVEProject/cve-schema/blob/main/schema/CVE_Record_Format.json#L315

Question(s):

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

Examples:

• Fail (or Warn) when the defaultStatus equals 'affected' and there are no versions/status items equal to 'unaffected' or 'unknown.' (Validation Library only)
• Fail (or Warn) when the defaultStatus equals 'unaffected' and there are no versions/status items equal to 'affected' or 'unknown.' (Validation Library only)
• Fail (or Warn) when the defaultStatus equals 'unknown' and there are no versions/status items equal to 'affected' or 'unaffected.' (Validation Library only)
• Fail (or Warn) when the defaultStatus is not specified (i.e., 'unknown') and there are no versions/status items equal to 'affected' or 'unaffected.' (Validation Library only)

[darakian]

Late followup and I can pick some nits with your examples, but I think I read them as all pointing at making ambiguous statements less common (or impossible if/when the warn becomes a fail). If that is not a fair read let me know, but if so then to your two questions; yes and yes.

I think there may be valid cases (at least in practice) where the first two examples are valid. eg.

1. It may be the case that some vuln is discovered in a product which will never see an update. => every version is affected => defaultStatus: affected w/ no subtraction to the cover.
2. It may be the case that an organization wants to express their unaffected-ness for a given vulnerability and hence defaultStatus: unaffected.

Case 2 is not a good use of the system, but unless/until the ADP system becomes generally available it may be the best of a set of bad practical options. Longer conversation there, but these two cases may not merit warnings/failures.

Examples 3 is a CVE in a state of existential crisis. If we assume the purpose of a CVE is to express that there exists and problem in one or more things and the canonical set of things is null/none/nothing then the CVE fails to have a reason to exist. This is certainly something a validation library could catch with relative ease.

Example 4 is the same as example 3 and is why defaultStatus should either be a required parameter or the value unknown should not be permitted. Either change to the schema would not change what can be encoded (both cases are identical in meaning), but by picking one encoding the task of reading a CVE (every 3 minutes or whatever) becomes slightly easier.

---

Going further though, a validation library could look for and warn/fail on any sort of overlap. Take a case where defaultStatus is affected for some product Foo. There is some set of products (f1, f2, f3...) which when taken together make up the complete set of Foo products. It would be confusing to a reader if some element in that set, say f3, fell into multiple, conflicting assertions. eg.
A set of unaffected products might be listed as >= f3 at the same time as the affected products are listed as <= f3.
What's a reader supposed to do with that?

If a CVE is published with a conflicting set of assertions and some org is unlucky enough to be using the ambiguous version then their response to the CVE will be delayed as they need to independently resolve that ambiguity. Maybe that costs them 3 minutes, maybe that costs them 3 weeks. Depends on the details, but it's a cost we can design out.

I will say, that in order for overlapping ranges to be detectable we do need to revisit the concept of what a versionType is. Ordering is a requirement for range construction and will depend on the definition on any given versionType.

[ccoffin]

Discussed in 9/10/2026 QWG Meeting:

• It might make sense to have defaultStatus as affected and also specify a version or version range that is affected, though this is still not clear. Even though it is redundant, there could be cases where a CNA just wants to be clear on which versions are affected.
• It may not make sense to have a defaultStatus of unaffected and no versions array specified. The members feel that this should not be allowed in the CNA container. However, this would be a valid scenario within an ADP container where a supplier CNA is stating that they are NOT affected.
• It may not make sense to have a defaultStatus of unknown and no versions array specified. One member feels that this doesn't provide enough actionable data to make the record useful. The same situation would exist if a version array only specified unknown for status in every case.

[darakian]

Even though it is redundant, there could be cases where a CNA just wants to be clear on which versions are affected.

Linking in
#425
as I believe it's relevant related topic.

It is my opinion that redundant data is at best of neutral value and would more commonly be of negative value to the reader of a CVE. If someone believes that there is a positive value case to be made then it would be good to document the reader persona for which redundant data is a positive in the Record Format Audience discussion. If no persona can be documented the publisher case might need to be seen as counter productive.