Consider making cve-schema releases time-based rather than feature-based

[alilleybrinker]

One of the ongoing discussions in the QWG is how to make the set of processes around evolving the CVE Record Format clearer and more intelligible, both to QWG participants and to outside stakeholders. Since the CVE Record Format is the data format for CVE and thus the point of integration between CVE (and thereby CNAs and ADPs) and its many downstream consumers, having a clear and predictable process for evolving the format is very important.

Currently, releases of new versions of the Record Format are feature-based, meaning the QWG decides by consensus to release a new version when they feel prepared to do so. Releases are not made on a regular schedule, and there is no bound on the possible time between new releases.

I believe we would benefit from transitioning to a time-based process for releasing new versions.

As I see it, there are several key benefits to a time-based release process:

• Predictability for CVE data producers and consumers.
• Predictability for QWG participants.

Predictability for CVE data producers and consumers

The key advantage for consumers is that updates to the CVE record format become easier to plan for. This applies both to direct consumers of CVE data and to vendors which consume CVE data to enrich or distribute to their customers. CVE is a large and many-stakeholder system, and making new releases on a schedule aids consumers who can then plan for and budget time to prepare for changes in upcoming releases.

This predictability also applies to CVE producers, as key endpoints of the CVE Services API directly take either entire CVE records or just CNA or ADP containers, all of which must be in the current published version of the CVE record format. As such, producers' ability to plan for and adapt to changes in the record format directly impacts their ability to continue publishing CVE entries, an operation that can at its most tense be highly security-critical and time-sensitive.

Predictability for QWG participants

Under the current process, participants in the QWG must reach consensus about what proposals to include or not include in any upcoming release. The combination of a consensus-based process and a feature-based release schedule often lends itself toward inaction and difficulty successfully landing improvements to the schema. Even when changes are merged and in theory ready for publication in a new version, the group may fail to form consensus around a release because of a desire to incorporate additional changes which are not yet merged or are less mature and not expected to be ready soon.

By transitioning to a time-based release process, while retaining the consensus-based decision-making, the questions posed to the QWG's participants go down. Instead of having to ask both 1) whether to merge a proposal and 2) whether to cut a new release, they can focus solely on the proposals, knowing that new releases will be made on the schedule regardless of the group's decisions on features.

This should help to make the QWG function more smoothly, and make the overall process clearer and more predictable for QWG participants.

[david-waltermire]

I like the idea of timed releases. We have a tendency to "feature bomb" with large releases. This could help level this out quite a bit. How often would we release?

[alilleybrinker]

"How often" is a good question! If we expect most releases to be only addition-level changes, the churn they'd introduce would be for data consumers who need to parse / handle new fields or new types. Each new releases would create work for those folks to handle the new features added in a release. Addition-level changes preserve backwards-compatibility but they still require work on the part of consumers at least (and CNAs, though in theory on a slower timescale to adopt new features for better CVE record enrichment).

For comparison, the Rust programming language releases every 6 weeks, but their changes in theory can be transparently adopted by Rust users with (usually) minimal effort or churn given that they're shipping an implementation and have rigorous standards and automation in place to get high confidence on backwards-compatibility.

I'd argue that a 3-month release schedule (so, four releases a year) would strike a good balance between limiting churn on CVE record consumers and keeping the ecosystem waiting a long time for improvements. It should also in theory help smooth out the "feature bomb" problem you identified, and give sufficient time for engaged stakeholders to prepare for upcoming releases.

Especially if coupled with the previously-discussed idea of some sort of "Inside CVE" blog to communicate about upcoming technical changes with engaged stakeholders, I think a 3-month cadence would make sense.