SBOM generated are missing packages

[kovacs-levent]

Description

We are using trivy to generate SBOMs for our images. Unrelated to the issue itself, but for added context, I found this while working on implementing end of life scans using the SBOMs generated by trivy.

When testing the end of life scans, I found that obvious outdated packages are not part of the SBOM. For demonstration purposes, I'll use xeol. When scanning an outdated docker image of python:3.7.17-slim-bullseye, directly scanning the image using xeol detects the following package as part of the image and being EOL:

$ xeol python:3.7.17-slim-bullseye
 ✔ EOL DB                          [no update available]
 ✔ Scanned for EOL                 [1 eol matches]
NAME    VERSION  EOL         DAYS EOL  TYPE
python  3.7.17   2023-06-27  282       binary

This is expected result, but when I first generate the SBOM using trivy, then scanning with the tool I get a different result:

$ trivy image --format spdx-json --output result3.json python:3.7.17-slim-bullseye
2024-04-04T13:02:14.831+0200    INFO    "--format spdx" and "--format spdx-json" disable security scanning

$ xeol sbom:result3.json
 ✔ EOL DB                          [no update available]
 ✔ Scanned for EOL                 [0 eol matches]
[0000]  WARN matcher failed for pkg=Pkg(type=, name=debian, version=11.7, upstreams=0): empty purl
[0000]  WARN matcher failed for pkg=Pkg(type=, name=python-pkg, version=, upstreams=0): empty purl
✅ no EOL software has been found

You can see that there are no EOL software packages detected during this scan... You may notice the warnings, which I suspected that the xeol scanner could be the culprit, so I manually checked the SBOM, and no matter how I tried, but there is no version information detected for any python packages, which is obviously causing the xeol tool to miss the python 3.7.17 EOL finding. There are references to python, but version information is missing. An excerpt from result3.json for example:

    {
      "name": "python-pkg",
      "SPDXID": "SPDXRef-Application-ace32df0b6bdbf7",
      "downloadLocation": "NONE",
      "sourceInfo": "Python",
      "copyrightText": "",
      "primaryPackagePurpose": "APPLICATION"
    },

I searched/looked in the SBOM lots of ways, but there's no version information regarding python 3.7.17, leading me to believe that trivy fails to generate the SBOMs properly, and is missing out on some packages...

Another reasoning I can give is that when generating SBOMs for the same image using syft, I get a much larger SBOM file compared to trivy. Scanning the same image as before:

$ trivy image --format spdx-json --output result-trivy.json python:3.7.17-slim-bullseye
2024-04-04T14:15:35.399+0200    INFO    "--format spdx" and "--format spdx-json" disable security scanning

$ syft scan python:3.7.17-slim-bullseye -o spdx-json --file result-syft.json
Flag --file has been deprecated, use: output
 ✔ Loaded image                                                                        python:3.7.17-slim-bullseye   ✔ Parsed image                            sha256:b5b0a67a91504c733095fdc8785063e5732d19237524be91c600d1608f1c7c99
 ✔ Cataloged contents                             b0b26c530b1d279024df9e9932260b7b185eeb533f2bbc32154ffe32c686c839
   ├── ✔ Packages                        [115 packages]
   ├── ✔ File digests                    [3,196 files]
   ├── ✔ File metadata                   [3,196 locations]                                                             └── ✔ Executables                     [799 executables]

When checking the size, it's evident that the SBOM generated by syft is 15 times larger in the same format (let's disregard the fact that syft also omits indentation in the resulting json, so it "compresses" the SBOM more than trivy does). Leading me to believe that syft catches much more packages as trivy when generating the SBOM.

$ ls -la
total 2572
drwxr-xr-x  2 wisefrog wisefrog    4096 Apr  4 14:15 .
drwxr-x--- 53 wisefrog wisefrog    4096 Apr  4 14:14 ..
-rw-r--r--  1 wisefrog wisefrog 2459195 Apr  4 14:15 result-syft.json
-rw-r--r--  1 wisefrog wisefrog  160331 Apr  4 14:15 result-trivy.json

When manually checking the SBOM of syft, I see that there's a python package with the correct version, this is completely missing from result-trivy.json SBOM (following is an excerpt from result-syft.json):

{
            "name": "python",
            "SPDXID": "SPDXRef-Package-binary-python-c5919fa5c3d7eac3",
            "versionInfo": "3.7.17",
            "supplier": "NOASSERTION",
            "downloadLocation": "NOASSERTION",
            "filesAnalyzed": false,
            "sourceInfo": "acquired package info from the following paths: /usr/local/bin/python3.7, /usr/local/lib/libpython3.7m.so.1.0",
            "licenseConcluded": "NOASSERTION",
            "licenseDeclared": "NOASSERTION",
            "copyrightText": "NOASSERTION",
            "externalRefs": [
                {
                    "referenceCategory": "SECURITY",
                    "referenceType": "cpe23Type",
                    "referenceLocator": "cpe:2.3:a:python_software_foundation:python:3.7.17:*:*:*:*:*:*:*"
                },
                {
                    "referenceCategory": "SECURITY",
                    "referenceType": "cpe23Type",
                    "referenceLocator": "cpe:2.3:a:python:python:3.7.17:*:*:*:*:*:*:*"
                },
                {
                    "referenceCategory": "SECURITY",
                    "referenceType": "cpe23Type",
                    "referenceLocator": "cpe:2.3:a:python:python:3.7.17:*:*:*:*:*:*:*"
                },
                {
                    "referenceCategory": "PACKAGE-MANAGER",
                    "referenceType": "purl",
                    "referenceLocator": "pkg:generic/[email protected]"
                }
            ]
        },

Desired Behavior

That trivy generates the SBOM with sufficient package information to run EOL scans and keeping track of software components (without missing obvious packages, like python). Also that the SBOM sizes will be similar with syft, since it's the same SPDX-json format with both tools.

Actual Behavior

trivy missed the python version, resulting in an obviously missing package in the SBOM. syft manage to generate an SBOM file 15x the size compared to trivy SBOM.

Reproduction Steps

1. trivy image --format spdx-json --output result-trivy.json python:3.7.17-slim-bullseye
2. Try searching for python 3.7.17 version
3. python 3.7.17 version package is not part of the generated SBOM

Target

Container Image

Scanner

None

Output Format

SPDX

Mode

Standalone

Debug Output

$ trivy image --format spdx-json --output result-trivy.json --debug python:3.7.17-slim-bullseye
2024-04-04T14:18:24.876+0200    DEBUG   ["cyclonedx" "spdx" "spdx-json" "github"] automatically enables '--list-all-pkgs'.
2024-04-04T14:18:24.876+0200    DEBUG   Severities: ["UNKNOWN" "LOW" "MEDIUM" "HIGH" "CRITICAL"]
2024-04-04T14:18:24.876+0200    DEBUG   Ignore statuses {"statuses": null}
2024-04-04T14:18:24.876+0200    INFO    "--format spdx" and "--format spdx-json" disable security scanning
2024-04-04T14:18:24.882+0200    DEBUG   cache dir:  /home/wisefrog/.cache/trivy
2024-04-04T14:18:24.882+0200    DEBUG   Enabling misconfiguration scanners: [azure-arm cloudformation dockerfile helm kubernetes terraform terraformplan-json terraformplan-snapshot]
2024-04-04T14:18:24.885+0200    DEBUG   The nuget packages directory couldn't be found. License search disabled
2024-04-04T14:18:24.885+0200    DEBUG   Image ID: sha256:b5b0a67a91504c733095fdc8785063e5732d19237524be91c600d1608f1c7c99
2024-04-04T14:18:24.885+0200    DEBUG   Diff IDs: [sha256:10764c37bcbc8dff79bd134e34e5e8d9c6a3e0d482ca2e6e0ff978485ada5c3c sha256:aa065d85cfdcb9a4b9d3352d119bf1fbe1d8e4d99bfec50b82eb88e5d4ca1576 sha256:ebf2bf60c0964e5bb3750de74d890d41ca38137c1d25b0e9001811afccbb51ab sha256:59c986a304a71121d1264fda1734710390333389e11eba96228f93b71db4eead sha256:85d9ae13b6488cc276ec1ddd60ac5f8e88988caf574fa9a4765588876dc00d10]
2024-04-04T14:18:24.885+0200    DEBUG   Base Layers: [sha256:10764c37bcbc8dff79bd134e34e5e8d9c6a3e0d482ca2e6e0ff978485ada5c3c]

Operating System

Ubuntu 22.04.4 LTS

Version

$ trivy --version
Version: 0.50.1
Vulnerability DB:
  Version: 2
  UpdatedAt: 2024-04-04 06:10:58.040841783 +0000 UTC
  NextUpdate: 2024-04-04 12:10:58.040841502 +0000 UTC
  DownloadedAt: 2024-04-04 11:38:41.799925414 +0000 UTC
Java DB:
  Version: 1
  UpdatedAt: 2024-04-04 00:51:06.207904281 +0000 UTC
  NextUpdate: 2024-04-07 00:51:06.207904121 +0000 UTC
  DownloadedAt: 2024-04-04 10:24:26.047578215 +0000 UTC

Checklist

• Run trivy image --reset
• Read the troubleshooting

[kosztyua]

I can confirm this issue and this goes beyond SBOM generation, python version was not identified at all, not even when going directly to vuln scan instead of first SBOM.

[kovacs-levent]

Most likely the root cause of this issue is part of the docs https://aquasecurity.github.io/trivy/v0.50/docs/scanner/vulnerability/:
"Trivy doesn't support third-party/self-compiled packages/binaries, but official packages provided by vendors such as Red Hat and Debian."

We are thinking of abandoning trivy because of this. Seems that trivy is useless for scanning distroless images, since it won't even detect the main binary which runs on the distroless image...

[DmitriyLewen]

Hello @kovacs-levent

Unfortunately Trivy supports only Go binaries and Rust Binaries built with cargo-auditable - https://aquasecurity.github.io/trivy/v0.50/docs/coverage/language/

python hasn't been installed using apt:

➜ docker run -it --rm python:3.7.17-slim-bullseye apt list --installed | grep python

That is why Trivy can't detect this package.

Regards, Dmitriy

[kovacs-levent]

@DmitriyLewen this is kind of comical, even though I understand the technical limitation, this is just a question of supporting this use-case... We have a distroless image, and trivy is unable to detect the main binary version (which is in the docker tag as well...), making the scan (arguably) completely useless... Syft can detect the package version in these cases, so there must be a way for trivy to add support and detect these binary versions too.

At the very least, for python, php, and other major, widely used interpreters/binaries, this would be crucial I think to minimize this blindspot... Don't you think so?

[DmitriyLewen]

We're trying to make Trivy better every day: adding new supported languages, adding new functionality, etc., but we don't have enough time to do everything.

We are always happy to receive new contributions! If you have time and understanding, it will be very cool if you make a PR with the addition of support for Python binaries.

[kovacs-levent]

There was a PR from 3 years ago which someone started to do for this same reasons and the maintainers just ignored it😅 aquasecurity/go-dep-parser#35 I'm happy to finish it, but it's a bit discouraging that this was already requested years ago and the PR is stuck in review with no resolution in sight.

[DmitriyLewen]

I'm happy to finish it

It will be great!
But keep in mind that we moved the go-dep-parser to Trivy - https://github.com/aquasecurity/trivy/tree/main/pkg/dependency/parser

[kovacs-levent]

#6524 I'd like a review for it please :)

[kovacs-levent]

If anyone is interested in such feature, aquasec explicitly denied my PR since it's supposed to be a "paid feature".

If anyone is actually interested in such feature, feel free to use my fork:
https://github.com/kovacs-levent/trivy/tree/parse-binary-versions