GHSA's present but CVE's missing from output

[woodyweaver]

What happened:

I get output like

NAME                            INSTALLED              FIXED-IN              TYPE          VULNERABILITY        SEVERITY 
bcprov-jdk15to18                1.72.0                 1.74                  java-archive  GHSA-hr8g-6v94-x4m9  Medium    
guava                           25.1-android           32.0.0-android        java-archive  GHSA-7g45-4rm6-3mm3  Medium    
guava                           25.1-android           32.0.0-android        java-archive  GHSA-5mg8-w23w-74h3  Low       
jdom                            1.0                                          java-archive  GHSA-2363-cqg2-863c  High      
jdom                            1.1.1.v201101151400                          java-archive  GHSA-2363-cqg2-863c  High      

but no CVE's are listed in report.

What you expected to happen:

The first one, GHSA-hr8g-6v94-x4m9, should also be listed as CVE-2023-33201; if I only get one, I'd rather have the CVE's

How to reproduce it (as minimally and precisely as possible):
Approach is to apply grype to an existing generated via syft: ./syft scan dir:$dir --output syft-json=$key.syft-json followed by grype sbom:syft-json/$key.json --file grype/$key.txt

Anything else we need to know?:
Condition has been existing since at least Nov 2023, but CVE's were present in Sep 2023. No change to how the scans were taken since 2022, but have updated syft/grype regularly.

Environment:

• syft 0.100.0
• grype 0.74.0
• grype executed on Red Hat Enterprise Linux release 8.9 (Ootpa)

[westonsteimel]

Hi, we turned off CPE-based matching in grype by default to reduce the high number of false positive results for the default experience. See https://anchore.com/blog/say-goodbye-to-false-positives/ for more details on that change. If what you want is just to pivot to seeing the CVE id by default rather than the GHSA, then you can pass the --by-cve flag or set the env varGRYPE_BY_CVE=true

If you want to return to doing exhaustive searching based on CPE and are prepared to handle the false positives that will introduce, you can return fully to the previous matching behaviour by setting the following in config or via env vars

match:
  # sets the matchers below to use cpes when trying to find 
  # vulnerability matches. The stock matcher is the default
  # when no primary matcher can be identified.
  java:
    using-cpes: true
  python:
    using-cpes: true
  javascript:
    using-cpes: true
  ruby:
    using-cpes: true
  dotnet:
    using-cpes: true
  golang:
    using-cpes: true
    # even if CPE matching is disabled, make an exception when scanning for "stdlib".
    always-use-cpe-for-stdlib: true
  stock:
    using-cpes: true

[woodyweaver]

Excellent, that is exactly what I was looking for. Sorry I missed it in the docs.

[willmurphyscode]

I'm closing this issue, since I think it's resolved by passing --by-cve, but please let us know if we've missed something.