Extend VEX to cater for Status such as CVE Rejected

[msymons]

Vulnerability Analysis "state" consists of the following possibilities :

• Exploitable
• In Triage
• Resolved
• False Positive
• Not Affected

This does not cater for vulnerabilities that are no longer valid, a corner case that I would argue is different to False Positive as it does not require a "response" per se.

In NVD, this state is "rejected" (and "reject" in CVE List).

This should be catered for in VEX.

Using CVE-2021-23334 as an example, this is a vulnerability that was "valid" (and thus subject to VEX analysis) for a period of 4 months before being rejected.

Just to muddy the waters a bit, this CVE is also GHSA-8v27-2fg9-7h62, where the language used in "withdrawn". It is also SNYK-JAVA-ORGWEBJARSNPM-1071860 (the CNA), who used the word "revoked".

[stevespringett]

Thanks for identifying this Mark. In this scenario where CVE-2021-23334 was valid for four months and then rejected. If analysis decisions were made during that four month window, I would think those analysis decisions would remain the same. I'm not sure if its the VEX that should house this data or the vulnerability itself.

For example, if CDX were to add a state field to the vulnerability object with possible values of published and rejected, this would make it more compatible with CVE JSON schema, so systems would not potentially loose this data when exchanging vulns between systems. (think BOV use cases here). And it does not affect the previous audit decisions.

Thoughts?

One other tweak is to add a new VEX analysis state called invalid to indicate that whatever the vulnerability is and for whatever reason, the responding organization does not recognize the legitimacy of the vulnerability.

[stevespringett]

Another thought instead of a new state field (which may get confusing between vulnerability.state and vulnerability.analysis.state would be to simply create a new date field such as rejected and if populated, we'll know that it was rejected and when.

The addition of an invalid VEX analysis state would still be possible though.

[msymons]

A new date field such as rejected would do the trick.

I did neglect one thing though. What about representing "disputed" vulnerabilities? Not the same thing as "rejected" (although I suspect that some vulns might transition from disputed to rejected") but pretty important when understanding VEX.

ie, one might imagine a vuln remaining "In Triage" because it is disputed.

[Tomalrich]

If this is an important issue (which it must be), I think it's a good idea to add a new Vulnerability Analysis "state" in CDX. However, I don't think it's even worth the time to bring this up to the CISA VEX working group. They've more or less abdicated any role in requiring what should be in the actual VEX formats. For example, the document that's intended for publication in January is going to discuss a couple new concepts that aren't in either CSAF or CDX formats - and the leader for that document freely admits it will be years if ever before they're incorporated in one of the formats.

[msymons]

FWIW, I see that cve-schema is planning to add disputedReasons to JSON 5.1: CVEProject/cve-schema/issues/140

[stevespringett]

@msymons we'll have to wait until the CVE Project adds disputedReasons capability to v5.1 and later see if this is something we want to support. As of now, v5.1 is only 26% complete and the milestone does not have a due date. So likely it won't be available prior to the release of CDX 5.1.

From my understanding of this issue, we want:

• A new timestamp on the vulnerability called rejected

one might imagine a vuln remaining "In Triage" because it is disputed.

I agree with this

[stevespringett]

Scheduled for inclusion in v1.5