-
-
Notifications
You must be signed in to change notification settings - Fork 93
|
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.
|
All reactions
-
🎉 2
Replies: 2 comments 1 reply
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.
All reactions
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.
All reactions
We hit this exact mapping building a free OpenVEX aggregator (getreel.dev/vex) that normalises uploaded CycloneDX VEX to OpenVEX, so I turned the table in this thread into a versioned, machine-readable file in case it's useful:
https://github.com/getreeldev/cyclonedx-to-openvex (Apache-2.0)
The mapping is crosswalk.yaml, anchored on the CISA labels and seeded from here. Each entry has a fidelity flag (exact/lossy/contested)
e.g. the five justifications that collapse into vulnerable_code_cannot_be_controlled_by_adversary are flagged lossy + reverse_ambiguous (deterministic forward, lossy back, as noted upthread).
Two cells I marked contested, input welcome:
- false_positive → not_affected: CDX state has no justification, but OpenVEX requires one; a bare false_positive can't be valid OpenVEX (we skip + report).
- protected_at_runtime: grouped under cannot_be_controlled here, arguably inline_mitigations_already_exist.
Happy to upstream the YAML if useful, just formalising what's already in this thread.