add aliases and related to Published.cveMetadata

[rsc]

In our work with open-source vulnerability databases, we have found it critical to be able to match CVEs to equivalent entries in other databases as well as to related CVEs.

We propose adding two new fields in the cveMetadata object, named “aliases” and “related”. Both would be lists of strings.

The “aliases” list would be a list of vulnerability IDs in other databases that are considered the same as this CVE. For example, CVE-2020-28498 is also tracked as (that is, the same as) GHSA-r9p9-mrjm-926w, NPM-1648 and SNYK-JS-ELLIPTIC-1064899.

The “related” list would be a list of vulnerability IDs (CVEs or from other databases) that are considered closely related to this CVE. For example, the CVE mentioned in the last paragraph is closely related to - but not the same as - CVE-2020-35149, which is also tracked as GHSA-45q2-34rf-mr94, NPM-1649 and SNYK-JAVA-ORGWEBJARSNPM-1069836.

Using this proposal, the entry for CVE-2020-28498 could list in its cveMetadata:

"aliases": [
  "NPM-1648",
  "GHSA-r9p9-mrjm-926w",
  "SNYK-JS-ELLIPTIC-1064899"
],
"related": [
  "CVE-2020-35149",
  "NPM-1649",
  "GHSA-45q2-34rf-mr94",
  "SNYK-JAVA-ORGWEBJARSNPM-1069836"
],

[chandanbn]

References with URLs, names, and tags were meant to be one way to capture this. Perhaps we need two new tags "alias" and "related"? or just "related" tag, assuming lack of one indicates a directly relevant/equivalent reference. CERT CC had a similar proposal with few more relationships like subset/superset.

Do you see any identifier that would not have an URL?

      "references": [
        {
          "url": "https://github.com/npm/npm/issues/8517",
          "name": "NPM-8517",
          "tags": [
            "issue-tracking"
          ]
        },
        {
          "url": "https://github.com/advisories/GHSA-r9p9-mrjm-926w",
          "name": "GHSA-r9p9-mrjm-926w",
          "tags": [
            "third-party-advisory"
          ]
        },
        {
          "url": "https://github.com/indutny/elliptic/commit/441b7428b0e8f6636c42118ad2aaa186d3c34c3f",
          "name": "441b7428b0e8f6636c42118ad2aaa186d3c34c3f",
          "tags": [
            "patch"
          ]
        },
        {
          "url": "https://github.com/indutny/elliptic/pull/244/commits",
          "name": "",
          "tags": [
            "patch",
            "permissions-required"
          ]
        },
        {
          "url": "https://snyk.io/vuln/SNYK-JS-ELLIPTIC-1064899",
          "name": "SNYK-JS-ELLIPTIC-1064899",
          "tags": [
            "third-party-advisory",
            "vdb-entry"
          ]
        }
      ]

[tcullum-rh]

I'd prefer to use the reference tags for this purpose, as how @chandanbn showed above. I believe all of those other such listings will always (or at least should) have an associated URL, which also plays nicely with the "public reference" requirement of CVE records.

I'd argue that the term "alias" would not be proper here, because e.g. SNYK, GHSA, GHSL, NPM, etc... are not CVE records. I would expect that an "alias" of a CVE record is another name which refers to the actual CVE record, not a related entry in another system. That being said, I do agree with the "related" terminology, but wonder if we could use reference tags for this purpose as mentioned above.

IMO, if we were to do something such as try to make hard one-to-one mappings between CVE and other systems, we would need to ensure that the record specification for those systems is in alignment with CVE. E.G., would it be possible to have a GHSA which lists multiple CVEs? If so, it would make more sense to simply list that GHSA as a reference for the CVE.

[rsc]

Thanks for the feedback. Using references sounds great. I'm hesitant to assume another entry is a direct equivalent without an explicit signal, though. Perhaps that's what "vdb-entry" would be? And then "vdb-related" for things that are similar but not the same?

[rsc]

The only mention of vdb-related in the repo (other than the generated html) seems to be https://github.com/CVEProject/cve-schema/blob/master/schema/v5.0/tags/reference-tags.json, but it doesn't document what any of those tags mean. Are the meanings of the tags documented in another repo or document?

[chandanbn]

AI: add tag definitions to schema AI: introduce new "related" tag

[tcullum-rh]

@chandanbn do we have a preferred way of adding the tag defs to the schema with enums like this? Please see https://github.com/json-schema-org/json-schema-spec/issues/57 and https://groups.google.com/g/json-schema/c/w_5mVYB7OHg . Trying to do it in the least complex and cumbersome manner... We could just add one big description to the tags array, or add a little bit of complexity and use one of the solutions proposed there. I'm not super thrilled about either option tbh.

[chandanbn]

Just having the definitions in the "description" with as plain text string should be sufficient. You can use simple markdown for readability.

For eg., term1: definition.\n\nterm2: definition.\n\n