VEX-like status and justification options

[zmanion]

Support VEX status and justifications as optional?

See also CVEProject/cve-schema#478.

Status

VEX	CVE
not_affected	unaffected
affected	affected
fixed	unaffected
under_investigation	unknown
?	unknown

Justification

VEX requires justification (or an impact statement) for "not_affected" status.

For [status] “not_affected”, a VEX statement SHOULD provide [justification].
If [justification] is not provided then [impact_statement] MUST be provided.

"component_not_present"
"vulnerable_code_not_present"
"vulnerable_code_not_in_execute_path"
"vulnerable_code_cannot_be_controlled_by_adversary"
“inline_mitigations_already_exist"

[zmanion]

Hacked up example, this does not pass schema validation!

"affected": [
  {
    "vendor": "Art",
    "product": "ArtsPDFGenerator (APG)",
    "defaultStatus": "unknown"
    "versions": [
      {
        "versionType": "custom",
        "version": "*",
        "lessThan": "143.0.7499.110",
        "status": "unaffected",
        "x_vexStatus": "not_affected",
        "x_vexStatusJustification": "vulnerable_code_not_present",
        "x_vexImpactStatement": "no really, it's #ifdef'd out"
      }
    ]
  }
]

[zmanion]

Since x_ hacking is not permitted in the affected array, another option is to add another element at the top level of the ADP container, peer with affected and cpeApplicability, let's call it vex. This new element could be a minimal CVE-flavored extension that adds just enough VEX to be compliant. But since this element can't be within affected it is necessary to create a separate list of products, so perhaps it's better to just import OpenVEX. Some OpenVEX fields may be able to be generated or inherited from the ADP container or other parts of the CVE Record.

Like cpeApplicability, vex would be optional and encouraged but not required to precisely match affected data.