Trivy analyzer support

[fnxpt]

Current Behavior

No support for trivy

Proposed Behavior

Trivy is one of the most performant analysers with really good results. Dependency track should be able to use it and collect its results

Checklist

• [X] I have read and understand the contributing guidelines
• [X] I have checked the existing issues for whether this enhancement was already requested

[fnxpt]

I’m currently working on this and should have it finalised on the next couple of weeks

Update: Frontend part is done, PR already created and linked to this issue. Backend part is 90% done

Besides this I need to:

• [x] Parse errors
• [ ] Do more tests with more projects/project types (probably will need help from someone to have more coverage)
• [x] clean up a little bit of code
• [x] unit tests
• [x] documentation

I think I should be able to have a working version probably monday and I hope I can finish everything by end of next week

[lustr4]

Great, I'm waiting for this useful functionality (support of trivy analyzer).

[nscuro]

Awesome, thanks @fnxpt!

FTR, this is somewhat related to #1677.

[fnxpt]

I saw that issue but didn't want to consider it the same because I'm not building a generic analyzer... the plan for this is to use trivy server and do a similar thing done on snyk

[nscuro]

No worries @fnxpt, that's totally fine. Just wanted to have these linked as the other issue explicitly mentions Trivy support :)

[fnxpt]

Updated first comment with status

[fnxpt]

I created a PR for backend too... there are still some things that are not working as they should.

• Scans on projects that represent docker images are not retrieving OS vulnerabilities
• Scans on web projects are not working... probably due to empty groups

I still need to add tests, but I wanted to share this as soon as possible to receive some feedback since this is my first PR in here. Regarding documentation I added a few things, but to be honest I'm really but in writing documentation, if someone would like to help let me know

[nscuro]

Thanks @fnxpt, this work is much appreciated.

Regarding documentation I added a few things, but to be honest I'm really but in writing documentation, if someone would like to help let me know

Without having looked at it in too much detail, it would be good to have a (high-level) description of how this is supposed to be set up. To most it is not obvious that Trivy has a server mode, or what needs to be done to make it work. If we'd have a step-by-step guide on how to set it up, including commands to launch Trivy, that would be super helpful.

Is there any public documentation on the Trivy API you're using?

[fnxpt]

Ok, I will try to add that information... additionally we can put as an option on the docker-compose, what do you think @nscuro . Regarding the API i couldn't find any documentation I had to check their code. They have 2 types of API. A REST API and a protobuf API.

[fnxpt]

All package managers that trivy supports should be supported now, docker is also supported now. @nscuro - is there any way to generate a snapshot image, I would like to still use the official branch for that but if its not possible I will generate one on my fork. Next steps: Test and compare the results against trivy, just to see if we are missing something... do a little bit of clean up and then add the missing tests.

[nscuro]

@fnxpt I pushed images for your changes here:

dependencytrack/apiserver:3259-trivy-integration
dependencytrack/frontend:656-trivy-integration

[fnxpt]

Thanks @nscuro

So if someone wants to try it my advice is to use the images above + a container running trivy server. After that you just need to enable it on the Admin -> Analysers settings by providing the endpoint + token.

[nscuro]

The following docker-compose.yml can be used for the test setup:

services:
  apiserver:
    image: dependencytrack/apiserver:3259-trivy-integration
    ports:
    - "127.0.0.1:8080:8080"
    volumes:
    - "apiserver-data:/data"
    restart: unless-stopped

  frontend:
    image: dependencytrack/frontend:656-trivy-integration
    environment:
      API_BASE_URL: "http://localhost:8080"
    ports:
    - "127.0.0.1:8081:8080"
    restart: unless-stopped

  trivy:
    image: aquasec/trivy:latest
    command:
    - server
    - --listen
    - 0.0.0.0:8080
    - --token
    - dummy
    restart: unless-stopped

volumes:
  apiserver-data: { }

Trivy should then be configured as follows (token is dummy):

I would also recommend to disable OSS Index for the duration of the test, as OSS Index is invoked prior to Trivy and there may be significant overlap in findings. Disabling OSS Index makes it easier to see how many findings Trivy is able to raise.

[simonfrancaix]

First of all, thank you very much for this feature @fnxpt, which will enable us to track vulnerabilities on our container components too.

I couldn't wait to try out this version of Dependency Track.

After configuring the application to use Trivy as an analyzer. I uploaded a bom in a project. The bom was generated as follows:

trivy image --format cyclonedx --output traefik.json traefik:2.10

I let the application run for over an hour and sent the bom again without any vulnerabilities being linked to the components I added. However, the Trivy scanner does return vulnerabilities for this image.

As mentioned above, I've deactivated the OSS Index to display only the vulnerabilities reported by Trivy.

@nscuro Before I found this new feature I tried to import the bom generated by Trivy with the vulnerabilities. Dependency Track doesn't seem to import vulnerabilities from external scanners. Is this feature included in this ticket #1677 ?

[fnxpt]

@simonfrancaix, can you check the logs from both the api-server and trivy server.... the scan is fast (less than 10s), so problably its a connection issue.

[simonfrancaix]

@fnxpt The logs don't show any connection problems between the api-server and the trivy server. By importing the bom again I managed to obtain vulnerabilities for my components. I import 2 different boms which seems to be the cause of my problem.

For this bom I do have some vulnerabilities that have come up:

trivy image --format cyclonedx --output traefik.json traefik:2.10

For this bom I have no vulnerabilities:

trivy image --format cyclonedx --output docker-bom/quarkus.json registry.access.redhat.com/ubi8/openjdk-17:1.17-1.1696520325

For the second I don't see any trivy analysis triggered by the api-server. The difference between these 2 boms is that the second only has system dependencies. When using Trivy, I expect Dependency Track to report a vulnerability in the curl package of the registry.access.redhat.com/ubi8/openjdk-17:1.17-1.1696520325 image.

[fnxpt]

@simonfrancaix if the connection is established it should have 3 log entries for the 3 endpoints called it should be something like PutBlob 200, Scan 200, DeleteBlob 200.

I got this for the first one

For the second one it seems that its not working.. Im going to have a look

[simonfrancaix]

@fnxpt Yes, I can see in the logs that the trivy scanner is launched when I import components from the traefik image. I also have the vulnerabilities available in dtrack (identified with the trivy scanner).

For the second one (image openjdk 17 ubi8), I don't see any log indicating the launch of the analysis with trivy.

For context, it seems that the components in the traefik image have application packages (go) as well as system packages. The second image, which is missing, only has system packages.

I'm at your disposal if you need me.

[fnxpt]

Theres a bug for the second one, Im working on it. The problem is related to the package manager declared. give me 1h and I should be able to submit a commit

[fnxpt]

341 vulnerabilities detected

[simonfrancaix]

Thanks for the quick response!

FYI by running the trivy analysis directly on the image I find this result:

registry.access.redhat.com/ubi8/openjdk-17:1.17-1.1696520325 (redhat 8.8)
=========================================================================
Total: 141 (UNKNOWN: 0, LOW: 82, MEDIUM: 56, HIGH: 3, CRITICAL: 0)

I'll test again at the end of the day. Don't hesitate to let me know as soon as the 3259-trivy-integration tag is updated.

[fnxpt]

The server is retrieving more vulnerabilities, Im trying to understand why its being excluded example cups-libs

                {
                    "vulnerability_id": "CVE-2019-8696",
                    "pkg_name": "cups-libs",
                    "installed_version": "2.2.6-51.el8_8.2",
                    "fixed_version": "1:2.2.6-33.el8",
                    "title": "cups: stack-buffer-overflow in libcups's asn1_get_packed function",
                    "description": "A buffer overflow issue was addressed with improved memory handling. This issue is fixed in macOS Mojave 10.14.6, Security Update 2019-004 High Sierra, Security Update 2019-004 Sierra. An attacker in a privileged network position may be able to execute arbitrary code.",
                    "severity": "LOW",
                    "references": [
                        "https://access.redhat.com/security/cve/CVE-2019-8696",
                        "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-8696",
                        "https://linux.oracle.com/cve/CVE-2019-8696.html",
                        "https://linux.oracle.com/errata/ELSA-2020-3864.html",
                        "https://nvd.nist.gov/vuln/detail/CVE-2019-8696",
                        "https://support.apple.com/en-us/HT210348",
                        "https://ubuntu.com/security/notices/USN-4105-1",
                        "https://www.cve.org/CVERecord?id=CVE-2019-8696"
                    ],
                    "layer": {
                        "digest": "",
                        "diff_id": "",
                        "created_by": ""
                    },
                    "severity_source": "redhat",
                    "cvss": {
                        "nvd": {
                            "v2_vector": "AV:N/AC:L/Au:S/C:P/I:P/A:P",
                            "v3_vector": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
                            "v2_score": 6.5,
                            "v3_score": 8.8
                        },
                        "redhat": {
                            "v2_vector": "",
                            "v3_vector": "CVSS:3.0/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
                            "v2_score": 0,
                            "v3_score": 3.5
                        }
                    },
                    "cwe_ids": [
                        "CWE-120"
                    ],
                    "primary_url": "https://avd.aquasec.com/nvd/cve-2019-8696",
                    "published_date": "2020-10-27T20:15:00Z",
                    "last_modified_date": "2020-10-30T02:22:00Z",
                    "custom_advisory_data": null,
                    "custom_vuln_data": null,
                    "vendor_ids": [
                        "RHSA-2020:1765"
                    ],
                    "data_source": null,
                    "vendor_severity": {
                        "amazon": "MEDIUM",
                        "nvd": "HIGH",
                        "oracle-oval": "MEDIUM",
                        "redhat": "LOW",
                        "ubuntu": "MEDIUM"
                    },
                    "pkg_path": "",
                    "pkg_id": "",
                    "status": 3
                },
                {
                    "vulnerability_id": "CVE-2020-10001",
                    "pkg_name": "cups-libs",
                    "installed_version": "2.2.6-51.el8_8.2",
                    "fixed_version": "1:2.2.6-40.el8",
                    "title": "cups: access to uninitialized buffer in ipp.c",
                    "description": "An input validation issue was addressed with improved memory handling. This issue is fixed in macOS Big Sur 11.1, Security Update 2020-001 Catalina, Security Update 2020-007 Mojave. A malicious application may be able to read restricted memory.",
                    "severity": "MEDIUM",
                    "references": [
                        "https://access.redhat.com/security/cve/CVE-2020-10001",
                        "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10001",
                        "https://linux.oracle.com/cve/CVE-2020-10001.html",
                        "https://linux.oracle.com/errata/ELSA-2021-4393.html",
                        "https://lists.debian.org/debian-lts-announce/2021/10/msg00027.html",
                        "https://nvd.nist.gov/vuln/detail/CVE-2020-10001",
                        "https://support.apple.com/en-us/HT212011",
                        "https://ubuntu.com/security/notices/USN-5454-1",
                        "https://ubuntu.com/security/notices/USN-5454-2",
                        "https://www.cve.org/CVERecord?id=CVE-2020-10001"
                    ],
                    "layer": {
                        "digest": "",
                        "diff_id": "",
                        "created_by": ""
                    },
                    "severity_source": "redhat",
                    "cvss": {
                        "nvd": {
                            "v2_vector": "AV:N/AC:M/Au:N/C:P/I:N/A:N",
                            "v3_vector": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
                            "v2_score": 4.3,
                            "v3_score": 5.5
                        },
                        "redhat": {
                            "v2_vector": "",
                            "v3_vector": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
                            "v2_score": 0,
                            "v3_score": 5.5
                        }
                    },
                    "cwe_ids": [
                        "CWE-20"
                    ],
                    "primary_url": "https://avd.aquasec.com/nvd/cve-2020-10001",
                    "published_date": "2021-04-02T18:15:00Z",
                    "last_modified_date": "2021-11-30T21:49:00Z",
                    "custom_advisory_data": null,
                    "custom_vuln_data": null,
                    "vendor_ids": [
                        "RHSA-2021:4393"
                    ],
                    "data_source": null,
                    "vendor_severity": {
                        "alma": "MEDIUM",
                        "nvd": "MEDIUM",
                        "oracle-oval": "MEDIUM",
                        "photon": "MEDIUM",
                        "redhat": "MEDIUM",
                        "ubuntu": "LOW"
                    },
                    "pkg_path": "",
                    "pkg_id": "",
                    "status": 3
                },
                {
                    "vulnerability_id": "CVE-2020-3898",
                    "pkg_name": "cups-libs",
                    "installed_version": "2.2.6-51.el8_8.2",
                    "fixed_version": "1:2.2.6-38.el8",
                    "title": "cups: heap based buffer overflow in libcups's ppdFindOption() in ppd-mark.c",
                    "description": "A memory corruption issue was addressed with improved validation. This issue is fixed in macOS Catalina 10.15.4. An application may be able to gain elevated privileges.",
                    "severity": "LOW",
                    "references": [
                        "https://access.redhat.com/security/cve/CVE-2020-3898",
                        "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-3898",
                        "https://linux.oracle.com/cve/CVE-2020-3898.html",
                        "https://linux.oracle.com/errata/ELSA-2020-4469.html",
                        "https://nvd.nist.gov/vuln/detail/CVE-2020-3898",
                        "https://support.apple.com/en-us/HT211100",
                        "https://support.apple.com/kb/HT211100",
                        "https://ubuntu.com/security/notices/USN-4340-1",
                        "https://www.cve.org/CVERecord?id=CVE-2020-3898"
                    ],
                    "layer": {
                        "digest": "",
                        "diff_id": "",
                        "created_by": ""
                    },
                    "severity_source": "redhat",
                    "cvss": {
                        "nvd": {
                            "v2_vector": "AV:L/AC:L/Au:N/C:P/I:P/A:P",
                            "v3_vector": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
                            "v2_score": 4.6,
                            "v3_score": 7.8
                        },
                        "redhat": {
                            "v2_vector": "",
                            "v3_vector": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L",
                            "v2_score": 0,
                            "v3_score": 4.5
                        }
                    },
                    "cwe_ids": [
                        "CWE-20",
                        "CWE-787"
                    ],
                    "primary_url": "https://avd.aquasec.com/nvd/cve-2020-3898",
                    "published_date": "2020-10-22T18:15:00Z",
                    "last_modified_date": "2021-07-21T11:39:00Z",
                    "custom_advisory_data": null,
                    "custom_vuln_data": null,
                    "vendor_ids": [
                        "RHSA-2020:4469"
                    ],
                    "data_source": null,
                    "vendor_severity": {
                        "nvd": "HIGH",
                        "oracle-oval": "LOW",
                        "redhat": "LOW",
                        "ubuntu": "MEDIUM"
                    },
                    "pkg_path": "",
                    "pkg_id": "",
                    "status": 3
                },
                {
                    "vulnerability_id": "CVE-2021-25317",
                    "pkg_name": "cups-libs",
                    "installed_version": "2.2.6-51.el8_8.2",
                    "fixed_version": "",
                    "title": "cups: insecure permissions of /var/log/cups allows for symlink attacks",
                    "description": "A Incorrect Default Permissions vulnerability in the packaging of cups of SUSE Linux Enterprise Server 11-SP4-LTSS, SUSE Manager Server 4.0, SUSE OpenStack Cloud Crowbar 9; openSUSE Leap 15.2, Factory allows local attackers with control of the lp users to create files as root with 0644 permissions without the ability to set the content. This issue affects: SUSE Linux Enterprise Server 11-SP4-LTSS cups versions prior to 1.3.9. SUSE Manager Server 4.0 cups versions prior to 2.2.7. SUSE OpenStack Cloud Crowbar 9 cups versions prior to 1.7.5. openSUSE Leap 15.2 cups versions prior to 2.2.7. openSUSE Factory cups version 2.3.3op2-2.1 and prior versions.",
                    "severity": "LOW",
                    "references": [
                        "https://access.redhat.com/security/cve/CVE-2021-25317",
                        "https://bugzilla.suse.com/show_bug.cgi?id=1184161",
                        "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GWPGZLT3U776Q5YPPSA6LGFWWBDWBVH3/",
                        "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/H74BP746O5NNVCBUTLLZYAFBPESFVECV/",
                        "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S37IDQGHTORQ3Z6VRDQIGBYVOI27YG47/",
                        "https://nvd.nist.gov/vuln/detail/CVE-2021-25317",
                        "https://www.cve.org/CVERecord?id=CVE-2021-25317"
                    ],
                    "layer": {
                        "digest": "",
                        "diff_id": "",
                        "created_by": ""
                    },
                    "severity_source": "redhat",
                    "cvss": {
                        "nvd": {
                            "v2_vector": "AV:L/AC:L/Au:N/C:N/I:P/A:N",
                            "v3_vector": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
                            "v2_score": 2.1,
                            "v3_score": 3.3
                        },
                        "redhat": {
                            "v2_vector": "",
                            "v3_vector": "CVSS:3.1/AV:L/AC:L/PR:H/UI:R/S:U/C:N/I:L/A:N",
                            "v2_score": 0,
                            "v3_score": 2
                        }
                    },
                    "cwe_ids": [
                        "CWE-276"
                    ],
                    "primary_url": "https://avd.aquasec.com/nvd/cve-2021-25317",
                    "published_date": "2021-05-05T10:15:00Z",
                    "last_modified_date": "2023-11-07T03:31:00Z",
                    "custom_advisory_data": null,
                    "custom_vuln_data": null,
                    "vendor_ids": [],
                    "data_source": null,
                    "vendor_severity": {
                        "nvd": "LOW",
                        "redhat": "LOW"
                    },
                    "pkg_path": "",
                    "pkg_id": "",
                    "status": 5
                },
                {
                    "vulnerability_id": "CVE-2022-26691",
                    "pkg_name": "cups-libs",
                    "installed_version": "2.2.6-51.el8_8.2",
                    "fixed_version": "1:2.2.6-45.el8_6.2",
                    "title": "cups: authorization bypass when using \"local\" authorization",
                    "description": "A logic issue was addressed with improved state management. This issue is fixed in Security Update 2022-003 Catalina, macOS Monterey 12.3, macOS Big Sur 11.6.5. An application may be able to gain elevated privileges.",
                    "severity": "HIGH",
                    "references": [
                        "https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2022-26691.json",
                        "https://access.redhat.com/security/cve/CVE-2022-26691",
                        "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-26691",
                        "https://github.com/OpenPrinting/cups/commit/de4f8c196106033e4c372dce3e91b9d42b0b9444",
                        "https://github.com/mandiant/Vulnerability-Disclosures/blob/master/2022/MNDT-2022-0026/MNDT-2022-0026.md",
                        "https://linux.oracle.com/cve/CVE-2022-26691.html",
                        "https://linux.oracle.com/errata/ELSA-2022-5056.html",
                        "https://lists.debian.org/debian-lts-announce/2022/05/msg00039.html",
                        "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/KQ6TD7F3VRITPEHFDHZHK7MU6FEBMZ5U/",
                        "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/YQRIT4H75XV6M42K7ZTARWZ7YLLYQHPO/",
                        "https://nvd.nist.gov/vuln/detail/CVE-2022-26691",
                        "https://openprinting.github.io/cups-2.4.2",
                        "https://support.apple.com/en-in/HT213183",
                        "https://support.apple.com/en-us/HT213183",
                        "https://support.apple.com/en-us/HT213184",
                        "https://support.apple.com/en-us/HT213185",
                        "https://ubuntu.com/security/notices/USN-5454-1",
                        "https://ubuntu.com/security/notices/USN-5454-2",
                        "https://www.cve.org/CVERecord?id=CVE-2022-26691",
                        "https://www.debian.org/security/2022/dsa-5149"
                    ],
                    "layer": {
                        "digest": "",
                        "diff_id": "",
                        "created_by": ""
                    },
                    "severity_source": "redhat",
                    "cvss": {
                        "nvd": {
                            "v2_vector": "AV:L/AC:L/Au:N/C:C/I:C/A:C",
                            "v3_vector": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
                            "v2_score": 7.2,
                            "v3_score": 6.7
                        },
                        "redhat": {
                            "v2_vector": "",
                            "v3_vector": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
                            "v2_score": 0,
                            "v3_score": 6.7
                        }
                    },
                    "cwe_ids": [
                        "CWE-697"
                    ],
                    "primary_url": "https://avd.aquasec.com/nvd/cve-2022-26691",
                    "published_date": "2022-05-26T18:15:00Z",
                    "last_modified_date": "2023-11-07T03:45:00Z",
                    "custom_advisory_data": null,
                    "custom_vuln_data": null,
                    "vendor_ids": [
                        "RHSA-2022:5056"
                    ],
                    "data_source": null,
                    "vendor_severity": {
                        "nvd": "MEDIUM",
                        "oracle-oval": "HIGH",
                        "photon": "MEDIUM",
                        "redhat": "HIGH",
                        "ubuntu": "MEDIUM"
                    },
                    "pkg_path": "",
                    "pkg_id": "",
                    "status": 3
                },
                {
                    "vulnerability_id": "CVE-2023-32324",
                    "pkg_name": "cups-libs",
                    "installed_version": "2.2.6-51.el8_8.2",
                    "fixed_version": "1:2.2.6-54.el8_9",
                    "title": "cups: heap buffer overflow may lead to DoS",
                    "description": "OpenPrinting CUPS is an open source printing system. In versions 2.4.2 and prior, a heap buffer overflow vulnerability would allow a remote attacker to launch a denial of service (DoS) attack. A buffer overflow vulnerability in the function `format_log_line` could allow remote attackers to cause a DoS on the affected system. Exploitation of the vulnerability can be triggered when the configuration file `cupsd.conf` sets the value of `loglevel `to `DEBUG`. No known patches or workarounds exist at time of publication.",
                    "severity": "MEDIUM",
                    "references": [
                        "https://access.redhat.com/errata/RHSA-2023:6596",
                        "https://access.redhat.com/security/cve/CVE-2023-32324",
                        "https://bugzilla.redhat.com/2209603",
                        "https://bugzilla.redhat.com/2214914",
                        "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-32324",
                        "https://errata.almalinux.org/9/ALSA-2023-6596.html",
                        "https://github.com/OpenPrinting/cups/security/advisories/GHSA-cxc6-w2g7-69p7",
                        "https://linux.oracle.com/cve/CVE-2023-32324.html",
                        "https://linux.oracle.com/errata/ELSA-2023-7165.html",
                        "https://lists.debian.org/debian-lts-announce/2023/06/msg00001.html",
                        "https://nvd.nist.gov/vuln/detail/CVE-2023-32324",
                        "https://ubuntu.com/security/notices/USN-6128-1",
                        "https://ubuntu.com/security/notices/USN-6128-2",
                        "https://www.cve.org/CVERecord?id=CVE-2023-32324",
                        "https://www.openwall.com/lists/oss-security/2023/06/01/1"
                    ],
                    "layer": {
                        "digest": "",
                        "diff_id": "",
                        "created_by": ""
                    },
                    "severity_source": "redhat",
                    "cvss": {
                        "nvd": {
                            "v2_vector": "",
                            "v3_vector": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
                            "v2_score": 0,
                            "v3_score": 5.5
                        },
                        "redhat": {
                            "v2_vector": "",
                            "v3_vector": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
                            "v2_score": 0,
                            "v3_score": 5.9
                        }
                    },
                    "cwe_ids": [
                        "CWE-787"
                    ],
                    "primary_url": "https://avd.aquasec.com/nvd/cve-2023-32324",
                    "published_date": "2023-06-01T17:15:00Z",
                    "last_modified_date": "2023-06-08T14:32:00Z",
                    "custom_advisory_data": null,
                    "custom_vuln_data": null,
                    "vendor_ids": [
                        "RHSA-2023:7165"
                    ],
                    "data_source": null,
                    "vendor_severity": {
                        "alma": "MEDIUM",
                        "amazon": "MEDIUM",
                        "nvd": "MEDIUM",
                        "oracle-oval": "MEDIUM",
                        "photon": "MEDIUM",
                        "redhat": "MEDIUM",
                        "ubuntu": "MEDIUM"
                    },
                    "pkg_path": "",
                    "pkg_id": "",
                    "status": 3
                },
                {
                    "vulnerability_id": "CVE-2023-32360",
                    "pkg_name": "cups-libs",
                    "installed_version": "2.2.6-51.el8_8.2",
                    "fixed_version": "1:2.2.6-51.el8_8.1",
                    "title": "cups: Information leak through Cups-Get-Document operation",
                    "description": "An authentication issue was addressed with improved state management. This issue is fixed in macOS Big Sur 11.7.7, macOS Monterey 12.6.6, macOS Ventura 13.4. An unauthenticated user may be able to access recently printed documents.",
                    "severity": "HIGH",
                    "references": [
                        "https://access.redhat.com/errata/RHSA-2023:4838",
                        "https://access.redhat.com/security/cve/CVE-2023-32360",
                        "https://bugzilla.redhat.com/2230495",
                        "https://bugzilla.redhat.com/show_bug.cgi?id=2230495",
                        "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-32360",
                        "https://errata.almalinux.org/9/ALSA-2023-4838.html",
                        "https://errata.rockylinux.org/RLSA-2023:4838",
                        "https://linux.oracle.com/cve/CVE-2023-32360.html",
                        "https://linux.oracle.com/errata/ELSA-2023-4864.html",
                        "https://lists.debian.org/debian-lts-announce/2023/09/msg00041.html",
                        "https://nvd.nist.gov/vuln/detail/CVE-2023-32360",
                        "https://support.apple.com/en-us/HT213758",
                        "https://support.apple.com/en-us/HT213759",
                        "https://support.apple.com/en-us/HT213760",
                        "https://ubuntu.com/security/notices/USN-6361-1",
                        "https://ubuntu.com/security/notices/USN-6361-2",
                        "https://www.cve.org/CVERecord?id=CVE-2023-32360"
                    ],
                    "layer": {
                        "digest": "",
                        "diff_id": "",
                        "created_by": ""
                    },
                    "severity_source": "redhat",
                    "cvss": {
                        "nvd": {
                            "v2_vector": "",
                            "v3_vector": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
                            "v2_score": 0,
                            "v3_score": 5.5
                        },
                        "redhat": {
                            "v2_vector": "",
                            "v3_vector": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
                            "v2_score": 0,
                            "v3_score": 6.5
                        }
                    },
                    "cwe_ids": [],
                    "primary_url": "https://avd.aquasec.com/nvd/cve-2023-32360",
                    "published_date": "2023-06-23T18:15:00Z",
                    "last_modified_date": "2023-09-30T20:15:00Z",
                    "custom_advisory_data": null,
                    "custom_vuln_data": null,
                    "vendor_ids": [
                        "RHSA-2023:4864"
                    ],
                    "data_source": null,
                    "vendor_severity": {
                        "alma": "HIGH",
                        "amazon": "MEDIUM",
                        "nvd": "MEDIUM",
                        "oracle-oval": "HIGH",
                        "redhat": "HIGH",
                        "rocky": "HIGH",
                        "ubuntu": "MEDIUM"
                    },
                    "pkg_path": "",
                    "pkg_id": "",
                    "status": 3
                },
                {
                    "vulnerability_id": "CVE-2023-34241",
                    "pkg_name": "cups-libs",
                    "installed_version": "2.2.6-51.el8_8.2",
                    "fixed_version": "1:2.2.6-54.el8_9",
                    "title": "cups: use-after-free in cupsdAcceptClient() in scheduler/client.c",
                    "description": "OpenPrinting CUPS is a standards-based, open source printing system for Linux and other Unix-like operating systems. Starting in version 2.0.0 and prior to version 2.4.6, CUPS logs data of free memory to the logging service AFTER the connection has been closed, when it should have logged the data right before. This is a use-after-free bug that impacts the entire cupsd process.\n\nThe exact cause of this issue is the function `httpClose(con->http)` being called in `scheduler/client.c`. The problem is that httpClose always, provided its argument is not null, frees the pointer at the end of the call, only for cupsdLogClient to pass the pointer to httpGetHostname. This issue happens in function `cupsdAcceptClient` if LogLevel is warn or higher and in two scenarios: there is a double-lookup for the IP Address (HostNameLookups Double is set in `cupsd.conf`) which fails to resolve, or if CUPS is compiled with TCP wrappers and the connection is refused by rules from `/etc/hosts.allow` and `/etc/hosts.deny`.\n\nVersion 2.4.6 has a patch for this issue.",
                    "severity": "MEDIUM",
                    "references": [
                        "http://www.openwall.com/lists/oss-security/2023/06/23/10",
                        "http://www.openwall.com/lists/oss-security/2023/06/26/1",
                        "https://access.redhat.com/errata/RHSA-2023:6596",
                        "https://access.redhat.com/security/cve/CVE-2023-34241",
                        "https://bugzilla.redhat.com/2209603",
                        "https://bugzilla.redhat.com/2214914",
                        "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-34241",
                        "https://errata.almalinux.org/9/ALSA-2023-6596.html",
                        "https://github.com/OpenPrinting/cups/commit/9809947a959e18409dcf562a3466ef246cb90cb2",
                        "https://github.com/OpenPrinting/cups/releases/tag/v2.4.6",
                        "https://github.com/OpenPrinting/cups/security/advisories/GHSA-qjgh-5hcq-5f25",
                        "https://linux.oracle.com/cve/CVE-2023-34241.html",
                        "https://linux.oracle.com/errata/ELSA-2023-7165.html",
                        "https://lists.debian.org/debian-lts-announce/2023/06/msg00038.html",
                        "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/7I7DWGYGEMBNLZF5UQBMF3SONR37YUBN/",
                        "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/TBIYKDS3UG3W4Z7YOHTR2AWFNBRYPNYY/",
                        "https://nvd.nist.gov/vuln/detail/CVE-2023-34241",
                        "https://support.apple.com/kb/HT213843",
                        "https://support.apple.com/kb/HT213844",
                        "https://support.apple.com/kb/HT213845",
                        "https://ubuntu.com/security/notices/USN-6184-1",
                        "https://ubuntu.com/security/notices/USN-6184-2",
                        "https://www.cve.org/CVERecord?id=CVE-2023-34241"
                    ],
                    "layer": {
                        "digest": "",
                        "diff_id": "",
                        "created_by": ""
                    },
                    "severity_source": "redhat",
                    "cvss": {
                        "nvd": {
                            "v2_vector": "",
                            "v3_vector": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
                            "v2_score": 0,
                            "v3_score": 7.1
                        },
                        "redhat": {
                            "v2_vector": "",
                            "v3_vector": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
                            "v2_score": 0,
                            "v3_score": 7.1
                        }
                    },
                    "cwe_ids": [
                        "CWE-416"
                    ],
                    "primary_url": "https://avd.aquasec.com/nvd/cve-2023-34241",
                    "published_date": "2023-06-22T23:15:00Z",
                    "last_modified_date": "2023-11-17T19:33:00Z",
                    "custom_advisory_data": null,
                    "custom_vuln_data": null,
                    "vendor_ids": [
                        "RHSA-2023:7165"
                    ],
                    "data_source": null,
                    "vendor_severity": {
                        "alma": "MEDIUM",
                        "amazon": "MEDIUM",
                        "nvd": "HIGH",
                        "oracle-oval": "MEDIUM",
                        "photon": "HIGH",
                        "redhat": "MEDIUM",
                        "ubuntu": "MEDIUM"
                    },
                    "pkg_path": "",
                    "pkg_id": "",
                    "status": 3
                },
                {
                    "vulnerability_id": "CVE-2023-4504",
                    "pkg_name": "cups-libs",
                    "installed_version": "2.2.6-51.el8_8.2",
                    "fixed_version": "",
                    "title": "cups, libppd: Postscript Parsing Heap Overflow",
                    "description": "Due to failure in validating the length provided by an attacker-crafted PPD PostScript document, CUPS and libppd are susceptible to a heap-based buffer overflow and possibly code execution. This issue has been fixed in CUPS version 2.4.7, released in September of 2023.\n",
                    "severity": "MEDIUM",
                    "references": [
                        "https://access.redhat.com/security/cve/CVE-2023-4504",
                        "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-4504",
                        "https://github.com/OpenPrinting/cups/releases/tag/v2.4.7",
                        "https://github.com/OpenPrinting/cups/security/advisories/GHSA-pf5r-86w9-678h",
                        "https://github.com/OpenPrinting/libppd/security/advisories/GHSA-4f65-6ph5-qwh6",
                        "https://lists.debian.org/debian-lts-announce/2023/09/msg00041.html",
                        "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/5WHEJIYMMAIXU2EC35MGTB5LGGO2FFJE/",
                        "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/5WVS4I7JG3LISFPKTM6ADKJXXEPEEWBQ/",
                        "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/AMYDKIE4PSJDEMC5OWNFCDMHFGLJ57XG/",
                        "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/PXPVADB56NMLJWG4IZ3OZBNJ2ZOLPQJ6/",
                        "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/T2GSPQAFK2Z6L57TRXEKZDF42K2EVBH7/",
                        "https://nvd.nist.gov/vuln/detail/CVE-2023-4504",
                        "https://takeonme.org/cves/CVE-2023-4504.html",
                        "https://ubuntu.com/security/notices/USN-6391-1",
                        "https://ubuntu.com/security/notices/USN-6391-2",
                        "https://ubuntu.com/security/notices/USN-6392-1",
                        "https://www.cve.org/CVERecord?id=CVE-2023-4504"
                    ],
                    "layer": {
                        "digest": "",
                        "diff_id": "",
                        "created_by": ""
                    },
                    "severity_source": "redhat",
                    "cvss": {
                        "nvd": {
                            "v2_vector": "",
                            "v3_vector": "CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H",
                            "v2_score": 0,
                            "v3_score": 7
                        },
                        "redhat": {
                            "v2_vector": "",
                            "v3_vector": "CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H",
                            "v2_score": 0,
                            "v3_score": 7
                        }
                    },
                    "cwe_ids": [
                        "CWE-787"
                    ],
                    "primary_url": "https://avd.aquasec.com/nvd/cve-2023-4504",
                    "published_date": "2023-09-21T23:15:00Z",
                    "last_modified_date": "2023-11-09T20:58:00Z",
                    "custom_advisory_data": null,
                    "custom_vuln_data": null,
                    "vendor_ids": [],
                    "data_source": null,
                    "vendor_severity": {
                        "amazon": "MEDIUM",
                        "nvd": "HIGH",
                        "photon": "HIGH",
                        "redhat": "MEDIUM",
                        "ubuntu": "MEDIUM"
                    },
                    "pkg_path": "",
                    "pkg_id": "",
                    "status": 5
                },

[simonfrancaix]

If I inspect the result of trivy in CLI I find these vulnerabilities for cups-libs:

Is it possible that trivy's database is different in server mode than in CLI?

[fnxpt]

No it's something else, I'm trying to validate what's the problem

[fnxpt]

Sorry for the delay, there were 3 issues. 1- isCapable was returning false when purl was not filled or with a missing package type 2- Arch was hardcoded 3- Epoch was not filled (this was the main issue for the additional vulnerabilities)

[nscuro]

@fnxpt I pushed an updated image built against 62528bbfd85c2b80eb56f80569e9b77c10fd4b33 to Docker Hub.

[simonfrancaix]

No problem, I'm just a simple user eager to use this feature. I was just cloning your work to see what I could bring to it. I'll test it tomorrow with different projects. Thanks a lot.

[simonfrancaix]

Sorry for the delay, it's been a busy day.

The various modifications have corrected the problem, thank you again for your responsiveness.

For test I used a bom generated as follows:

trivy image --format cyclonedx --output ubi.json registry.access.redhat.com/ubi8/openjdk-17:1.17-1.1696520325

Dependency Track analysis results:

In Dependency Track, we detect an additional vulnerability, unlike in Trivy CLI.

The additional vulnerability concerns this component:

Nor does it appear to count against the vulnerability counter in the top right-hand corner. This problem is certainly not related to your feature.

I also carried out a second test. For some of our projects we try to provide a single bom to Dependency Track to provide an overview for a project. It's certainly not ideal, but I haven't found a better solution for the moment for aggregating the various vulnerabilities of a project.

To keep things simple, I simply merged two boms representing two containers to evaluate this feature. It seems that only the first container detected is considered by the analysis.

trivy image --format cyclonedx --output traefik.json traefik:2.10
trivy image --format cyclonedx --output ubi.json registry.access.redhat.com/ubi8/openjdk-17:1.17-1.1696520325
cyclonedx-cli merge --input-files ubi.json traefik.json --output-file bom.json --name my-app --version latest --hierarchical

If I run a new scan using the "Reanalyze" button in the audit vulnerabilities menu, I find all the vulnerabilities (144 for ubi and 5 for traefik).

The logs show that this time it was the other image that was analyzed.

BTW Your development of the trivy analyzer is even better than trivy CLI itself - impressive! Let me tell you why. If I run a scan on the shared bom with trivy, it doesn't find any vulnerabilities.

Sorry for the long comment, I hope my tests help you implement this great feature. I'm going to continue integrating the feature with different projects to try and provide as much coverage as possible.

[fnxpt]

Thanks for the feedback regarding the additional vulnerability I will need to have a look. Regading the better results, it might be because trivy cli doesnt expect merged sboms, since we are doing it on our end to we also included it... I just need to double check the final package because maybe we are combining the packages into the wrong OS. I will check these 2 things, if you have anything extra to validate let me know

[romwol-witt]

Hi! First of all, seems to be great work 👍 But i cannot see at the logs that the TrivyAnalyzer is started... Any idea how to debug? I have a trivy-operator in Server-Mode running at my cluster and configured it in DT...

[fnxpt]

@romwol-witt you should be able to see a Starting Trivy vulnerability analysis task message in the logs. Also when the requests are made to the server you should see some PutBlob/Scan/DeleteBlob messages. Best way to validate it is to force a scan in one of the projects or add a new SBOM to a project.

[romwol-witt]

@fnxpt Ok, many thanks :) Now its working... But if i compare the results with the results from trivy operator, there is a HUGE gap regarding the amount of vulnerabilities :( Any idea why? Or is there a better approach than using trivy operator to generate the sbom's ? I have a test container mit NodeJS and there are 0 findings... and we all know that cannot be the truth regarding NodeJS :)

[fnxpt]

Can you share your findings… I’m trying to identify issues.Sent from my iPhoneOn 12 Dec 2023, at 08:26, romwol-witt @.***> wrote: Ok, many thanks. Now its working... But if i compare the results with the results from trivy operator, there is a HUGE gap regarding the amount of vulnerabilities :( Any idea why?

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

[fnxpt]

Can you share your findings I'm trying to fix this type of issues

[romwol-witt]

Oh, i see there is a problem in the log... hm...

2023-12-12 08:20:29,498 ERROR [TrivyAnalysisTask] Request failure org.apache.http.conn.ConnectionPoolTimeoutException: Timeout waiting for connection from pool

---

There are findings for other projects, but there not as much as in trivy as well. Here are the screenshots of the difference:

Trivy Operator:

Dtrack:

[fnxpt]

That's weird, can you check the logs from trivy server. Can you share the sbom, this way I can validate on my side too.

[romwol-witt]

nothing in the logs... here the exported sbom from trivy... node-sbom.json

[romwol-witt]

now i have findings for node?!?! But why?! ^^ But still not the same as trivy operator. i cannot use the frontend at the moment because the apiserver doing a lot of stuff and is not responding to the frontend. i'll keep you updated if i can reach the frontend again

[fnxpt]

The sbom you sent is not retrieving any components to dependency track so its not able to be processed

[romwol-witt]

I have a script that extracts the component part and that i am uploading to DT... Like this: librarynode_bom.json

[fnxpt]

I see results, for that sbom, but for sure something is missing I will need to debug it again

[romwol-witt]

I've tried https://github.com/ckotzbauer/sbom-operator as well and there i get more/different results than from trivy ^^

[fnxpt]

So the goal is to have the same results on dependency track as if you were running trivy tool directly, from the previous sbom you sent there is clearly some differences, I will need to understand why

[romwol-witt]

if i can help in any way, just let me know! I would prefer the trivy way also

[romwol-witt]

Btw, how do you get the sbom's to dependency track? i am using a bash script currently, but this is far away from optimal...

[simonfrancaix]

@romwol-witt I don't think this ticket is the right place to expand on automating sbom publishing in Dependency Track. Quite simply, I think automation (CI/CD) is the key. For example, we run a pipeline for each project, generating the SBOM and publishing it to Dependency Track. This pipeline runs automatically every day from the main development branch, providing our developers with the dependency status every day. We don't currently use Kubernetes to orchestrate our containers, but it's certainly simple enough to run a kubernetes job periodically to update your project's sbom. This job should retrieve the sbom generated by trivy-operator and then upload it to Dependency Track.

@fnxpt I'll continue to integrate the feature with more complex projects and also look at its integration with other scanners. Let me know if I can assist you in solving the sbom merge analysis.

[fnxpt]

@romwol-witt you can join slack channel and discuss this questions in there I will gladly give some hints

@simonfrancaix right now Im trying to identify the existing issues... one way to help is to provide sboms where the outcome is different from running trivy cli

[simonfrancaix]

@fnxpt here's a bom that returns a different result ubi.json

Component: pkg:rpm/redhat/guava@31.0.1-4.module%2Bel8.8.0%2B18044%2B0a924b8f?arch=noarch&distro=redhat-8.8&modularitylabel=maven%3A3.8%3A8080020230202141436%3A1e199b36

Vulnerability: CVE-2023-2976

---

I left this version of dependency track running in order to visualize the appearance of new vulnerabilities for a project. Example:

This new vulnerability is also present in the new analysis of trivy-cli

[romwol-witt]

@simonfrancaix Sorry, you're completely right. I just wanted to know how you guy get the trivy-sboms to dependency track. But i will join the slack channel for this...

[fnxpt]

@simonfrancaix executed it locally and got the same amount of vulnerabilities.. maybe its because of the latests changes I did (still not commited)