| Field | Value |
|---|---|
| RFD Submitter | Jon Moroney |
| RFD Pull Request | RFD #0000 |
Introduce a new semantic versioning version type for the machine readable versions array. The goal of this addition is to provide consumers of CVE records with version information which is interoperable with off the shelf semantic versioning compatible tools. The proposed change includes schema based validation to ensure submitted records conform to the semver specification as well as tests to ensure conformity.
Today the versions array allows for a number of typed version fields which should inform the reader how to interpret the data. Alas, there is no validation that a record producer must conform to and as a result the version types have been used inconsistently. At time of writing a consumer reading the semantic versioning type in particular has about a 44% chance of the data conforming to the semantic versioning specification.
As a result consumers of CVE records cannot build reliable automation from the data in the record itself. Multiple sub-patterns do exist, but there is canonical list of them nor is there any guarantee of their stability. This leads to increased operational complexity in vulnerability management and potentially to vulnerabilities going unresolved.
Failing to adopt stricter datatypes will maintain the status quo which is generally accepted to be lacking.
The proposed change adds a new semver-2.0.0-version pattern and five new properties for expressing version ranges. The parameters are exactly, inclusiveLowerBound, exclusiveLowerBound, inclusiveUpperBound, and exclusiveUpperBound and map to the mathematics operators =, >=, >, <=, and <. These parameters are only expected to be used with the semver-2.0.0 version type. Validation is proved in the form of a regular expression which is taken directly from semver.org in order to ensure interoperability.
Examples are provided as tests and may be viewed in the valid and invalid semver-2-0-0 subdirectories here: https://github.com/CVEProject/cve-schema/tree/0dc04e2a9adb9e3d50409051ce1d006d79b57a90/schema/support/tests
This proposal has been designed to be very low impact. In the base case both record producers and record consumers can simply ignore the new data type. Adoption of the new data type into systems that process CVE records should be quite straight forward as semantic versioning is well supported across many languages. Once records begin to be produced with semver-2.0.0 values a record consumer will be able to build reliable vulnerability managment automation based on the data.
This change adds one new, optional, value to the versions array and should be completely backwards compatible as no prior data formats are altered. The version type is currently arbitrary and so record providers are free to populate anything in that field, however no currently published records have used semver-2.0.0.
Both consumers are producers will need to update their code/process in order to make use of the new field. Should there be a desire to coordinate a migration an addition could be made to this RFD with guidance both for record producer and consumers, but off the shelf, semver compatible tools are expected to work.
Existence of the new version type should be communicated to stakeholders upon the RFDs acceptance.
6+ months after the acceptance and adoption of this RFD process, the QWG should conduct a review of published CVE records to assess usage of the new version type. Additionally the QWG should solicit a survey to QWG members and outside CVE stakeholders about the perceived value of the new type. If there is low/no usage as well as a poor qualitative perception then the effort should be considered a failure and discussion of a rollback should be considered.
If there is consistent measured usage as well as positive qualitative perception then the effort should be considered a success. Anything between these two polls will require more qualitative analysis, but it is the RFD author's opinion that if there is a lack of consensus then the effort should by default be considered a failure.
A roll back of this RFD would consist of a removal of the semver-2.0.0 version type and associated tests.
This change originated out of a conversation detailing the shortcomings of the current versioning system here: #362
An alternative to adopting this RFD would be to not adopt it.
Medium
None currently.
Other common versioning types could have new, validated versions provided via subsequent RFDs.