Dependency Ttrack makes Trivy-generated SBOM unusable to Trivy server about dependency-track HOT 12 CLOSED

Ok I confirm its not working as expected, I will try to debug it later today

from dependency-track.

cc @fnxpt

@sec-p24 Can you please share the version of Trivy you're using? Also sharing the exact SBOM you're uploading could help in reproducing this.

from dependency-track.

My current production setup uses Trivy v0.49.1 to generate SBOM and Trivy v0.51.1 in server mode.
However I tested the same locally with both Trivy's v0.51.1 and the issue remains the same. I am attaching 2 SBOMs - one straight after it was generated with Trivy and the other one downloaded from Dependency Track UI (Download BOM -> Inventory).

After performing few additional tests I have noticed that when I access the Trivy server directly (through Trivy SBOM command, ommiting dtrack) then sometimes it parses the dtrack-proccessed SBOM file correctly, while other times it does not (like 50/50). When I upload the same file through Dependency Track, then it always fails it's assessment.

dt-processed-sbom.json
raw-trivy-sbom.json

from dependency-track.

When I try to run the sbom locally on trivy I get this.

from dependency-track.

Trivy client logs:

$ trivy sbom --server http://localhost:7070 raw-trivy-sbom.json
2024-05-16T16:25:12.145+0200    INFO    Vulnerability scanning is enabled
2024-05-16T16:25:12.147+0200    INFO    Detected SBOM format: cyclonedx-json
2024-05-16T16:25:12.203+0200    WARN    This OS version is no longer supported by the distribution: alpine 3.12.0
2024-05-16T16:25:12.203+0200    WARN    The vulnerability detection may be insufficient because security updates are not provided

Trivy server logs:

$ docker run -p 7070:7070 aquasec/trivy:0.51.1 server --listen 0.0.0.0:7070
2024-05-16T14:25:01Z    INFO    Need to update DB
2024-05-16T14:25:01Z    INFO    Downloading DB...       repository="ghcr.io/aquasecurity/trivy-db:2"
2024-05-16T14:25:08Z    INFO    Listening 0.0.0.0:7070...
2024-05-16T14:25:12Z    INFO    Detected OS     family="alpine" version="3.12.0"
2024-05-16T14:25:12Z    INFO    [alpine] Detecting vulnerabilities...   os_version="3.12" repository="" pkg_num=31
2024-05-16T14:25:12Z    INFO    Number of language-specific files       num=0

from dependency-track.

Generated a new sbom for that image using trivy and it worked

from dependency-track.

When I generated the SBOM for the same image as you did, uploading the file directly to Trivy server yielded different results than when it was uploaded to Dependency Track.

from dependency-track.

Do you see the requests from DT arriving to trivy?
With the image you mentioned yesterday I was able to get some result... not all of them (i will check why)... but Im getting results

from dependency-track.

Few things to clarify.

1. In my initial comment I generated SBOM for php:7.4.10-fpm-alpine docker image, not the trivy image itself.
2. The from Trivy (see last screenshot from my previous message) suggest SBOM arrive correctly there. The same goes for Dependency Track API logs which suggest successful analysis:

2024-05-17 10:08:15,600 INFO [TrivyAnalysisTask] Starting Trivy vulnerability analysis task
2024-05-17 10:08:15,813 INFO [TrivyAnalysisTask] Trivy vulnerability analysis complete

If there is a better way to confirm the arrival, please let me know.
3. Anyway, notice that you are getting results from language-based component only, but not OS-related packages. Looks like the issue might with OS detection on Trivy side when the SBOM is passed from DT.

from dependency-track.

I think I found the issue, just need to do some testing...

from dependency-track.

@sec-p24 Issue fixed, PR is failing due to issues with dependencies
@nscuro any ideia what could be the issue, i saw in the logs that there were a few changes on the dependencies 2 days ago

for the php:7.4.10-fpm-alpine

for the aquasec/trivy:0.51.1

from dependency-track.

@fnxpt The build failures are related to #3726 and the corresponding changes in Alpine. I'll get that PR merged, then your build should pass.

from dependency-track.