Evaluate osv.dev
See original GitHub issuePer @di: The final deliverable version of pip-audit
will not use osv.dev, but instead should use a (hitherto unimplemented) REST API provided by PyPI.
Since we’ll need to consume that API, we should evaluate osv.dev and determine what we’d like to be different.
Issue Analytics
- State:
- Created 2 years ago
- Comments:5 (5 by maintainers)
Top Results From Across the Web
OSV.dev
A distributed vulnerability database for Open Source ... An open, precise, and distributed approach to producing and consuming vulnerability information for open ...
Read more >Announcing OSV-Scanner: Vulnerability Scanner for Open ...
The OSV-Scanner generates reliable, high-quality vulnerability information that closes the gap between a developer's list of packages and the ...
Read more >Google releases dev tool to list vulnerabilities in project ...
Google has launched OSV Scanner, a new tool that allows developers to scan for vulnerabilities in open-source software dependencies used in ...
Read more >Google debuts OSV-Scanner to find vulns in open source ...
Google this week released OSV-Scanner – an open source vulnerability scanner linked to the OSV.dev database that debuted last year.
Read more >Open Source Vulnerability format - GitHub Pages
Serving <ID> in the shared format at https://api.osv.dev/v1/vulns/<ID> ... Pseudocode for evaluating if a given version is affected is available here.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Here’s the docs for the OSV API: https://osv.dev/docs/
One thing that I noticed recently is that the OSV vulnerability schema lists multiple version range. So there can be multiple start version introduced/version fixed pairs for a single vulnerability in the case where the same bug get re-introduced.
We’d want the PyPI API to work the same way for those types of vulnerabilities.