CSAF example not working

[santiagorr]

Description

Hello trivy developers,

Unless I am wrong, the "Scan with CSAF VEX" example provided in the v0.58 documentation https://trivy.dev/v0.58/docs/supply-chain/vex/file/#csaf doesn't seem to work as expected:

Desired Behavior

I would expect the same behavior described in the mentioned documentation:

$ trivy image debian:11 --vex debian11.vex.csaf
...
2024-01-02T10:28:26.704+0100    INFO    Filtered out the detected vulnerability {"VEX format": "CSAF", "vulnerability-id": "CVE-2019-8457", "status": "not_affected"}

debian11.spdx.json (debian 11.6)
================================
Total: 80 (UNKNOWN: 0, LOW: 58, MEDIUM: 6, HIGH: 16, CRITICAL: 0)

Actual Behavior

$ trivy -d image debian:11 --vex debian11.vex.csaf | grep -C 2 CVE-2019-8457
2024-12-23T17:05:34-03:00	DEBUG	No plugins loaded
2024-12-23T17:05:34-03:00	DEBUG	Default config file "file_path=trivy.yaml" not found, using built in values
2024-12-23T17:05:34-03:00	DEBUG	Cache dir	dir="/home/santiago/.cache/trivy"
2024-12-23T17:05:34-03:00	DEBUG	Cache dir	dir="/home/santiago/.cache/trivy"
2024-12-23T17:05:34-03:00	DEBUG	Parsed severities	severities=[UNKNOWN LOW MEDIUM HIGH CRITICAL]
2024-12-23T17:05:34-03:00	DEBUG	Ignore statuses	statuses=[]
2024-12-23T17:05:34-03:00	DEBUG	DB update was skipped because the local DB is the latest
2024-12-23T17:05:34-03:00	DEBUG	DB info	schema=2 updated_at=2024-12-23T18:16:41.542223648Z next_update=2024-12-24T18:16:41.542223197Z downloaded_at=2024-12-23T20:05:15.012377942Z
2024-12-23T17:05:34-03:00	DEBUG	[pkg] Package types	types=[os library]
2024-12-23T17:05:34-03:00	DEBUG	[pkg] Package relationships	relationships=[unknown root workspace direct indirect]
2024-12-23T17:05:34-03:00	INFO	[vuln] Vulnerability scanning is enabled
2024-12-23T17:05:34-03:00	INFO	[secret] Secret scanning is enabled
2024-12-23T17:05:34-03:00	INFO	[secret] If your scanning is slow, please try '--scanners vuln' to disable secret scanning
2024-12-23T17:05:34-03:00	INFO	[secret] Please see also https://aquasecurity.github.io/trivy/v0.58/docs/scanner/secret#recommendation for faster secret detection
2024-12-23T17:05:34-03:00	DEBUG	Enabling misconfiguration scanners	scanners=[azure-arm cloudformation dockerfile helm kubernetes terraform terraformplan-json terraformplan-snapshot]
2024-12-23T17:05:34-03:00	DEBUG	Initializing scan cache...	type="fs"
2024-12-23T17:05:35-03:00	DEBUG	[secret] No secret config detected	config_path="trivy-secret.yaml"
2024-12-23T17:05:35-03:00	DEBUG	[secret] No secret config detected	config_path="trivy-secret.yaml"
2024-12-23T17:05:35-03:00	DEBUG	[image] Detected image ID	image_id="sha256:ab22521fee6a874ede24f0eabc1193a0d4e4ca417aedf8e2a82911ce84ed0831"
2024-12-23T17:05:35-03:00	DEBUG	[image] Detected diff ID	diff_ids=[sha256:7b329afd97eb4c8a9f81c95a2d2d416de77859f73cb1540dcad0fdc1ee1167f6]
2024-12-23T17:05:35-03:00	DEBUG	[image] Detected base layers	diff_ids=[]
2024-12-23T17:05:35-03:00	INFO	Detected OS	family="debian" version="11.11"
2024-12-23T17:05:35-03:00	INFO	[debian] Detecting vulnerabilities...	os_version="11" pkg_num=96
2024-12-23T17:05:35-03:00	INFO	Number of language-specific files	num=0
2024-12-23T17:05:35-03:00	WARN	Using severities from other vendors for some vulnerabilities. Read https://aquasecurity.github.io/trivy/v0.58/docs/scanner/vulnerability#severity-selection for details.
2024-12-23T17:05:35-03:00	DEBUG	Specified ignore file does not exist	file=".trivyignore"
│                    │                     │          │              │                         │               │ https://avd.aquasec.com/nvd/cve-2019-9192                    │
├────────────────────┼─────────────────────┼──────────┼──────────────┼─────────────────────────┼───────────────┼──────────────────────────────────────────────────────────────┤
│ libdb5.3           │ CVE-2019-8457       │ CRITICAL │ will_not_fix │ 5.3.28+dfsg1-0.8        │               │ sqlite: heap out-of-bound read in function rtreenode()       │
│                    │                     │          │              │                         │               │ https://avd.aquasec.com/nvd/cve-2019-8457                    │
├────────────────────┼─────────────────────┼──────────┼──────────────┼─────────────────────────┼───────────────┼──────────────────────────────────────────────────────────────┤

Reproduction Steps

1. Install trivy 0.58
2. Create the CSAF VEX document as described at https://trivy.dev/v0.58/docs/supply-chain/vex/file/#create-the-csaf-document
3. Run `trivy image debian:11 --vex debian11.vex.csaf`

Target

Container Image

Scanner

None

Output Format

None

Mode

None

Debug Output

The same as the actual behaviour.

Operating System

Linux

Version

$ trivy --version
Version: 0.58.0
Vulnerability DB:
  Version: 2
  UpdatedAt: 2024-12-23 18:16:41.542223648 +0000 UTC
  NextUpdate: 2024-12-24 18:16:41.542223197 +0000 UTC
  DownloadedAt: 2024-12-23 20:05:15.012377942 +0000 UTC

Checklist

• Run trivy clean --all
• Read the troubleshooting

[DmitriyLewen]

Hello @santiagorr
Thanks for your interest to Trivy.

CSAF example uses distro qualifier (pkg:deb/debian/[email protected]%2Bdfsg1-0.8?arch=amd64\u0026distro=debian-11.8).
So this purl doesn't match libdb from debian 11.11.

example:

➜ trivy  image debian:11.8 --vex debian11.vex.csaf
...
2024-12-24T12:30:11+06:00	INFO	[vex] Filtered out the detected vulnerability	format="CSAF" vulnerability-id="CVE-2019-8457" product-id="LIBDB-5328" status="not_affected"
2024-12-24T12:30:11+06:00	INFO	Some vulnerabilities have been ignored/suppressed. Use the "--show-suppressed" flag to display them.

debian:11.8 (debian 11.8)

Total: 153 (UNKNOWN: 1, LOW: 82, MEDIUM: 33, HIGH: 32, CRITICAL: 5)

Anyway i created #8166 to update docs

Regards, Dmitriy

[DmitriyLewen]

#8166 was merged

[lucaskanashiro]

Hi @DmitriyLewen ,

First, thanks for replying to this request and trying to improve the docs, that's appreciated.

However, I'd like to understand, from trivy's perspective, why do you need to rely on the minor version of the Debian release in this case. In Debian, we are trying to implement proper CSAF version 2.0 documents for our security advisories, but testing them with trivy is very difficult because it is very picky regarding the version number. For instance, if we generate a CSAF document for a specific security advisory, and then later a Debian point release happens (increase the minor version, let's say from 11.8 to 11.9), the generated CSAF document does not work anymore. This is not practical since we would need to update all CSAF documents (security advisories) to point to this new point release.

Something interesting to say here, is that a fix that reaches a new Debian point release (minor version) is also available for all the previous minor version. When we increase the minor version a new installer is provided containing all the latest updates, but users can have access to them simply upgrading their system (via terminal for instance), no need to reinstall the system with the new installer.

I am not sure how trivy fetches this data, but it would be really helpful if it could use, for instance, the Debian codename (i.e. Debian 11 == Debian bullseye) or simple the major version (ignore the minor). Then our CSAF documents will work for the whole lifetime of that major release.

Could you please try to elucidate that to us?

TIA!

[DmitriyLewen]

Hello @lucaskanashiro
Thanks for your idea.

This is interest case.
There are no special rules for distro in purl. So we use the information from os-release (or other file).
This was not a problem before, but you are right: VEX package matching can be a problem.

I found an issue with the distro qualifier - package-url/purl-spec#423.
I hope they add some rules for distro, and that will help in this case.
They are planning these changes for August 30th, so I think they will create a PR for these changes soon, and we will start implementing in Trivy.

[santiagorr]

Hello @DmitriyLewen. Thanks for your answer, and sorry for this delayed reply (to @lucaskanashiro's message). Just to be sure, are you waiting for package-url/purl-spec#423 to be addressed first before implementing the change in Trivy?

[DmitriyLewen]

hello @santiagorr

Right. As you can see in the related issues, there is confusion around the versions in the distro qualifier.
If we make changes, it might help some users but break things for others.
That’s why we currently stick to the versions that Trivy already displays in other formats.