What steps did you take and what happened:
In relation to this pull request concerning grouping, I discovered that some VulnerabilityReports lack a Package Path. For example, when I scanned external-dns/external-dns:v0.12.0, there were two instances of CVE-2022-2097—one for resource: libcrypto1.1
- class: os-pkgs
cvss:
ghsa:
V3Score: 7.5
V3Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
nvd:
V2Score: 5
V2Vector: AV:N/AC:L/Au:N/C:P/I:N/A:N
V3Score: 5.3
V3Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
redhat:
V3Score: 5.3
V3Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
description: AES OCB mode for 32-bit x86 platforms using the AES-NI assembly optimised
implementation will not encrypt the entirety of the data under some circumstances.
This could reveal sixteen bytes of data that was preexisting in the memory that
wasn't written. In the special case of "in place" encryption, sixteen bytes
of the plaintext would be revealed. Since OpenSSL does not support OCB based
cipher suites for TLS and DTLS, they are both unaffected. Fixed in OpenSSL 3.0.5
(Affected 3.0.0-3.0.4). Fixed in OpenSSL 1.1.1q (Affected 1.1.1-1.1.1p).
fixedVersion: 1.1.1q-r0
installedVersion: 1.1.1n-r0
lastModifiedDate: "2024-06-21T19:15:23Z"
links: [...]
packageType: alpine
primaryLink: https://avd.aquasec.com/nvd/cve-2022-2097
publishedDate: "2022-07-05T11:15:08Z"
resource: libcrypto1.1
score: 5.3
severity: MEDIUM
target: k8s.gcr.io/external-dns/external-dns:v0.12.0 (alpine 3.15.4)
title: 'openssl: AES OCB fails to encrypt some bytes'
vulnerabilityID: CVE-2022-2097
and one for resource: libssl1.1
- class: os-pkgs
cvss:
ghsa:
V3Score: 7.5
V3Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
nvd:
V2Score: 5
V2Vector: AV:N/AC:L/Au:N/C:P/I:N/A:N
V3Score: 5.3
V3Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
redhat:
V3Score: 5.3
V3Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
description: AES OCB mode for 32-bit x86 platforms using the AES-NI assembly optimised
implementation will not encrypt the entirety of the data under some circumstances.
This could reveal sixteen bytes of data that was preexisting in the memory that
wasn't written. In the special case of "in place" encryption, sixteen bytes
of the plaintext would be revealed. Since OpenSSL does not support OCB based
cipher suites for TLS and DTLS, they are both unaffected. Fixed in OpenSSL 3.0.5
(Affected 3.0.0-3.0.4). Fixed in OpenSSL 1.1.1q (Affected 1.1.1-1.1.1p).
fixedVersion: 1.1.1q-r0
installedVersion: 1.1.1n-r0
lastModifiedDate: "2024-06-21T19:15:23Z"
links: [..]
packageType: alpine
primaryLink: https://avd.aquasec.com/nvd/cve-2022-2097
publishedDate: "2022-07-05T11:15:08Z"
resource: libssl1.1
score: 5.3
severity: MEDIUM
target: k8s.gcr.io/external-dns/external-dns:v0.12.0 (alpine 3.15.4)
title: 'openssl: AES OCB fails to encrypt some bytes'
vulnerabilityID: CVE-2022-2097
From the VulnerabilityReport, both of them lack a Package Path. I'm not sure, but it might be related to this comment.
PkgPath string `json:",omitempty"` // This field is populated in the case of language-specific packages such as egg/wheel and gemspec
This is causing our metrics to be grouped into a single metric, even though they correspond to different resources.
This also causes the metrics between trivy_image_vulnerabilities and trivy_vulnerability_id to not match up.
What did you expect to happen:
I expect these two reports to be separate metrics, not grouped into a single metric, because they have different resource fields.
What steps did you take and what happened: In relation to this pull request concerning grouping, I discovered that some VulnerabilityReports lack a Package Path. For example, when I scanned
external-dns/external-dns:v0.12.0
, there were two instances of CVE-2022-2097—one forresource: libcrypto1.1
and one for
resource: libssl1.1
From the VulnerabilityReport, both of them lack a Package Path. I'm not sure, but it might be related to this comment.
This is causing our metrics to be grouped into a single metric, even though they correspond to different resources.
This also causes the metrics between
trivy_image_vulnerabilities
andtrivy_vulnerability_id
to not match up.What did you expect to happen: I expect these two reports to be separate metrics, not grouped into a single metric, because they have different resource fields.
Anything else you would like to add:
maybe we can include
vuln.Resource
invulnKey
mapEnvironment:
trivy-operator version
): 0.22.0kubectl version
): v1.28.7-gke.1026001