Trivy Scan Report missing out files the respective vulnerabilities were found

[rgarcia89]

Expected behavior and actual behavior: When I look at a Trivy Scan Report in Harbor, I cannot see in which files the respective vulnerabilities were found. This looks different with a local scan.

Steps to reproduce the problem: Scan an image in Harbor and check the trivy report on Harbor vs when running trivy directly on your command line.

Versions: Please specify the versions of following systems.

• harbor version: 2.8.0
• containerd://1.6.18

Additional context: harbor

command line

[zyyw]

@rgarcia89 , could you please elaborate this sentence: I cannot see in which files the respective vulnerabilities were found. Not quite understand your question.

The vulnerabilities along with their information are listed in the grid in harbor as you attached above. The vulnerabilities are the scan results against a specific image/artifact, which include CVE ID, Serverity, and Package/Library that causes the CVE. These information should be consistent between Harbor trivy scan and scanning via Trivy CLI.

[rgarcia89]

@zyyw you should see the difference comparing the two attached screenshots.

Here for example you can see that a vulnerability has been found in a library of /usr/bin/terraform

This is not visible in harbor. There you can only see the libraries including vulnerabilities but not the binaries to which them belong.

[stonezdj]

From the original trivy report, there is a layer attribute, maybe we could add it to the vulnerability_record

      "layer": {
        "digest": "sha256:c0f451e89402529041da71904cfbe9d12d39237f5fb5f3f255a851d109579d74",
        "diff_id": "sha256:232d93e4ab7cd94fb5a5455b5bb5b602e03812d6c5d997e3ffc25812acb97f72"
      },

[rgarcia89]

I don't think it is about the image layer. I could install multiple binaries within a layer command. This still would not tell me in which binary the vulnerability has been found

[stonezdj]

There is no binary information in the trivy adapter's original report.

[zyyw]

please feel free to create a issue in the trivy-adapter project:

• https://github.com/aquasecurity/harbor-scanner-trivy

[bianjp]

Possible duplicate of #16017

[bianjp]

It seems that Target, Class, Type, PkgPath are all necessary to identify which file caused the vulnerability. See the following snippet of a Trivy report in JSON format:

{
  "Results": [
    {
      "Target": "goharbor/harbor-core:v2.1.0 (photon 2.0)",
      "Class": "os-pkgs",
      "Type": "photon",
      "Vulnerabilities": [
        {
          "VulnerabilityID": "CVE-2021-22945",
          "PkgID": "curl@7.59.0-11.ph2.x86_64",
          "PkgName": "curl",
          "InstalledVersion": "7.59.0-11.ph2",
          "FixedVersion": "7.78.0-2.ph2"
        }
      ]
    },
    {
      "Target": "harbor/harbor_core", // file path
      "Class": "lang-pkgs",
      "Type": "gobinary",
      "Vulnerabilities": [
        {
          "VulnerabilityID": "CVE-2019-16354",
          "PkgName": "github.com/astaxie/beego",
          "InstalledVersion": "v1.12.1",
          "FixedVersion": "1.12.2"
        }
      ]
    },
    {
      "Target": "Java",
      "Class": "lang-pkgs",
      "Type": "jar",
      "Vulnerabilities": [
        {
          "VulnerabilityID": "CVE-2022-25845",
          "PkgName": "com.alibaba:fastjson",
          "PkgPath": "app/app.jar/BOOT-INF/lib/ons-client-1.8.0.Final.jar", // file path
          "InstalledVersion": "1.2.50",
          "FixedVersion": "1.2.83"
        }
      ]
    }
  ]
}

@zyyw @stonezdj Can you add these fields to the vulnerability data structure in Harbor? As for harbor-scanner-trivy I might be able to make a pull request to return these fields.

[chen-keinan]

@rgarcia89 do you mind opening an issue for this item on trivy-adapter repo

[rgarcia89]

@chen-keinan I already did like you can see 3 messages above

although as @bianjp mentioned it seems that the information are already available via the PkgPath value which unfortunately does not seem to be used by harbor?

[chen-keinan]

@chen-keinan I already did like you can see 3 messages above

although as @bianjp mentioned it seems that the information are already available via the PkgPath value which unfortunately does not seem to be used by harbor?

@rgarcia89 missed it probably. great you can pick it up and raise a PR if you have a time

[bianjp]

@chen-keinan Merely updating harbor-scanner-trivy to return additional information is not enough, as harbor cannot recognize these additional infomation and will not show them to users. Harbor has to modify its vulnerability data structure first.

Since Harbor not only supports trivy but also clair as vulnerability scanner, maybe the clair adapter should also be updated to keep consistent with trivy.

[chen-keinan]

@chen-keinan Merely updating harbor-scanner-trivy to return additional information is not enough, as harbor cannot recognize these additional infomation and will not show them to users. Harbor has to modify its vulnerability data structure first.

Since Harbor not only supports trivy but also clair as vulnerability scanner, maybe the clair adapter should also be updated to keep consistent with trivy.

I'm not sure if adding this additional fields by harbor-scanner-trivy only will break harbor or just be ignored. can anyone confirm ? by the answer we can know if work can be done independently

[zyyw]

To display this PkgPath info on Harbor, it requires changes to Harbor code (UI: displaying a new column called PkgPath maybe, backend including code here and updating database table schema) and also code change on harbor-scanner-trivy to supply the data of PkgPath, related code might be here.

Instead of making this ad-hoc changes, the best practice may need to update pluggable-scanner-spec first. We can add this requirement to the queue before rolling out the next version of pluggable-scanner-spec.

[bianjp]

To display this PkgPath info on Harbor, it requires changes to Harbor code (UI: displaying a new column called PkgPath maybe, backend including code here and updating database table schema) and also code change on harbor-scanner-trivy to supply the data of PkgPath, related code might be here.

Instead of making this ad-hoc changes, the best practice may need to update pluggable-scanner-spec first. We can add this requirement to the queue before rolling out the next version of pluggable-scanner-spec.

Be aware that PkgPath is not enough to identify all vulnerabilities, see my above comment for example.

[rgarcia89]

As far as I understand it, we are currently only iterating over the vulnerabilities and not paying attention to the binary they belong to. However, as we can see in the json above, they belong to a 'Target' with a 'Type'. Which in my opinion, are the missing fields here.

trivy-cli scan results:

harbor trivy scan results:

trivy-cli scan results in json format

    {
      "Target": "usr/bin/helm",
      "Type": "gobinary",
      "Vulnerabilities": [
        {
          "VulnerabilityID": "GHSA-7ww5-4wqc-m92c",
          "PkgName": "github.com/containerd/containerd",
          "InstalledVersion": "v1.7.6",
          "FixedVersion": "1.6.26, 1.7.11",
          "Status": "fixed",
          "Title": "containerd allows RAPL to be accessible to a container",
          "Severity": "MEDIUM"
        },
        {
          "VulnerabilityID": "GHSA-jq35-85cj-fj4p",
          "PkgName": "github.com/docker/docker",
          "InstalledVersion": "v24.0.6+incompatible",
          "FixedVersion": "24.0.7, 23.0.8, 20.10.27",
          "Status": "fixed",
          "Title": "/sys/devices/virtual/powercap accessible by default to containers",
          "Severity": "MEDIUM"
        },
        {
          "VulnerabilityID": "CVE-2023-48795",
          "PkgName": "golang.org/x/crypto",
          "InstalledVersion": "v0.13.0",
          "FixedVersion": "0.17.0",
          "Status": "fixed",
          "Title": "ssh: Prefix truncation attack on Binary Packet Protocol (BPP)",
          "Severity": "MEDIUM"
        },
        {
          "VulnerabilityID": "CVE-2023-39325",
          "PkgName": "golang.org/x/net",
          "InstalledVersion": "v0.13.0",
          "FixedVersion": "0.17.0",
          "Status": "fixed",
          "Title": "golang: net/http, x/net/http2: rapid stream resets can cause excessive work (CVE-2023-44487)",
          "Description": "A malicious HTTP/2 client which rapidly creates requests and immediately resets them can cause excessive server resource consumption. While the total number of requests is bounded by the http2.Server.MaxConcurrentStreams setting, resetting an in-progress request allows the attacker to create a new request while the existing one is still executing. With the fix applied, HTTP/2 servers now bound the number of simultaneously executing handler goroutines to the stream concurrency limit (MaxConcurrentStreams). New requests arriving when at the limit (which can only happen after the client has reset an existing, in-flight request) will be queued until a handler exits. If the request queue grows too large, the server will terminate the connection. This issue is also fixed in golang.org/x/net/http2 for users manually configuring HTTP/2. The default stream concurrency limit is 250 streams (requests) per HTTP/2 connection. This value may be adjusted using the golang.org/x/net/http2 package; see the Server.MaxConcurrentStreams setting and the ConfigureServer function.",
          "Severity": "HIGH"
        },
        {
          "VulnerabilityID": "CVE-2023-44487",
          "PkgName": "golang.org/x/net",
          "InstalledVersion": "v0.13.0",
          "FixedVersion": "0.17.0",
          "Status": "fixed",
          "Title": "HTTP/2: Multiple HTTP/2 enabled web servers are vulnerable to a DDoS attack (Rapid Reset Attack)",
          "Severity": "MEDIUM"
        },
        {
          "VulnerabilityID": "GHSA-m425-mq94-257g",
          "PkgName": "google.golang.org/grpc",
          "InstalledVersion": "v1.54.0",
          "FixedVersion": "1.56.3, 1.57.1, 1.58.3",
          "Status": "fixed",
          "Title": "gRPC-Go HTTP/2 Rapid Reset vulnerability",
          "Severity": "HIGH"
        }
      ]
    }