Move "x_generator" to an official and optional string value "generator"

[jayjacobs]

I suggest, as a way to standardize this field across different tools and more importantly, json records, that we add the "generator" field as a string into the "cveMetadataPublished" definition, and move away from the experimental field for the same purpose.

This is related to, but independent from #318

To be inserted into the properties of the cveMetadataPublished definition (and not required):

generator: {
    type: "string",
    description: "An identifying string for any software used to generate or maintain this record, e.g. \"Vulnogram 0.2.0\".",
    minLength: 1,
    maxLength: 256
},

And leave the field as optional.

[ccoffin]

Probably should make this official in the CVE Record Format. Maybe just define this as stated use what Vulnogram provides today for structure.

[zmanion]

Not to overcomplicate things, but do we want a separate field for generator version? Also is "engine" an unnecessarily weird word?

Current:

"x_generator": {
  "engine": "Vulnogram 0.2.0"
}

Proposed:

"generator": {
  "name": "Vulnogram",
  "version": "0.2.0"
}

[MrMegaZone]

Not to overcomplicate things, but do we want a separate field for generator version? Also is "engine" an unnecessarily weird word?

"generator": {
"name": "Vulnogram",
"version": "0.2.0"
}

I do think name & version are better. 'Engine' never really made sense to me.

I'm not sure if it is possible, but I'd say name is optional, and version is optional but is only valid when name is also present. That way we don't get weirdness with just a 'version' being provided and no name.

[mprpic]

+1 for separate name and version. That is also how the CSAF specification uses this, see e.g.: https://github.com/oasis-tcs/csaf/blob/bdc1381881beeba2a03a6321f37febc9c5794ec5/csaf_2.0/examples/csaf/rhsa-2022_0011.json#L62-L65

[MrMegaZone]

+1 for separate name and version. That is also how the CSAF specification uses this, see e.g.: https://github.com/oasis-tcs/csaf/blob/bdc1381881beeba2a03a6321f37febc9c5794ec5/csaf_2.0/examples/csaf/rhsa-2022_0011.json#L62-L65

Interesting - maybe we should borrow a bit from CSAF:

 "generator": {
        "date": "2022-03-23T20:31:00Z",
        "engine": {
          "name": "Red Hat SDEngine",
          "version": "3.4.3"
        }
      },

[zmanion]

I'm neutral on the date part of the CSAF structure, if we include it we should be careful about documenting that is the date the generator generated which is not any of the other ~6 possible date fields in a record. I'd be OK not having date in generator -- dates are pretty well covered (well see also #392).

[ElectricNroff]

I feel that the CVE Program should maintain a neutral position on whether the record-producing software (or any other information that isn't about the vulnerability) is placed in the CVE Record. As part of maintaining a neutral position, there should be no official field.

CVE Records are often produced in a PSIRT environment, using computers that also (and often simultaneously) have access to substantial amounts of non-public vulnerability information. Adversaries may find it attractive to profile PSIRT targets through any available information, and especially information about what software is used. For example, by knowing the specific software that produced a CVE Record, an adversary may conclude it is both viable and worthwhile to conduct a supply chain attack in an effort to compromise a PSIRT workstation.

It would be much better for the CVE Program to offer an effective way for CNAs to express the popularity of CVE-related software in an anonymous way. https://popcon.debian.org is an example of gathering software popularity data anonymously, but I have no direct knowledge of how well it works. If the CVE Program had a trustworthy anonymous channel, we could expand it to other data items (which arguably also do not belong in the CVE Record):

• preferred language of container author (so we would have better data to support efforts at CVE documentation in other languages)
• amount of time needed to compose the CVE Record (so that we can assess the burdens placed on data producers)
• etc.

[MrMegaZone]

I strongly disagree. This is something being widely done today using x_ fields. Making it an official, but optional field, helps standardize the data. There is also a separate push to drop support for x_ I'm the future as part of the effort to clean up the data.

I see no security benefit in avoiding a standard optional element, and I do see downsides in doing so. If a CNA is concerned about it they can simply not fill in the field.