Open rgarcia89 opened 1 year ago
@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.
@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.
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"
},
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
There is no binary information in the trivy adapter's original report.
please feel free to create a issue in the trivy-adapter project:
Possible duplicate of #16017
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.
@rgarcia89 do you mind opening an issue for this item on trivy-adapter repo
@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 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
@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 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
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
.
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 ofPkgPath
, 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.
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"
}
]
}
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.
Additional context: harbor
command line