Audit Published PyPI Package Dependencies

Published package metadata is a useful audit input, but it is not the same as the installed environment. The PyPI Package Scraper collects exact project requirements and compatibility fields so reviewers can identify questions before running environment-aware tools.

Collect the source metadata layer

Choose the packages actually approved or imported by the application.

{"packageNames":["requests","urllib3","httpx","aiohttp"],"maxResults":4}

Inspect dependencies, requires_python, classifiers, license, latest version, and vulnerability records. Keep requirement strings intact. Markers such as Python version, operating system, and extras determine whether a dependency applies, so splitting strings naively can change their meaning.

Compare the result with lockfiles and deployed inventories. PyPI describes the current published project response; your environment can pin an older version, select optional extras, or resolve transitive dependencies differently. Use package-manager and software-composition tools to build the installed graph.

Treat vulnerability metadata as one signal. A blank list is not a certification, and a listed issue needs version and environment context. Route findings through the established security process rather than inventing a pass/fail rule from one field.

Schedule exact lookups to detect changes in requirements or Python support. Store snapshots and alert on meaningful diffs, especially a raised minimum Python version or new dependency. The workflow improves visibility and audit preparation while keeping the boundary clear: source metadata supports a dependency audit; it does not replace one.

Review optional extras separately because an application can activate requirement branches that are invisible when teams examine only the package's default installation.