Open dwertent opened 7 months ago
Hi @dwertent, thank you for the detailed report. We do have some circumstances where the summary count won't line up with the default table view output, specifically when there are duplicate rows in the table referring to the same vulnerability against the same package but installed in different places on your system. The JSON output should be correct relative to the the summary counts, but we agree that this is confusing.
Here is a similar issue with our proposed fix: annotate de-duplicated rows in the table output with something like (2) to indicate that a vulnerability has a duplicate: https://github.com/anchore/grype/issues/1327
We need to do some more investigation to make sure that our explanation is correct, we'll add this issue to our backlog to look at when we are able. Thanks again!
I quick check looking at the JSON output too shows that there is a count issue still:
$ grype quay.io/tigera/cc-operator@sha256:d6451279b74c73a669d2901c321d386163f09fdc3cccabaf4d34b2ad065ea6c6 --by-cve -o json | jq '.matches[] | select(.vulnerability.severity == "Medium") | .vulnerability.id ' | wc -l
✔ Vulnerability DB [no update available]
✔ Loaded image quay.io/tigera/cc-operator@sha256:d6451279b74c73a669d2901c321d386163f09fdc3cccabaf4d34b2ad065ea6c6
✔ Parsed image sha256:b747f07011a2c82631683d826b2275a6fcfbe6dfb5c26ac48d69446767cd7511
✔ Scanned for vulnerabilities [30 vulnerability matches]
├── by severity: 1 critical, 18 high, 11 medium, 0 low, 0 negligible
└── by status: 9 fixed, 21 not-fixed, 0 ignored
...
8
For this image at this time, here are all of the matches with a severity of medium (13)
GHSA-qppj-fm5r-hxr3 golang.org/x/net@v0.13.0
GHSA-qppj-fm5r-hxr3 golang.org/x/net@v0.14.0
GHSA-qppj-fm5r-hxr3 golang.org/x/net@v0.14.0
GHSA-8r3f-844c-mc37 google.golang.org/protobuf@v1.30.0
GHSA-8r3f-844c-mc37 google.golang.org/protobuf@v1.31.0
CVE-2023-39318 stdlib@go1.20.7
CVE-2023-39319 stdlib@go1.20.7
CVE-2023-39326 stdlib@go1.20.7
CVE-2023-45284 stdlib@go1.20.7
CVE-2023-39318 stdlib@go1.21.0
CVE-2023-39319 stdlib@go1.21.0
CVE-2023-39326 stdlib@go1.21.0
CVE-2023-45284 stdlib@go1.21.0
Taking a look at the non-stdlib matches, when not using --by-cve you'll see:
NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY
golang.org/x/net v0.13.0 0.17.0 go-module GHSA-4374-p667-p6c8 High
golang.org/x/net v0.13.0 0.17.0 go-module GHSA-qppj-fm5r-hxr3 Medium
golang.org/x/net v0.14.0 0.17.0 go-module GHSA-4374-p667-p6c8 High
golang.org/x/net v0.14.0 0.17.0 go-module GHSA-qppj-fm5r-hxr3 Medium
google.golang.org/protobuf v1.30.0 1.33.0 go-module GHSA-8r3f-844c-mc37 Medium
google.golang.org/protobuf v1.31.0 1.33.0 go-module GHSA-8r3f-844c-mc37 Medium
k8s.io/kubernetes v1.28.0 1.28.1 go-module GHSA-q78c-gwqw-jcmc High
k8s.io/kubernetes v1.28.0 1.28.4 go-module GHSA-hq6q-c2x6-hmch High
k8s.io/kubernetes v1.28.0 1.28.1 go-module GHSA-7fxm-f474-hf8w High
But with --by-cve you'll see:
golang.org/x/net v0.13.0 0.17.0 go-module CVE-2023-44487 High
golang.org/x/net v0.13.0 0.17.0 go-module CVE-2023-39325 High
golang.org/x/net v0.14.0 0.17.0 go-module CVE-2023-44487 High
golang.org/x/net v0.14.0 0.17.0 go-module CVE-2023-39325 High
google.golang.org/protobuf v1.30.0 1.33.0 go-module CVE-2024-24786 Unknown
google.golang.org/protobuf v1.31.0 1.33.0 go-module CVE-2024-24786 Unknown
k8s.io/kubernetes v1.28.0 1.28.4 go-module CVE-2023-5528 High
k8s.io/kubernetes v1.28.0 1.28.1 go-module CVE-2023-3955 High
k8s.io/kubernetes v1.28.0 1.28.1 go-module CVE-2023-3676 High
Note that the severities are different for the CVEs than the GHSA's for the same matches.
This is mostly due to the way we are implementing --by-cve
, which I think will need to be heavily changed. Today this is a presentation concern... we make no changes to the matching process but instead after the matching is done transform non-CVEs to CVEs (if possible) and coalesce the set of transformed matches. I think this is where most of the issue is occuring.
However, there is still one more issue: we search for matches without looking for duplicate packages first:
[0000] TRACE searching for vulnerability matches package=pkg:golang/golang.org/x/net@v0.14.0
[0000] DEBUG found 2 vulnerabilities package=pkg:golang/golang.org/x/net@v0.14.0
[0000] DEBUG ├── namespace=github:language:go vuln=GHSA-4374-p667-p6c8
[0000] DEBUG └── namespace=github:language:go vuln=GHSA-qppj-fm5r-hxr3
[0000] TRACE searching for vulnerability matches package=pkg:golang/golang.org/x/net@v0.14.0
[0000] DEBUG found 2 vulnerabilities package=pkg:golang/golang.org/x/net@v0.14.0
[0000] DEBUG ├── namespace=github:language:go vuln=GHSA-4374-p667-p6c8
[0000] DEBUG └── namespace=github:language:go vuln=GHSA-qppj-fm5r-hxr3
This is a debug log snippet showing the back-to-back (duplicate) lookup. This hints at either:
What happened: I sanned the following:
Here is the list of vulnerabilities:
As you can tell, there are 19 High and 8 Medium, not 18 high, and 11 medium as it says in the summary.
What you expected to happen: The numbers should add up.
How to reproduce it (as minimally and precisely as possible): Run the following:
Anything else we need to know?:
Full output:
And here are the results without the
--by-cve
flag:As you can tell, also here the summary does not add up.
Environment:
Output of
grype version
:OS (e.g:
cat /etc/os-release
or similar):macos M1