Audit Python Dependencies with OSV Data

A useful Python dependency audit starts with the versions actually deployed, not a broad keyword search for security news. The OSV Vulnerability Scraper accepts PyPI names with optional versions and returns advisories mapped to package ranges.

Build the inventory input

Extract top-level and transitive packages from a lockfile, SBOM, or environment report, then format entries consistently:

{"packages":["PyPI:django@4.2.10","PyPI:requests@2.31.0","PyPI:jinja2@3.1.2"],"maxResultsPerPackage":20}

Keep the original package/version string beside every result. That field is the join key back to the service, repository, owner, and environment that supplied the dependency. The advisory ID and aliases provide durable identifiers for tickets; affected ranges and fixed versions provide the evidence needed to plan an upgrade.

Do not collapse records only by CVE. Some ecosystem advisories use PYSEC or GHSA identities, and a single vulnerability can have several aliases. Deduplicate by OSV ID while retaining aliases for external integrations. If the same result is produced by several inventory entries, preserve the asset-to-advisory relationship downstream rather than discarding which service was affected.

An empty result is not a certification. It can reflect source coverage, package naming, a newly disclosed issue, or a vulnerability that has not yet been mapped to a version. Combine this feed with code review, reachability analysis, supported-version policy, and vendor guidance.

Schedule the audit after lockfile changes and on a regular cadence. Alert on newly observed IDs, withdrawn-state changes, or a newly published fixed version. That produces a smaller, explainable queue than repeatedly exporting every historical advisory without deployment context.