Trivy 0.50.0 not finding CVE-2024-23334, and not finding python virtual envs installed by debian packages

[PenelopeFudd]

IDs

CVE-2024-23334, CVE-2024-23829, CVE-2023-49082, CVE-2023-47641, CVE-2023-47627, CVE-2023-37276, CVE-2022-33124

Description

We've got 11 stale copies of aiohttp, trivy detected 10 of them but did not report them as vulnerable to CVE-2024-23334 or CVE-2024-23829; it did report them as vulnerable to CVE-2023-49081 only. Aqua's own CVE search shows CVE-2024-23334 as HIGH severity: https://avd.aquasec.com/nvd/2024/cve-2024-23334/

The one copy of aiohttp that wasn't detected was in a virtual environment that had been put on the filesystem by installing our application's deb file. This is the most important copy, it's vulnerable (aiohttp-3.7.4.post0), and it seems to be invisible to Trivy.

Reproduction Steps

1. ulimit -n 102400
2. cd /dev/shm
3. nice /usr/local/bin/trivy rootfs --scanners vuln --timeout 60m -s CRITICAL,HIGH --skip-dirs /cache --skip-dirs /repo --skip-dirs /tmp/package-staging --skip-dirs /share1 -f json -o trivy-scan.json /

Target

Filesystem

Scanner

Vulnerability

Target OS

Ubuntu 22.04

Debug Output

The output was more than 64kB, github rejected the submission and erased my answers.  I had to start over.

The only aiohttp-related messages were these 11 messages:

$ grep aiohttp trivy-scan.stderr

2024-03-20T00:09:22.223-0700	INFO	License acquired from METADATA classifiers may be subject to additional terms for [aiohttp:3.7.4.post0]
2024-03-20T00:09:22.313-0700	INFO	License acquired from METADATA classifiers may be subject to additional terms for [aiohttp:3.4.4]
2024-03-20T00:09:22.473-0700	INFO	License acquired from METADATA classifiers may be subject to additional terms for [aiohttp:3.7.4.post0]
2024-03-20T00:09:22.731-0700	INFO	License acquired from METADATA classifiers may be subject to additional terms for [aiohttp:2.3.10]
2024-03-20T00:09:22.883-0700	INFO	License acquired from METADATA classifiers may be subject to additional terms for [aiohttp:3.4.4]
2024-03-20T00:09:23.206-0700	INFO	License acquired from METADATA classifiers may be subject to additional terms for [aiohttp:3.7.4.post0]
2024-03-20T00:09:23.600-0700	INFO	License acquired from METADATA classifiers may be subject to additional terms for [aiohttp:3.4.4]
2024-03-20T00:09:23.745-0700	INFO	License acquired from METADATA classifiers may be subject to additional terms for [aiohttp:2.3.10]
2024-03-20T00:09:23.810-0700	INFO	License acquired from METADATA classifiers may be subject to additional terms for [aiohttp:3.4.4]
2024-03-20T00:09:23.828-0700	INFO	License acquired from METADATA classifiers may be subject to additional terms for [aiohttp:3.4.4]
2024-03-20T00:09:23.970-0700	INFO	License acquired from METADATA classifiers may be subject to additional terms for [aiohttp:3.4.4]

It's very odd that it shows 11 copies of aiohttp here, but the json output only shows 10.

Version

Version: 0.50.0
Vulnerability DB:
  Version: 2
  UpdatedAt: 2024-03-20 06:12:24.2229523 +0000 UTC
  NextUpdate: 2024-03-20 12:12:24.222951939 +0000 UTC
  DownloadedAt: 2024-03-20 07:28:53.003538875 +0000 UTC
Java DB:
  Version: 1
  UpdatedAt: 2024-03-20 00:44:41.182955908 +0000 UTC
  NextUpdate: 2024-03-23 00:44:41.182955728 +0000 UTC
  DownloadedAt: 2024-03-20 07:29:24.06147934 +0000 UTC

Checklist

• Read the documentation regarding wrong detection
• Ran Trivy with -f json that shows data sources and confirmed that the security advisory in data sources was correct

[DmitriyLewen]

Hello @PenelopeFudd
Thanks for your report!

but did not report them as vulnerable to GHSA-5h86-8mv2-jq9f or GHSA-8qpw-xqxj-h4r2

We use database severity (if present) - https://aquasecurity.github.io/trivy/v0.50/docs/scanner/vulnerability/#severity-selection
ghsa in your case.
Therefore, Trivy filters these vulnerability by severity (ghsa marks them as MEDIUM).

installing our application's deb file

For deb files we use OS vendor database - https://aquasecurity.github.io/trivy/v0.50/docs/scanner/vulnerability/#data-source-selection
I think Trivy detects this package, but perhaps name from deb package doesn't match with Debian/Ubuntu database.

You can see all found packages using -f json --list-all-pkgs flags.

Regards, Dmitriy

[PenelopeFudd]

Severity:
I was expecting that once a severity was selected, it would be recorded in Aqua's public-facing database, and Trivy would report that severity. Having a CVE reported as HIGH on the website but MEDIUM in the report is counterintuitive.

Deb files:
We created our own Debian package called backend-sms-master that contains our application and a Python virtual environment. It's a great way to deploy software, but our package is unlikely to show up in the Debian / Ubuntu database. :-)

I'm surprised that Trivy works this way for Debian files, since it has no problem diving into Jar files like the one distributed with logstash.

Thanks for the --list-all-pkgs flag, I'll take a look.

[PenelopeFudd]

Is there a way to have Trivy ignore the dpkg database on the host? I was thinking of ways to getting Trivy to scan the files that were installed by the package. Other approaches might be to copy the directory tree to another path, or renaming the directory tree and symlinking it back to where it was.

[DmitriyLewen]

I was expecting that once a severity was selected, it would be recorded in Aqua's public-facing database, and Trivy would report that severity. Having a CVE reported as HIGH on the website but MEDIUM in the report is counterintuitive.

There are cases when trivy-db contains CVE from multiple databases with different severities.
Therefore, we chose NVD for avd.aquasec.com (url includes nvd to avoid confusing for similar cases (https://avd.aquasec.com/nvd/)).
But Trivy report in json format contains severities from all vendors. Also there is SeveritySource fields:

          "SeveritySource": "ghsa",
          "Severity": "MEDIUM",
          "VendorSeverity": {
            "ghsa": 2,
            "nvd": 3
          },

Is there a way to have Trivy ignore the dpkg database on the host?

We have #4257 for this case.

But currently as workaround you can skip dep status file for your app (/var/lib/dpkg/status or /var/lib/dpkg/status/*) or scan directory of your dep app separately.

[PenelopeFudd]

Ok thanks.

I hope the merge conflicts on #4109 get resolved soon, that's a nice feature.