CycloneDX and OpenVEX express the same idea with different vocabularies. CycloneDX 1.6 uses analysis states such as exploitable, in_triage and not_affected, while OpenVEX uses affected, under_investigation and not_affected. A rough mapping works for most statements, but a few values need care.
The CycloneDX 1.6 vocabulary
In the CycloneDX 1.6 JSON schema, a vulnerability's analysis object has these fields: state, justification, response, detail, firstIssued and lastUpdated.
The state values are resolved, resolved_with_pedigree, exploitable, in_triage, false_positive and not_affected.
The justification values are code_not_present, code_not_reachable, requires_configuration, requires_dependency, requires_environment, protected_by_compiler, protected_at_runtime, protected_at_perimeter and protected_by_mitigating_control.
The response values are can_not_fix, will_not_fix, update, rollback and workaround_available.
The OpenVEX vocabulary
Statuses: not_affected, affected, fixed, under_investigation. Justifications: component_not_present, vulnerable_code_not_present, vulnerable_code_not_in_execute_path, vulnerable_code_cannot_be_controlled_by_adversary, inline_mitigations_already_exist.
State mapping
| CycloneDX state | Closest OpenVEX status |
|---|---|
| exploitable | affected |
| in_triage | under_investigation |
| not_affected | not_affected |
| resolved | fixed |
| resolved_with_pedigree | fixed |
| false_positive | not_affected, with care |
False positive does not map cleanly. It says the scanner was wrong, for example a wrong component match, while not_affected says the product is real but safe. Choose based on the reason.
Justification mapping
| CycloneDX | Closest OpenVEX |
|---|---|
| code_not_present | vulnerable_code_not_present |
| code_not_reachable | vulnerable_code_not_in_execute_path |
| protected_by_mitigating_control | inline_mitigations_already_exist |
The other CycloneDX values, such as requires_configuration, requires_environment and protected_at_perimeter, have no direct OpenVEX equivalent. In OpenVEX you would use an impact statement to carry that reasoning. Notably, CycloneDX protected_at_perimeter describes protection outside the product, which OpenVEX's inline mitigations definition does not allow.
What CycloneDX adds
The response field lets a supplier say will_not_fix or can_not_fix, which OpenVEX has no dedicated field for. The CycloneDX schema describes responses as strongly encouraged where the state is exploitable.
Practical advice
If you convert between formats, keep the original value in a note. Do not claim a stronger justification than the source gave. When in doubt, drop to an impact statement and explain.
A conversion routine
- Convert the state first, using the closest status in the table above.
- If the state is not_affected or false_positive, convert the justification next.
- Where no direct justification exists, write the reason into an impact statement.
- Copy the detail text from CycloneDX into the OpenVEX status notes or impact statement so reasoning is not lost.
- Carry the first issued and last updated times across, and increment versions on the new document.
- Record in the new document's tooling field that it was converted, so consumers know the original source.
Run the reverse conversion the same way, and expect to drop OpenVEX fields that CycloneDX stores elsewhere, such as the supplier on a product.
Quick check
Can I lose information converting CycloneDX to OpenVEX?
Yes. Several justifications and the response field have no direct equivalent, so keep the originals in a note.
Sources
Last reviewed: 19 October 2026.
