--by-cve takes a noticeable amount more time to complete

[kzantow]

Using the --by-cve flag doesn't filter out the duplicates (and also takes 10x as long, from 15s to 2m38s). Both CVE-2020-9547 and GHSA-q93h-jc49-78gg are still in the output and only the GHSA-q93h-jc49-78gg one has a fixed version.

./grype version
Application:          grype
Version:              0.59.1
Syft Version:         v0.74.1
BuildDate:            2023-03-09T14:57:12Z
GitCommit:            29b646568901d1ef48a528cf35f67f3cead49c9f
GitDescription:       v0.59.1
Platform:             linux/amd64
GoVersion:            go1.19.6
Compiler:             gc
Supported DB Schema:  5

Originally posted by @JipSogeti in #236 (comment)

[kzantow]

NOTE: I'm seeing the --by-cve consistently about 4x on my machine using that test image (docker.io/s3curitybug/jackson-databind-cves). After a few runs these are pretty indicative:

grype docker.io/s3curitybug/jackson-databind-cves  3.63s user 3.65s system 51% cpu 14.186 total

grype docker.io/s3curitybug/jackson-databind-cves --by-cve  17.42s user 8.82s system 76% cpu 34.175 total

[ghost]

Thanks @westonsteimel for fixing this so quickly! I can confirm the performance issues are now gone. With or without --by-cve takes about the same time.

I can also confirm the GHSA- IDs are now replaced by the CVE- equivalent.

However, the result is that the CVEs are now shown twice, once with a known fixed version (the one which was previously GHSA-) and once without.

jackson-databind          2.8.8                                           java-archive  CVE-2020-9547     Critical    
[...]    
jackson-databind          2.8.8                2.9.10.4                   java-archive  CVE-2020-9547     Critical 

Shouldn't these results be de-duplicated?

My use case is to block a pipeline when there are known fixes, or vulnerabilities for which the fix state is unknown (in which case the vulnerability needs manual analysis). I want to skip vulnerabilities for which there is no fix (wont-fix, not-fixed). Leaving the duplicate CVE with a fix state of unknown (even though the fix state is known, in the second instance of the same CVE) would cause issues for my use case.

./grype version
Application:          grype
Version:              [not provided]
Syft Version:         v0.75.0
BuildDate:            [not provided]
GitCommit:            [not provided]
GitDescription:       [not provided]
Platform:             linux/amd64
GoVersion:            go1.20.2
Compiler:             gc
Supported DB Schema:  5