fix: generated VEX outputs lose CycloneDX BOM component identity #5723

Description

I found a BOM-VEX identifier correspondence problem in cve-bin-tool when generating VEX for the same target (ubuntu:18.04) in two workflows:

1. External CycloneDX BOM (docker_bom.json, generated with cdxgen) -> cve-bin-tool VEX
2. End-to-end cve-bin-tool generation from exported rootfs (ubuntu-rootfs) -> CycloneDX BOM + OpenVEX

I am attaching the generated files used in this report.

The issue is that the generated VEX output does not preserve enough component identity to remain directly mappable to the source BOM components.

For the external BOM case, I tested all supported VEX formats (openvex, cyclonedx, csaf) and all showed target identity / resolvability problems in different ways:

• OpenVEX: targets only resolve via weak name+version matching, and the generated VEX PURLs do not match the BOM PURLs
• CycloneDX VEX: targets are rewritten into unresolved generic refs wrapped in urn:cdx:...#...
• CSAF: only product-level internal IDs such as CSAFPID_0001 are used, which cannot be mapped back to BOM components

For the end-to-end cve-bin-tool case, I observed a similar issue even when both the BOM and the OpenVEX were generated by cve-bin-tool itself in a single run: some VEX products only resolve via weak name+version, and others become ambiguous when multiple BOM components share the same coarse identity.

Representative results from my BOM-VEX linkage validator:

External BOM -> OpenVEX:
✘ CROSS-003 Identifier Consistency ERROR
PURL mismatch: BOM='pkg:deb/ubuntu/apt@1.6.17?arch=arm64&distro=ubuntu-18.04&distro_name=bionic' vs VEX='pkg:generic/debian/apt@1.6.17'

External BOM -> CycloneDX VEX:
✘ CROSS-001 Target Resolvability ERROR
VEX product 'urn:cdx:01ace85b-6ab6-4538-9137-f74d1476fbe9/1#pkg:generic/gnu/bash@4.4.18-2ubuntu1.3' (vuln: CVE-2019-18276) cannot be resolved to any BOM component.

External BOM -> CSAF:
✘ CROSS-001 Target Resolvability ERROR
VEX product 'CSAFPID_0001' (vuln: CVE-2020-3810) cannot be resolved to any BOM component.

End-to-end cve-bin-tool BOM + OpenVEX:
✘ CROSS-002 Target Uniqueness WARNING
VEX product 'pkg:generic/kernel/util-linux@2.31.1' has ambiguous weak match (name+version): 5-util-linux, 6-util-linux, 7-util-linux, 8-util-linux

To reproduce

Case 1: external CycloneDX BOM generated with cdxgen

1. Generate a CycloneDX BOM for ubuntu:18.04 externally and save it as docker_bom.json.
2. Run cve-bin-tool on that BOM three times, changing only --vex-type and --vex-output:

cve-bin-tool \
  --offline \
  --sbom cyclonedx \
  --sbom-file docker_bom.json \
  --vex-type <openvex|cyclonedx|csaf> \
  --vex-output <output-file> \
  --product ubuntu \
  --vendor canonical \
  --release 18.04 \
  -f json \
  -o <report-file>

3. Validate each generated VEX document against docker_bom.json.
4. Observe:

• OpenVEX only weakly resolves and has identifier mismatch
• CycloneDX VEX cannot resolve targets to BOM components
• CSAF product IDs cannot resolve to BOM components at all

Case 2: end-to-end cve-bin-tool generation from exported rootfs

1. Export the ubuntu:18.04 filesystem to a local directory (ubuntu-rootfs).
2. Run:

cve-bin-tool ubuntu-rootfs \
  --offline \
  --sbom-output ./bom.cdx.json \
  --sbom-type cyclonedx \
  --vex-output ./vex.openvex.json \
  --vex-type openvex \
  --product ubuntu \
  --vendor canonical \
  --release 18.04 \
  -f json \
  -o ./report.json

3. Validate vex.openvex.json against bom.cdx.json.
4. Observe that some products resolve only by weak name+version, and some become ambiguous when multiple BOM components share the same coarse identity.

Expected behaviour:
Generated VEX output should preserve enough target identity to remain directly relatable to the input CycloneDX BOM components, ideally through BOM-compatible references or equally strong identifiers.

Actual behaviour:
Generated VEX output weakens, rewrites, or abstracts away component identity, causing weak, ambiguous, or unresolved BOM-VEX matching.

Version/platform info

Version of CVE-bin-tool( e.g. output of cve-bin-tool --version):

• 3.4.1
  Installed from pypi or github?
• Installed from GitHub source in a Python virtual environment
  Operating system:
• macOS / Darwin arm64
  Python version (e.g. python3 --version):
• 3.12.7
  Running in any particular CI environment we should know about? (e.g. Github Actions)
• No

Anything else?

I found this while building a BOM-VEX validation/interoperability workflow.

• docker_bom.json was generated externally with cdxgen
• bom.cdx.json, vex.openvex.json, and report.json were generated by cve-bin-tool in a single run from ubuntu-rootfs

I am currently working on BOM-VEX validation/interoperability research, and this issue came up during that work. If helpful, I’d also be happy to share additional validator output or help test a fix in this area.

I attached the reproduction files grouped by case:

• Case 1 (external BOM -> cve-bin-tool VEX):
  cve-bin-tool_cdx_vex.json
  cve-bin-tool_csaf.json
  cve-bin-tool_openvex.json
  docker_bom.json

• Case 2 (end-to-end cve-bin-tool generation from ubuntu-rootfs):
  bom.cdx.json
  vex.openvex.json