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]

@romwol-witt figure out the issue with node sbom... For example imagemagic is retrieving vulnerabilities but imagemagick-6-common is not. When calling trivy directly with sbom the file contains some properties describing the srcName as imagemagic, internally trivy scans imagemagik instead retrieving the same vulnerabilities for imagemagick-6-common. While we dont have the same amount of vulnerabilities I think this is ok because the vulnerabilities will still be there and you wont be able to fix imagemagick-6-common without fixing imagemagick. @nscuro what do you think?

[jimmyjones2]

Having Trivy will be great!

I've tried with the docker-compose.yml above, enabling the trivy analyzer and setting base URL to http://trivy:8080 and API token dummy. The results don't seem quite right and I'm getting the following errors in the log when uploading an SBOM created by trivy (cyclonedx json):

2023-12-31 14:05:03,519 INFO [TrivyAnalysisTask] add package pkg:rpm/redhat/zlib@1.2.7-20.el7_9?arch=x86_64&distro=redhat-7.9
2023-12-31 14:05:03,559 INFO [TrivyAnalysisTask] PutBlob response: 200
2023-12-31 14:05:04,204 INFO [TrivyAnalysisTask] Scan response: 200
2023-12-31 14:05:04,251 INFO [TrivyAnalysisTask] received response from trivy
2023-12-31 14:05:04,251 WARN [TrivyParser] Unable to parse published date 2017-09-06T21:29:00.707Z
2023-12-31 14:05:04,251 WARN [TrivyParser] Unable to parse last modified date 2017-09-13T11:17:22.230Z
2023-12-31 14:05:04,305 INFO [TrivyAnalysisTask] Trivy vulnerability added : CVE-2015-5186 to component audit-libs
2023-12-31 14:05:04,310 WARN [TrivyParser] Unable to parse published date 2019-06-18T18:15:09.247Z
2023-12-31 14:05:04,310 WARN [TrivyParser] Unable to parse last modified date 2023-11-07T02:13:33.410Z
2023-12-31 14:05:04,389 INFO [TrivyAnalysisTask] Trivy vulnerability added : CVE-2012-6711 to component bash

[fnxpt]

The errors are related with the parsing of the dates, I notice that and I will fix it soon, regarding the results what do you think its wrong, did you compare it with trivy. If you provide the sbom file I can also have a look

[fnxpt]

Issue with date parsing fixed on last commit

[jimmyjones2]

Just noticed the links to the trivy CVEs need to be lowercased - otherwise get a 404

[jimmyjones2]

Generated an SBOM for a Red Hat UBI8 image (latest as of today):

trivy image --format cyclonedx --output result.json registry.access.redhat.com/ubi8/ubi:8.9-1028

Standard scan, showing ~183 vulns, as Red Hat rate many as unaffected etc - essentially useless

trivy sbom result.json

Ignore unfixed, which results in 5 CVEs in 2 packages - actionable (wait until Red Hat produce new images, or possibly run dnf update as part of Dockerfile)

trivy sbom result.json --ignore-unfixed

If I create 3 new projects, and upload the result.json created above to each of them, get different results for each. Going into each shows 190 audit vulnerabilities, which isn't helpful. One of the benefits of Trivy is it includes the Red Hat feed, so you can filter (e.g. with --ignore-unfixed) to make the results actionable. Could the Trivy analyzer add support for this please?

[fnxpt]

trivy image registry.access.redhat.com/ubi8/ubi:8.9-1028 returned this

generated and imported sbom into dependency track and I get the same vulnerabilities

Right now we dont have an option to ignore-unfixed, maybe we can add it in the future

[fnxpt]

Just noticed the links to the trivy CVEs need to be lowercased - otherwise get a 404

The problem is not the case, but the link it self, some of the CVEs don't exist on aquasecurity side, but also the format of the link is wrong... Im going to change the PR to change it to nist page instead

[fnxpt]

I ended up implementing it..

[jimmyjones2]

Thanks @fnxpt

I presume this issue of multiple uploads of the same SBOM to different projects showing different number of vulnerabilities is an issue in DependencyTrack and not anything to do with the Trivy scanner?

[fnxpt]

Probably its not an issue at all, but a job that didn't run yet... the jobs are performed in x hours, so probably they were not updated yet

[jimmyjones2]

Sorry, yes I was being too impatient, they all now show the same. Thanks for your work on Trivy, this will make DependencyTrack usable for people using Red Hat container images.

[nscuro]

@fnxpt For example imagemagic is retrieving vulnerabilities but imagemagick-6-common is not. When calling trivy directly with sbom the file contains some properties describing the srcName as imagemagic, internally trivy scans imagemagik instead retrieving the same vulnerabilities for imagemagick-6-common. While we dont have the same amount of vulnerabilities I think this is ok because the vulnerabilities will still be there and you wont be able to fix imagemagick-6-common without fixing imagemagick. @nscuro what do you think?

Yes I think that is fine. If I got this right, it also means that scanning an SBOM with Trivy that was not generated by Trivy, this kind of metadata will also not be there?

Can we forward arbitrary properties to the Trivy API, assuming we have them? I think once #2560 lands, we should be able to simply present the properties ingested from the BOM to Trivy.

[fnxpt]

@fnxpt For example imagemagic is retrieving vulnerabilities but imagemagick-6-common is not. When calling trivy directly with sbom the file contains some properties describing the srcName as imagemagic, internally trivy scans imagemagik instead retrieving the same vulnerabilities for imagemagick-6-common. While we dont have the same amount of vulnerabilities I think this is ok because the vulnerabilities will still be there and you wont be able to fix imagemagick-6-common without fixing imagemagick. @nscuro what do you think?

Yes I think that is fine. If I got this right, it also means that scanning an SBOM with Trivy that was not generated by Trivy, this kind of metadata will also not be there?

Can we forward arbitrary properties to the Trivy API, assuming we have them? I think once #2560 lands, we should be able to simply present the properties ingested from the BOM to Trivy.

Yes if we have the properties on DT we can use them when performing the requests, those properties are filled on the sbom but we don't have any way to access them. If in the future we do we can also import them, but to be honest since you will only need to fix the main library I think its a nice to have. Maybe we can merge this one and create a issue tied to #2560

[nscuro]

but to be honest since you will only need to fix the main library I think its a nice to have. Maybe we can merge this one and create a issue tied to https://github.com/DependencyTrack/dependency-track/issues/2560

Agreed on the nice-to-have point. Yes, let's raise a follow-up issue for that.

[sithmein]

I was just trying this on a Docker image based on Ubuntu. There are several CVEs reported for libc6 and libc-bin when running trivy directly. However, when using an SBOM via DT there are no vulnerabilities for libc being reported. However, I am also getting the date parsing errors mentioned above. Could this be the reason for the missing findings? I can provide more information if required. Is there a rough timeline when this can get integrated? Especially when it comes to OS support trivy will be very useful as OSSIndex doesn't have much data about it.

[nscuro]

@sithmein @fnxpt has made quite a few adjustments and fixes since I last published a container image for it. I'll re-publish one later today. I haven't had a chance yet to review the code, but it's possible your issue has already been addressed.

[sithmein]

OK, looking forward to the new images. However, I believe it's the problem with missing properties discussed above and it's apparently more "severe". Here's what I did:

• Running trivy on the image directly returns the expected findings for libc6 or libc-bin.
• Then I let trivy create an SBOM for this image and immediately ran it again on this SBOM - findings occur as well.
• Then I uploaded the SBOM to DT. No findings for libc* get reported when running through trivy (many others do)
• I exported the SBOM from DT and ran trivy on it - also here no findings for libc*.

You can try it yourself using registry.hub.knime.com/knime/knime-full:r-5.1.2-433 as the image.

[nscuro]

Updated images for API server and frontend have been pushed to Docker Hub.

I believe it's the problem with missing properties discussed above and it's apparently more "severe".

This shortcoming is covered by #3369 already then.

[fnxpt]

@sithmein like @nscuro mentioned that will be fixed on #3369. Internally trivy uses properties of sbom to replace the original name of some libraries, so probably if you go to your sbom you will see that you have libc6 on the properties of libc-bin

[github-actions[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.