Weston Steimel

Actually this is going to be difficult since the advisory database is only going to have version tags not shas

syft just recently got an actions cataloger, but we came to the same realization that the dataset probably won't be useful as is if pinning by sha, which is the...

> When Grype is using the CPE matcher, it uses the version field for comparison: https://github.com/anchore/grype/blob/844711285b22c0e6ac55fa7c3a20ecd9650aaf71/grype/search/cpe.go#L91 which means that a CPE like cpe:2.3:a:oracle:openjdk:8:update392:*:*:*:*:*:* will be version "8" in grype's CPE...

https://github.com/anchore/grype-db/pull/145 was the grype-db change for adding update component, so I think making the same change you mentioned in grype will make these matches significantly better overall

The built constraint in the db seems correct given the data and you can basically ignore the CPEs in the db since they are largely unused apart from vendor/product

@joshbressers , so in this case it is matching on the `= 8` clause of the grype-db `version_constraint` because grype is currently dropping the `update392` component when doing the comparison....

Thanks @ramanNarasimhan77 , so unfortunately there still isn't a standardized way of embedding the version when building a go binary; however, syft does make an attempt at retrieving the version...

For ubuntu packages the vulnerability data for matches does not come from NVD, it comes from ubuntu, which currently has focal set to `Needed` on https://ubuntu.com/security/CVE-2018-1000021, which is why this...

So the issue is likely `git/focal-updates`, as that is going to pull in updates that won't be accounted for by the official Canonical feed. This is a known current downside...

@ramanNarasimhan77 , thanks for surfacing this though, we'll leave it open. @willmurphyscode , I think it might make sense to add a new category of false positives to track these...