False positives when running a scan from a filesystem or a SBOM

[athiol]

Description

Running trivy on a sbom created on a RedHat 8.4 host gives a lot of false positives

On the host, the sbom was created with
trivy fs --format cyclonedx --output sbom.json /

Then
trivy sbom sbom.json output many vulnerabilities that are fixed in the RH 8.4 versions, indicating that the vulnerability is fixed in a later version.
For example:

─────────────────────────────────────────────────────┤
│ bind-export-libs           │ CVE-2022-38177 │ HIGH     │ 32:9.11.26-4.el8_4.1                      │ 32:9.11.36-3.el8_6.1                      │ bind: memory leak in ECDSA DNSSEC verification code          │
│                            │                │          │                                           │                                           │ https://avd.aquasec.com/nvd/cve-2022-38177                   │
│                            ├────────────────┤          │                                           │                                           ├─────────

But this CVE was fixed in 8.4 by https://access.redhat.com/errata/RHSA-2022:6779 applying amongst others to bind-export-libs-9.11.26-4.el8_4.1.x86_64.rpm

Similarly

─────────────────────────────────────────────────────┤
│ zlib                       │ CVE-2018-25032 │ HIGH     │ 1.2.11-18.el8_4                           │ 1.2.11-18.el8_5                           │ zlib: A flaw found in zlib when compressing (not             │
│                            │                │          │                                           │                                           │ decompressing) certain inputs...                             │
│                            │                │          │                                           │                                           │ https://avd.aquasec.com/nvd/cve-2018-25032                   │
│                            ├────────────────┼──────────┤                                           ├───────────────────────────────────────────┼──────────────────────────────────────────────────────────────┤

This CVE was fixed by https://access.redhat.com/errata/RHSA-2022:4845 applying on zlib-1.2.11-18.el8_4.x86_64.rpm

There are a lot of such false positives which are reported.

Taking a look at the code in redhat.go, my understanding is that in the case of scanning a filesystem (directly or from a sbom), trivy skips the ".4" and considers the RHEL8 repositories (rhel-8-for-x86_64-baseos-rpms and rhel-8-for-x86_64-appstream-rpms), but not the eus repositories that we use.
On the other hand, when scanning an image based on RHEL8.4 created by Red Hat with a /root/buildinfo directory, trivy can use the specified repositories.
After replacing in the code the default RHEL8 repositories with rhel-8-for-x86_64-baseos-eus-rpms__8_DOT_4 and rhel-8-for-x86_64-appstream-eus-rpms__8_DOT_4 for a test, the false positives are no longer returned.

Is there a way to indicate to trivy to use specific repositories when scanning a filesystem or a sbom?

What did you expect to happen?

Only the CVEs that are not fixed in 8.4 are reported by trivy

What happened instead?

False positives

Output of run with -debug:

$ trivy sbom --debug sbom.json > /dev/null
2023-02-08T10:03:31.507+0100    DEBUG   Severities: ["UNKNOWN" "LOW" "MEDIUM" "HIGH" "CRITICAL"]
2023-02-08T10:03:31.511+0100    DEBUG   cache dir:  /home/user/.cache/trivy
2023-02-08T10:03:31.511+0100    DEBUG   DB update was skipped because the local DB is the latest
2023-02-08T10:03:31.511+0100    DEBUG   DB Schema: 2, UpdatedAt: 2023-02-08 06:07:32.058596264 +0000 UTC, NextUpdate: 2023-02-08 12:07:32.058595864 +0000 UTC, DownloadedAt: 2023-02-08 08:45:50.282603684 +0000 UTC
2023-02-08T10:03:31.511+0100    INFO    Vulnerability scanning is enabled
2023-02-08T10:03:31.511+0100    DEBUG   Vulnerability type:  [os library]
2023-02-08T10:03:31.534+0100    INFO    Detected SBOM format: cyclonedx-json
2023-02-08T10:03:31.540+0100    DEBUG   Unmarshaling CycloneDX JSON...
2023-02-08T10:03:31.583+0100    INFO    Detected OS: redhat
2023-02-08T10:03:31.583+0100    INFO    Detecting RHEL/CentOS vulnerabilities...
2023-02-08T10:03:31.583+0100    DEBUG   Red Hat: os version: 8
2023-02-08T10:03:31.583+0100    DEBUG   Red Hat: the number of packages: 603
2023-02-08T10:03:31.735+0100    INFO    Number of language-specific files: 0
2023-02-08T10:03:31.749+0100    WARN    Error while getting vulnerability details: failed to get the vulnerability "CVE-2022-23816": no vulnerability details for CVE-2022-23816
2023-02-08T10:03:31.758+0100    WARN    Error while getting vulnerability details: failed to get the vulnerability "CVE-2022-23816": no vulnerability details for CVE-2022-23816
2023-02-08T10:03:31.767+0100    WARN    Error while getting vulnerability details: failed to get the vulnerability "CVE-2022-23816": no vulnerability details for CVE-2022-23816
2023-02-08T10:03:31.778+0100    WARN    Error while getting vulnerability details: failed to get the vulnerability "CVE-2022-23816": no vulnerability details for CVE-2022-23816
2023-02-08T10:03:31.787+0100    WARN    Error while getting vulnerability details: failed to get the vulnerability "CVE-2022-23816": no vulnerability details for CVE-2022-23816
2023-02-08T10:03:31.795+0100    WARN    Error while getting vulnerability details: failed to get the vulnerability "CVE-2022-23816": no vulnerability details for CVE-2022-23816
2023-02-08T10:03:31.803+0100    WARN    Error while getting vulnerability details: failed to get the vulnerability "CVE-2022-23816": no vulnerability details for CVE-2022-23816
2023-02-08T10:03:31.812+0100    WARN    Error while getting vulnerability details: failed to get the vulnerability "CVE-2022-23816": no vulnerability details for CVE-2022-23816
2023-02-08T10:03:31.819+0100    WARN    Error while getting vulnerability details: failed to get the vulnerability "CVE-2021-20095": no vulnerability details for CVE-2021-20095
2023-02-08T10:03:31.819+0100    WARN    Error while getting vulnerability details: failed to get the vulnerability "CVE-2021-20095": no vulnerability details for CVE-2021-20095
2023-02-08T10:03:31.820+0100    WARN    Error while getting vulnerability details: failed to get the vulnerability "CVE-2021-20095": no vulnerability details for CVE-2021-20095
2023-02-08T10:03:31.827+0100    WARN    Error while getting vulnerability details: failed to get the vulnerability "CVE-2022-23816": no vulnerability details for CVE-2022-23816
...

Note: I don't think that the WARNings are directly related to the reported issue.

Output of trivy -v:

$ trivy -v
Version: 0.36.1
Vulnerability DB:
  Version: 2
  UpdatedAt: 2023-02-08 06:07:32.058596264 +0000 UTC
  NextUpdate: 2023-02-08 12:07:32.058595864 +0000 UTC
  DownloadedAt: 2023-02-08 08:45:50.282603684 +0000 UTC

Additional details (base image name, container registry info...):

[afdesk]

@athiol thanks for the report and sorry for waiting.
could you share an open image (eg.redhat/ubi8:8.4?), which reproduces this issue?