Proposal: Minimal Validation for all 6.0.0 Schema Fields

[jgamblin]

I would like to propose a discussion about implementing minimal validation for all populated fields within the 6.0.0 CVE JSON schema.

Currently, while some fields have well-defined requirements, others lack basic checks for data quality. This proposal is not about making optional fields mandatory, but rather ensuring that if a field is populated with data, that data is substantive and useful to consumers of the CVE List. This applies not only to strings but also to arrays, numbers, and other data types.

Why this is important:

Improved Data Quality: This approach helps prevent the submission of fields with meaningless content, such as empty arrays, zero values for counts, or single-character strings. By setting a minimum standard for all data types, we can ensure the information is always useful.

Enhanced Reliability: Enforcing minimal validation across all fields makes the data more reliable and easier to process for automated systems and tools. It reduces the need to handle a wide range of edge cases and invalid data formats.

Consistency Across the Board: Applying this principle universally creates a more consistent and robust schema. It ensures that the integrity of the data is maintained, regardless of the field type.

Proposed Action:

I suggest we review all fields in the schema and establish a set of minimal validation rules for them. These rules would only apply if a field is present in the record. For example:

Strings: Require a minLength greater than zero (e.g., minLength: 1) to prevent empty strings.

Arrays: Require a minItems greater than zero (e.g., minItems: 1) to prevent empty arrays.

Numbers/Integers: For fields that represent a count or a measure, require a minimum value greater than zero (e.g., minimum: 1) to ensure the value is meaningful.

This change would be a significant step toward improving the overall quality and usability of the CVE data. I look forward to the community's thoughts on this proposal.

[andrewpollock]

I'd like the advocate for use-case based prioritisation of what is validated, using #384 as a starting point.

[darakian]

Philosophically I think this is great, but I'd love to see more atomized and detailed steps. I think there's a conversation we often get into about improving quality which then leads into the murky "how do we define quality?" question which then leads us into the awkward place where we try to quantify quality. I'll assert that trying to quantify quality is a bad idea and leads people to cynical states of being which is less than ideal.

I suggest we review all fields in the schema and establish a set of minimal validation rules for them. These rules would only apply if a field is present in the record.

This is great. Can we (you) start iterating these fields? Maybe open a PR with attached (minimal) RFD to make the change on a per-field basis? I'd be happy pair on these too to help get the ball rolling. If these are small changes it may be worth making the case that they can go into 5.x rather than waiting for 6 👍

[jgamblin]

I appreciate the positive feedback and the enthusiasm to move this forward. I'm excited about this idea too, especially the focus on applying minimal validation rules.

I've been burned by doing work that doesn't get used, so before I invest a lot of time into this, I'd like to get agreement on a path forward. Currently, there are 17 open pull requests on this branch, with the oldest dating back to 2021.

Given this, I would like to get a more concrete commitment that these changes will be reviewed and merged in a timely manner. I'm happy to do the work and even pair with you to get the ball rolling, but I want to make sure the effort will lead to a tangible outcome.

Once we have an agreement on the process, I can start iterating on these fields as you suggested.

[dwelch2344]

I think there's a conversation we often get into about improving quality which then leads into the murky "how do we define quality?" question which then leads us into the awkward place where we try to quantify quality.

I agree with this. I also think there's a history of over-prioritizing experience from a CNA point of view when the starting point should be working back from impact from CVE Consumer POV.

As such, imo the first real questions are along the lines of "what are the consumer pain point(s) related to data quality" and "what is the ordered priority of addressing said pain points". That said, I'll admit I'm not well read on prior works (though I have plenty of thoughts from being in the 'long time CVE consumer' demographic)

I would like to get a more concrete commitment that these changes will be reviewed and merged in a timely manner.

This! This is the hardest part of an open community, and imo I still don't know who the "stakeholder" (ie who can make that commitment to @jgamblin) / where the actual process-bottleneck is to address this.

Open to input, but I feel like we (QWG/AWG) have been trying to refine processes to alleviate this, and we could use @jgamblin's ask here to tangibly do so.

So, what's the play here? @jgamblin is it literally what you said of implementing:

• Strings: Require a minLength greater than zero (e.g., minLength: 1) to prevent empty strings.
• Arrays: Require a minItems greater than zero (e.g., minItems: 1) to prevent empty arrays.
• Numbers/Integers: For fields that represent a count or a measure, require a minimum value greater than zero (e.g., minimum: 1) to ensure the value is meaningful.

If so, I'm assuming that means only on required fields? Is there a precursory step of identify all the fields, giving a limited time to opine in xWG(s), then doing the work? Guess I'm just trying to funnel us to a concise + actionable ask before WG meetings this week...