CVE IDs really need structured inter/intra-ID relationships, as noted in 1999

[zmanion]

While the seminal 1999 CVE paper covers relationships in section "7 Future Work" it is now 2022 and it's well past time to design and implement at least intra-CVE ID relationships.

https://www.cve.org/Resources/General/Towards-a-Common-Enumeration-of-Vulnerabilities.pdf

Just a snippet:

To better clarify the relationships between the elements of a vulnerability database and
those of a CVE, we anticipate utilizing the following relations (currently informally defined).
Suppose that V1 is a vulnerability as defined in one database, and V2 is a vulnerability that
is defined in another database (e.g. a CVE). Then:
V1 = V2 if (V1 and V2 refer to the same vulnerability)
V1 subsumes V2 if (V1 includes V2 and other vulnerabilities)
V1 intersects V2 if (V1 and V2 share some, but not all, characteristics)

See also:

https://docs.google.com/presentation/d/1L41fZ3a3C7sD154ZFWjK3V3ZZv1WMHRyJ30gZcGAi08

This is not conceptually difficult and I suggest we start with a small set of relationship types. Here is a JSON reference implementation, which could be adpated to work with CVE:

https://github.com/FIRSTdotorg/vrdx-sig-vxref-wip

[zmanion]

Other relationship changes have been discussed, such as allowing non-authors to update CVE ID content, particularly references, possibly using the ADP concept. Also there are a slew of old vulnerability database source "types" which are probably no longer needed or useful.

If we work on intra-CVE ID relationships, inter-vulnerability ID can essentially be handled at the same time. Examples:

CVE1 different_than CVE2

CVE3 intersects OSV-2021-820

CVE3 subsumes DSA-5222-1

Basic OWL/RDF probably works well here: (URL/ref1) (verb_relationship_type) (URL/ref2)