Mapping CycloneDX bi-directionally to Minimum Requirements for VEX

[RingoDev]

Hey there, I have taken a closer look at the Minimum Requirements for VEX as published by CISA across the major VEX document standards. In that document CISA describe 5 different Status Justifications that should be set if a VEX statement is created with status Not Appliccable.

I have some difficulties clearly mapping the existing CycloneDX justification values to that scheme. Is there some official guidance of how this should be mapped? For context, I have read through the VEX Use Cases and the JSON spec.

CISA Justifications	SPDX 3.0	CycloneDX 1.6	CSAF 2.0	OpenVEX 0.2
Component  Not Present	VexJustificationType.componentNotPresent	potentially vulnerabilities[].analysis.state.false_positive	vulnerabilities[].flags[].label.component_not_present	statements[].justification.component_not_present
Vulnerable Code Not Present	VexJustificationType.vulnerableCodeNotPresent	vulnerabilities[].analysis.justification.code_not_present	vulnerabilities[].flags[].label.vulnerable_code_not_present	statements[].justification.vulnerable_code_not_present
Vulnerable Code Not In Execute Path	VexJustificationType.vulnerableCodeNotInExecutePath	vulnerabilities[].analysis.justification.code_not_reachable	vulnerabilities[].flags[].label.vulnerable_code_not_in_execute_path	statements[].justification.vulnerable_code_not_in_execute_path
Vulnerable Code Cannot Be Controlled By Adversary	VexJustificationType.vulnerableCodeCannotBeControlledByAdversary	?	vulnerabilities[].flags[].label.vulnerable_code_cannot_be_controlled_by_adversary	statements[].justification.vulnerable_code_cannot_be_controlled_by_adversary
Inline Mitigations Already Exist	VexJustificationType.inlineMitigationsAlreadyExist	vulnerabilities[].analysis.justification.protected_by_mitigating_control	vulnerabilities[].flags[].label.inline_mitigations_already_exist	statements[].justification.inline_mitigations_already_exist

[stevespringett]

Vulnerable Code Cannot Be Controlled By Adversary isn't really a justification. Its a superset which includes the rationale why the code cannot be controlled by an adversary, including the code is not in the execute path.

There are multiple additional rationales why vulnerable code cannot be controlled by an adversary, including:

• requires_configuration
• requires_dependency
• requires_environment
• protected_at_runtime
• protected_at_perimeter

Any one of these CycloneDX justifications could prevent vulnerable code from being controlled by an adversary. CycloneDX justifications pre-date any official guidance or pseudo VEX specification from CISA. As you can see, CycloneDX is more granular in how it identifies justifications that could prevent vulnerable code from being executed by an adversary. Converting CycloneDX to any of the other VEX specs is fairly elementary as a result. Converting the other specs to CycloneDX can be challenging as those specs do not support the level of granularity that CycloneDX provides.

[RingoDev]

Thanks for taking the time and the thorough answer @stevespringett.

That was my impression as well, that CycloneDX offers more fine-granular options in that regard.

I had hoped that with CISA's pseudo standard we might get to a commonly agreed set of states and justifications to communicate "not affectedness", which is harder to dispute due to being uniformally agreed on categories. I agree with your point that "cannot be controlled by adversary" is very vague and very hard to prove without a more specific breakdown in most cases.

As it stands right now I feel like CycloneDX stands out a bit like a sore thumb in this comparison, which feels a bit sad to me, but I guess is what we have to deal with and potentially provide CISA with feedback on.