False positives in Trivy analyzer ?

dsk-imgw commented 4 months ago

Current Behavior

Trivy analyzer may report false positives (at least about Rocky Linux 9).

Steps to Reproduce

Generate a CycloneDX SBOM file with trivy CLI on Rocky 9.4 PC, where all avaiable updates are applied.
```
trivy rootfs / --format=cyclonedx -o <SBOM file>
```
Upload the SBOM generated in step 1 to Dependency-Track to identify vulnerabiliies. Trivy version is 0.51.2 running on Docker.
Apart from above, run trivy CLI using the SBOM generated in step 1 to identify vulnerabiliies.
```
trivy sbom <SBOM file>
```
Compare the results of step 2 and 3. => The result was … step 2: 77 vulnerabilities (all detected by trivy analyzer), and step 3: 27 vulnerabilties (please see the screenshots below for details).

Results by Dependency Track DT_Detection_Results

Results by trivy CLI Trivy_Detection_Results

Expected Behavior

I think trivy analyzer in Dependency-Track should detect only 27 vulnerabitiles detected by trivy CLI by the following reasons.

27 vulnerabilities (in common with those detected by Dependency-Track) directry detetced by trivy CLI are all about old kernel-* rpms, which co-exist with the patched version rpms, and thus are not false positives.
The rest 50 Vulnerabilities detected only by Dependency-Track are found to be all false positives according to the Rocky's official security advisory.
As the common data (SBOM) and analyzer are used, the results should be the same for Dependency-Track and trivy CLI.

Dependency-Track Version

4.11.1

Dependency-Track Distribution

Container Image

Database Server

PostgreSQL

Database Server Version

10.5

Browser

Google Chrome

Checklist

[X] I have read and understand the contributing guidelines
[X] I have checked the existing issues for whether this defect was already reported

dsk-imgw commented 3 months ago

I inspected HTTP traffic of vulnerability scans between client (both Dependency-Track and Trivy CLI) and Trivy server. I discovered the slight difference of POST data between Dependency-Track and Trivy CLI. More precisely, when POST to /twirp/trivy.cache.v1.Cache/PutBlob,

(a) The value of "version" in "package" dot NOT contain the value of "epoch" and "release".
(b) The key "release" exists in "packages" section.

Please see the example below. If the source code of Dependency-Track could be modified to send the data below 2), this issue might be resolved, but I have not tried to modify the source code of Dependency-Track, since the change impacts could not be estimated precisely (just OK by changing the structure of "Package" class and POST data?).

1) Dependency-Track -> Trivy Server

{
    "diff_id": "sha256:0f4c5915d0608864abfca0081bd1f1b71b6b23a61c90b3dc59b693ea859fb8f0",
    "blob_info": {
        "schema_version": 2,
        "os": {
            "family": "rocky",
            "name": "9.4",
            "eosl": false,
            "extended": false
        },
        "package_infos": [
            {
                "packages": [
                    {
                        ...
                    },
                    {
                        "name": "dbus",
                        "version": "1:1.12.20-8.el9", // <-- %{EPOCH}:%{VERSION}-%{RELEASE} and no "release" key.
                        "arch": "x86_64",
                        "epoch": 1,
                        "src_name": "dbus",
                        "src_version": "1.12.20",
                        "src_epoch": 1,
                        "src_release": "8.el9",
                        "licenses": [],
                        "layer": {
                            "eosl": false,
                            "extended": false
                        }
                    },
                    {
                        ...
                    },
                ]
            }
        ]
    }
}

2) Trivy CLI Client -> Trivy Server (Below is JSON equivalent representation. The actual "Content-Type" is "application/protobuf", not "application/json".)

{
    "diff_id": "sha256:0f4c5915d0608864abfca0081bd1f1b71b6b23a61c90b3dc59b693ea859fb8f0",
    "blob_info": {
        "schema_version": 2,
        "os": {
            "family": "rocky",
            "name": "9.4",
            "eosl": false,
            "extended": false
        },
        "package_infos": [
            {
                "packages": [
                    {
                        ...
                    },
                    {
                        "name": "dbus",
                        "version": "1.12.20", // <-- (a) %{VERSION}
                        "release": "8.el9",   // <-- (b) %{RELEASE}
                        "arch": "x86_64",
                        "epoch": 1,
                        "src_name": "dbus",
                        "src_version": "1.12.20",
                        "src_epoch": 1,
                        "src_release": "8.el9",
                        "licenses": [],
                        "layer": {
                            "eosl": false,
                            "extended": false
                        }
                    },
                    {
                        ...
                    },
                ]
            }
        ]
    }
}

dsk-imgw commented 3 months ago

As for RPM and DEB packages, false positives by Trivy Analyser seems to be resolved by modifying the source code a little.

I modified the source code of 4.11.3. Modified files are 2 files, "main/java/org/dependencytrack/tasks/scanners/TrivyAnalysisTask.java" and "main/java/org/dependencytrack/parser/trivy/model/Package.java". For your reference, the patch file ("dependency-track-4.11.3_trivy_rpm+deb.patch") is attached to the last of this message.

After deploying the modified apiserver JAR file, I re-analysed the project of rpm packages in "Rocky Linux 9.4" which I mentioned in this issue. The result is "27 vulnerabilities detected" (screenshot is below), as I wanted.

Result_by_my_custom_code

Inaddition, I also confirmed the same thing for DEB packages; scan results of deb packages in Ubuntu 22.04 are the same both by Dependency-Track and by Trivy CLI.

dependency-track-4.11.3_trivy_rpm+deb.patch

Thank you.

fnxpt commented 3 months ago

Hey sorry for missing this, I will try to have a look into it today

fnxpt commented 3 months ago

@dsk-imgw do you want to create a PR for this or do you want me to handle it?

dsk-imgw commented 3 months ago

If possible, I would appreciate it if you could handle a PR.

fnxpt commented 3 months ago

Ok, Im a little busy right now, but I will try to create it the next few days

nscuro commented 2 months ago

@dsk-imgw What's the reason for closing this issue? Does the proposed patch not work as expected?

dsk-imgw commented 2 months ago

I closed the issue as "stale" or "inactive" by the following reasons:

No response for a certain period of time.
I thought that leaving issues unresolved for a long time would not be good. (- It seems that no other users are experiencing the same problem as me.)

2024年7月9日(火) 1:54 Niklas @.***>:

@dsk-imgw https://github.com/dsk-imgw What's the reason for closing this issue? Does the proposed patch not work as expected?

— Reply to this email directly, view it on GitHub https://github.com/DependencyTrack/dependency-track/issues/3774#issuecomment-2214689893, or unsubscribe https://github.com/notifications/unsubscribe-auth/AX7E4DA7QLPPN5ZCYXYAZXDZLK73XAVCNFSM6AAAAABIPCTSLWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJUGY4DSOBZGM . You are receiving this because you were mentioned.Message ID: @.***>

github-actions[bot] commented 1 month ago

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.

DependencyTrack / dependency-track