search

pypa / advisory-database

Advisory database for Python packages published on pypi.org
Creative Commons Attribution 4.0 International
264 stars 62 forks source link

Some CVEs are missing #65

Open di opened 2 years ago

di commented 2 years ago

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

westonsteimel commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

https://github.com/google/osv/issues/254

di commented 2 years ago

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

juspence commented 2 years ago

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.