How to Scrape OSV Package Vulnerabilities

Package-security work becomes difficult when an inventory spans npm, PyPI, Maven, Go, Cargo, NuGet, and other ecosystems. The OSV Vulnerability Scraper turns package and version checks into consistent dataset rows without requiring teams to maintain a separate connector for each advisory database.

Query exact package versions

Use Ecosystem:name@version when the deployed version is known:

{"packages":["PyPI:requests@2.31.0","npm:lodash@4.17.20"],"maxResultsPerPackage":10}

Each row carries the primary OSV ID, CVE or GHSA aliases, the published summary, affected package ranges, fixed versions, severity material, references, and a canonical source URL. The input that produced the match is retained, which makes it easier to join results back to a dependency inventory.

Package-only values such as Go:golang.org/x/net return known advisories without limiting the check to one version. That is useful for research and watchlists, while version-specific queries are better for an actionable remediation queue. Exact advisory IDs can be supplied separately when a team already tracks a CVE, GHSA, PYSEC, or ecosystem identifier.

Deduplicate on the returned id, not the summary text. Multiple packages or aliases can point to the same underlying advisory. Review the affected ranges and upstream references before deciding whether a deployed service is exposed; runtime configuration and reachability are outside the dataset.

For recurring work, save a Task for each maintained inventory segment and schedule it after dependency-lockfile updates. Store snapshots with collection timestamps downstream so changes to affected ranges, withdrawal state, severity, or fixes remain auditable.