Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some CVEs are missing #65

Open
di opened this issue Mar 23, 2022 · 5 comments
Open

Some CVEs are missing #65

di opened this issue Mar 23, 2022 · 5 comments

Comments

@di
Copy link
Member

di commented Mar 23, 2022

For example, CVE-2022-24761/GHSA-4f7p-27jc-3c36 was published 5 days ago but is not present here.

@westonsteimel
Copy link
Collaborator

westonsteimel commented Mar 23, 2022

This is because there aren't yet any CPEs on the NVD entry. The automated process currently needs those in order to determine version ranges. It does also attempt to look at the description to determine version but only supports a limited number of patterns per https://github.com/google/osv/blob/b291dc7d9c7a4fcec2b62fb67952f7e63d0e34be/vulnfeeds/cves/versions.go#L109.

@westonsteimel
Copy link
Collaborator

It would be really useful if the triage tooling pulled in the GHSA data and used that if available over the NVD stuff. I think I may have filed an issue for that but never had time to actually work it

@westonsteimel
Copy link
Collaborator

google/osv.dev#254

@di
Copy link
Member Author

di commented Mar 23, 2022

Thanks @westonsteimel. Since it seems like advisories may originate from GHSA first, which likely would include the version ranges, that would be ideal.

@juspence
Copy link

juspence commented May 9, 2022

Another usecase: https://github.com/trailofbits/pip-audit uses the PyPA advisory database by default, but also supports OSV. Users (myself as an example) sometimes assume these databases are already synchronized and that there's no need to check both.

This caused an issue where a dependency used by my team had a GHSA, but we didn't notice because we only ran pip-audit against the PyPA advisory database. I've filed a pip-audit bug to automatically check both databases (or document that results may differ), but it would be nice to see it fixed upstream as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants