Grype missing vulnerability check for cpe:2.3:a :json:json:20200518

[farhan0102]

What happened:
This maybe an issue for Syft and not Grype,
Component: maven:org.json:json
CPE Produced: cpe:2.3:a :json:json:20200518:::::::*"
Actual CPE: cpe:2.3:a :json-java_project:json-java:20200518:::::::*

This may look like two separate packages but it isn’t, we can see in the SBOM it is built by stlea_00 which is linked to this repo. Which is referenced in the CVE, and the recommendation is to upgrade to version 20230227. Json.org does reference multiple json libraries under Java it could be using, but the versioning of what we have suggests that this library is the correct one.
What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

1. downloaded and extracted JDBC Driver from here
2. ran syft /Users/fahmz/Downloads/SimbaJDBCDriverforGoogleBigQuery42_1.3.0.1001 -o json=bom.json
3. ran grype sbom:/Users/fahmz/Downloads/SimbaJDBCDriverforGoogleBigQuery42_1.3.0.1001/bom.json

Anything else we need to know?:

Environment:

• Output of grype version:
  Application: grype
  Version: 0.61.0
  Syft Version: v0.76.0
  BuildDate: 2023-04-04T15:11:17Z
  GitCommit: d8c0c08
  GitDescription: v0.61.0
  Platform: darwin/arm64
  GoVersion: go1.19.7
  Compiler: gc
  Supported DB Schema: 5

• OS (e.g: cat /etc/os-release or similar):
  ProductName: macOS
  ProductVersion: 13.3
  BuildVersion: 22E252

[tgerla]

Hi @farhan0102, thanks for the report. It's our understanding that you are seeing Grype report a false positive for a vulnerability that doesn't actually exist in what you are scanning, because of an incorrect CPE generation, is that correct? Let us know if we are misunderstanding.

[farhan0102]

Not quite, it is not a False Positive; the vulnerability does not show up for the CPE generated which means it's being missed. Actual CPE means the one that should be produced.

[westonsteimel]

I've submitted github/advisory-database#2086 to update the affected packages in GitHub which we'll pull in and match on once they update. CPE-based matching will always be brittle because syft is always essentially guessing what the CPE for a package may be.

[tgerla]

I believe this issue can be closed now that the advisory database has been updated.