OpenVEX statements whose product is the SBOM root component are ignored by trivy sbom for packages of other ecosystems

[ryru]

Description

When scanning a CycloneDX SBOM, an OpenVEX statement with product = the SBOM root component's PURL and subcomponent = the vulnerable package is not applied, except for packages in the same ecosystem as the root PURL.

It seems that since #9604, the VEX filter rebuilds the BOM with a synthetic root that has no PURL, so the product never matches for packages of other ecosystems.

I think the open PR #11304 would also fix this problem.

Context: I'm working on Vulnlog, a CLI tool that generates, among other artifacts, OpenVEX documents from a YAML-based vulnerability analysis. I stumbled over this while testing Vulnlog's OpenVEX output with real-life data and scanners such as Trivy.
The VEX statements use the released application (the SBOM's root component) as product, which is, to my knowledge, the typical vendor case of shipping an SBOM together with a VEX document.

Desired Behavior

Both findings are suppressed (see example below).

Actual Behavior

• CVE-2022-45868 (h2, maven, same ecosystem as the root PURL) is suppressed.
• CVE-2026-27601 (underscore, NPM) is not suppressed, although the VEX statement should apply.

Reproduction Steps

Run this command with the below example files.


trivy sbom --vex test-openvex.json test-sbom.json


SBOM:
```json
{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "component": {
      "type": "application",
      "bom-ref": "app",
      "name": "app",
      "version": "1.0.0",
      "purl": "pkg:maven/com.example/app@1.0.0"
    }
  },
  "components": [
    { "type": "library", "bom-ref": "pkg:maven/com.h2database/h2@2.1.214", "group": "com.h2database", "name": "h2", "version": "2.1.214", "purl": "pkg:maven/com.h2database/h2@2.1.214" },
    { "type": "library", "bom-ref": "pkg:npm/underscore@1.13.6", "name": "underscore", "version": "1.13.6", "purl": "pkg:npm/underscore@1.13.6" }
  ],
  "dependencies": [
    { "ref": "app", "dependsOn": ["pkg:maven/com.h2database/h2@2.1.214", "pkg:npm/underscore@1.13.6"] },
    { "ref": "pkg:maven/com.h2database/h2@2.1.214", "dependsOn": [] },
    { "ref": "pkg:npm/underscore@1.13.6", "dependsOn": [] }
  ]
}

OpenVEX:

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.com/vex/app-1.0.0",
  "author": "Example",
  "timestamp": "2026-09-28T00:00:00Z",
  "version": 1,
  "statements": [
    {
      "vulnerability": { "name": "CVE-2022-45868" },
      "products": [ { "@id": "pkg:maven/com.example/app@1.0.0", "subcomponents": [ { "@id": "pkg:maven/com.h2database/h2@2.1.214" } ] } ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path"
    },
    {
      "vulnerability": { "name": "CVE-2026-27601" },
      "products": [ { "@id": "pkg:maven/com.example/app@1.0.0", "subcomponents": [ { "@id": "pkg:npm/underscore@1.13.6" } ] } ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path"
    }
  ]
}

### Target

SBOM

### Scanner

Vulnerability

### Output Format

Table

### Mode

Standalone

### Debug Output

```bash
trivy sbom --vex test-openvex.json test-sbom.json --debug
2026-09-29T16:31:29Z	DEBUG	Default config file "file_path=trivy.yaml" not found, using built in values
2026-09-29T16:31:29Z	DEBUG	Cache dir	dir="/home/pascal/.cache/trivy"
2026-09-29T16:31:29Z	DEBUG	Cache dir	dir="/home/pascal/.cache/trivy"
2026-09-29T16:31:29Z	DEBUG	Parsed severities	severities=[UNKNOWN LOW MEDIUM HIGH CRITICAL]
2026-09-29T16:31:29Z	DEBUG	Ignore statuses	statuses=[]
2026-09-29T16:31:29Z	DEBUG	DB update was skipped because the local DB is the latest
2026-09-29T16:31:29Z	DEBUG	DB info	schema=2 updated_at=2026-09-29T13:11:12.644596957Z next_update=2026-09-30T13:11:12.644596686Z downloaded_at=2026-09-29T16:27:13.568496201Z
2026-09-29T16:31:29Z	DEBUG	[pkg] Package types	types=[os library]
2026-09-29T16:31:29Z	DEBUG	[pkg] Package relationships	relationships=[unknown root workspace direct indirect]
2026-09-29T16:31:29Z	INFO	[vuln] Vulnerability scanning is enabled
2026-09-29T16:31:29Z	DEBUG	Initializing scan cache...	type="memory"
2026-09-29T16:31:29Z	INFO	Detected SBOM format	format="cyclonedx-json"
2026-09-29T16:31:29Z	DEBUG	Unmarshalling CycloneDX JSON...
2026-09-29T16:31:29Z	DEBUG	[notification] Running version check
2026-09-29T16:31:29Z	WARN	Third-party SBOM may lead to inaccurate vulnerability detection
2026-09-29T16:31:29Z	WARN	Recommend using Trivy to generate SBOMs
2026-09-29T16:31:29Z	DEBUG	OS is not detected.
2026-09-29T16:31:29Z	DEBUG	Detected OS: unknown
2026-09-29T16:31:29Z	INFO	Number of language-specific files	num=2
2026-09-29T16:31:29Z	INFO	[jar] Detecting vulnerabilities...
2026-09-29T16:31:29Z	DEBUG	[jar] Scanning packages for vulnerabilities	file_path=""
2026-09-29T16:31:29Z	INFO	[node-pkg] Detecting vulnerabilities...
2026-09-29T16:31:29Z	DEBUG	[node-pkg] Scanning packages for vulnerabilities	file_path=""
2026-09-29T16:31:29Z	DEBUG	Specified ignore file does not exist	file=".trivyignore"
2026-09-29T16:31:29Z	INFO	Some vulnerabilities have been ignored/suppressed. Use the "--show-suppressed" flag to display them.

Report Summary

┌─────────┬──────────┬─────────────────┐
│ Target  │   Type   │ Vulnerabilities │
├─────────┼──────────┼─────────────────┤
│ Java    │   jar    │        0        │
├─────────┼──────────┼─────────────────┤
│ Node.js │ node-pkg │        1        │
└─────────┴──────────┴─────────────────┘
Legend:
- '-': Not scanned
- '0': Clean (no security findings detected)


Node.js (node-pkg)

Total: 1 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 1, CRITICAL: 0)

┌────────────┬────────────────┬──────────┬────────┬───────────────────┬───────────────┬─────────────────────────────────────────────────────┐
│  Library   │ Vulnerability  │ Severity │ Status │ Installed Version │ Fixed Version │                        Title                        │
├────────────┼────────────────┼──────────┼────────┼───────────────────┼───────────────┼─────────────────────────────────────────────────────┤
│ underscore │ CVE-2026-27601 │ HIGH     │ fixed  │ 1.13.6            │ 1.13.8        │ Underscore.js: Underscore.js: Denial of Service via │
│            │                │          │        │                   │               │ recursive data structures in flatten and...         │
│            │                │          │        │                   │               │ https://avd.aquasec.com/nvd/cve-2026-27601          │
└────────────┴────────────────┴──────────┴────────┴───────────────────┴───────────────┴─────────────────────────────────────────────────────┘

Operating System

Ubuntu 26.04 LTS

Version

Version: 0.72.0
Vulnerability DB:
  Version: 2
  UpdatedAt: 2026-09-29 13:11:12.644596957 +0000 UTC
  NextUpdate: 2026-09-30 13:11:12.644596686 +0000 UTC
  DownloadedAt: 2026-09-29 16:27:13.568496201 +0000 UTC

Checklist

• Run trivy clean --all
• Read the troubleshooting

[DmitriyLewen]

Hi @ryru, thanks for the detailed report and the ready-to-use reproduction files!

I reproduced the issue on the current main: CVE-2022-45868 (h2) is suppressed, while CVE-2026-27601 (underscore) is not.
This is a bug.

Here is what happens:

1. A third-party SBOM has no Trivy application components (lock files, etc.), so Trivy groups the packages by ecosystem.
   The metadata root component has the PURL pkg:maven/..., so it is decoded as a regular package and goes into the Java group together with h2.
   underscore goes into a separate Node.js group.
   You can see this in your output as well: Java (jar) and Node.js (node-pkg).
2. Before applying VEX, Trivy rebuilds the BOM from the scan results.
   Relationships are built within each result, so the app → h2 relationship is kept, while app → underscore (which crosses results) is lost.
3. The rebuilt BOM has a synthetic root without a PURL.
   underscore ends up attached directly to this root, so when Trivy walks up from underscore it never reaches pkg:maven/com.example/app@1.0.0, and the statement is not applied.
   h2 is reached through app, which is why it works.

You are right, #11304 fixes this case: it copies the original root's data (including the PURL) into the synthetic root.
I applied that change locally to your example, and both vulnerabilities are suppressed.

One limitation to keep in mind: relationships across ecosystems are still lost.
If the product is an intermediate component rather than the SBOM root, and the subcomponent belongs to a different ecosystem, the statement still won't be applied.
This doesn't affect your scenario (product = SBOM root).

Regards, Dmitriy

[ryru]

I'm glad the repost was helpful.

Do you need any further information or support? Is there a timeline for the fix?

Thank you, @DmitriyLewen!

[DmitriyLewen]

We currently have a lot of tasks, including higher-priority ones, so I can’t give any timeline. But as soon as we have time, we’ll work on #11304.