Make CVE JSON compatible with VEX

[zmanion]

From today's SPWG meeting, the current CVE JSON format (unsurprisingly) almost implements VEX, as defined here:

https://www.cisa.gov/sites/default/files/2023-04/minimum-requirements-for-vex-508c.pdf

Should CVE JSON be compatible with VEX?

At a glance, changes would need to be made to status, and some additional VEX-specific fields would need to be added, such as:

• not_affected/justification
• action_statement
• impact_statement
• some timestamps (maybe, may be able to reuse existing timestamps)

Status justification would need a definition.

See also #8 which also includes CSAF integration, which I do not think is appropriate for CVE JSON.

[zmanion]

This proposal should perhaps be limited to provide simplified or "direct" VEX -- so that a reader can derive VEX from CVE only for directly affected (or unaffected, or unknown) products. IOW, what CVE already is able to express, that some product or range has some status, and not that CVE records would also need to be able to reference the upstream product or vulnerability.

Yes: CVE-1 VEX says that producxt P is affected by CVE-1.

No: CVE-1 VEX says that product P is affected by CVE-2 because P uses upstream U which is affected by CVE-2.

The second case would be nice to have, but would require a way for a CVE record to reference the upstream product and vulnerability, which is a bigger change and should/could be handled separately.

[zmanion]

Bumping this as at least two VEX-associated topics have come up in the discussion on #12.

How to clearly convey "fixed" status

status and defaultStatus can have the values
"affected"
"unaffected"
"unknown"

It is (still) common to write prose status information in descriptions but this is not machine readable. CNAs use different techniques to convey "fixed" status, for example, using lessThanOrEqual or lessThan inside a version range. Or Red Hat style using "defaultStatus": "affected" with versions ranges with "status": "unaffected" (e.g., CVE-2024-0229).

So, we can imply a version that is fixed, by setting a affected/unaffected boundary. This has, more or less, been working. But what does that boundary really mean? Is the software unaffected because of a patch or update? Or was the software never affected in the first place?

Whether or not we choose to become VEX-compatible, I suggest we add a fixed status value.

[zmanion]

The second VEX-associated topic from #12 (actually being discussed in at least this email thread).

Referencing the upstream vulnerable software and/or vulnerability

There is a desire to be able, in a CVE Record, to reference either or both of the upstream vulnerable software and the vulnerability inherited (or not) from upstream. This is a core design feature of VEX.

The CVE Record format discussion includes a suggestion to add (a) field(s) to be able to reference the "source affected product." This seems useful, there are numerous examples of confusion about what a CVE ID is scoped to: The downstream software, the upstream software, or the interaction between the two, or something else. Here are two examples I've looked into closely: CVE-2022-38171 and CVE-2024-21893.

Relevant CNA Operational Rules:

4.1.12 The act of updating Product dependencies MUST NOT be determined to be a Vulnerability, regardless of whether the dependencies have Vulnerabilities. For example, updating a library to address a Vulnerability in that library MUST NOT be determined to be a new Vulnerability in a Product that uses the library, and a Vulnerability advisory for the Product SHOULD reference the CVE ID for the Vulnerability in the library. See 4.2.13.

4.2.13 If multiple Products are affected by the same Independently Fixable Vulnerability, then the CNA:

1. MUST NOT assign more than one CVE ID if the Products are vulnerable because they share the vulnerable code. The assigned CVE ID will be shared by the vulnerable Products.
2. SHOULD assign different CVE IDs if the Products do not share vulnerable code.
3. SHOULD assign different CVE IDs if the CNA is uncertain whether the Products share vulnerable code.

4.2.14 If a Product is affected by a Vulnerability because it uses the functionality or specification of another Product, then a CNA:

1. MUST assign a CVE ID to each known vulnerable implementation if there is a secure way of using the functionality or specification.
2. MUST assign a single CVE ID if there is no option to use the functionality or specification in a secure way.
3. SHOULD assign different CVE IDs to each known vulnerable implementation if the CNA is uncertain whether there is a secure way.

While I appreciate the need to reference upstream, it seems that doing so could lead to many CVE Records saying "software S is affected by vulnerability V because S uses upstream software U that has V." At present, policy and rules say not to assign a new CVE ID for this case. U should have a CVE ID for V, P should (MUST) not.