Skip to content

CycloneDX VEX Exports

CVEScan Web can export vulnerability information in the CycloneDX format (version 1.6), including VEX (Vulnerability Exploitability eXchange) metadata. This document outlines what is included in the export and explains how the VEX state is determined for each vulnerability.

What You Get in the Export

Each vulnerability in the exported BOM contains:

Field Description
id The CVE identifier (e.g. CVE-2021-1234).
description The vulnerability description from the scan report.
published The CVE publication date.
updated The CVE last modified date.
ratings All CVSS scores provided by the scan report (v4.0, v3.1, v3.0, v2.0).
affects Reference to the affected component.
analysis The VEX state and related metadata (see below).

Note

Not all of the fields listed above are always included in the export. For details on which fields are mandatory or optional, refer to the CycloneDX specification.

How the VEX Analysis Is Determined

The VEX analysis is determined based on the following rules:

  1. Excluded from export: Vulnerability entries are omitted entirely when their vulnerable field is false, have no applicable annotation, and have at least one automatic assessment with status version mismatch.
  2. When an applicable and up-to-date non-legacy annotation exists, its status determines the VEX state.
  3. When an applicable annotation exists but is outdated, the VEX state is in_triage with the detail as described in the Manual Assessment table below.
  4. Otherwise, automatic assessments are used and a priority is applied to determine the VEX state.

Manual Assessment → VEX State

The following table shows the mapping of manual assessment status to VEX state, response, justification, and detail:

Annotation Status VEX State Response Justification Detail
Patched resolved — — Concatenated annotation logs that impacts the annotation status
False positive false_positive — — Concatenated annotation logs that impacts the annotation status
Not exploitable not_affected — — Concatenated annotation logs that impacts the annotation status
Accepted exploitable will_not_fix — Concatenated annotation logs that impacts the annotation status
Exploitable exploitable — — Concatenated annotation logs that impacts the annotation status
Ongoing, Pending, Todo in_triage — — Concatenated annotation logs that impacts the annotation status
Legacy — — —
Outdated in_triage — — A line indicating that the vulnerability was updated since the last assessment + concatenated annotation logs that impact the annotation status

Note

If the applicable, up-to-date annotation's latest status is Legacy, it is ignored and automatic assessments are used instead to determine the VEX state.

Automatic Assessment → VEX State

The following table shows the mapping of automatic assessment status to VEX state, justification, response, and detail:

Automatic Assessment (CLI) VEX State Justification Response Detail
Rejected false_positive — — —
Package patched resolved — — —
Patch applied resolved — — —
Version mismatch not_affected code_not_present — —
Code removed not_affected code_not_present — —
Safe config not_affected requires_configuration — —
Package whitelisted not_affected — — —
Patch available No state — — —

Note

  • Patch available produces no state, therefore the analysis is omitted if no other assessment applies.
  • When multiple assessments apply, the highest-priority state wins (see Multiple Automatic Assessments).

Multiple Automatic Assessments

When several automatic assessments apply, the highest-priority state wins:

  1. false_positive
  2. resolved
  3. not_affected

When multiple automatic assessments map to the same most specific state (e.g. not_affected), the most specific justification is used. The priority is as follows:

  1. code_not_present
  2. code_not_reachable
  3. requires_configuration
  4. requires_dependency
  5. requires_environment
  6. protected_by_compiler
  7. protected_at_runtime
  8. protected_at_perimeter
  9. protected_by_mitigating_control