pip-audit review
pip-audit 2.10.1 collects Python package names and versions from an environment, requirements files, a local project, or PEP 751 locks, then matches them against vulnerability records. PyPI is the default feed; OSV, a custom OSV endpoint, and Ecosyste.ms are options. It can print tables, Markdown, JSON, or CycloneDX and can preview or apply package upgrades. Version 2.10.1 stops a KeyError when an OSV affected entry omits the optional ranges field. A zero result means the selected feed had no matching record, not that application code is safe.
Our pip-audit 2.10.1 install took 0.5 seconds, used 27 MB across 29 packages, imported in 0.01 seconds, and found no known vulnerabilities in its fresh environment. Use it as a Python dependency-advisory gate, with separate source scanning and trusted, pinned inputs.
We installed it
| Install | ✓ · 0.5s | 29 packages on disk · 27 MB |
| Import | ✓ | import pip_audit in 0.01s · pure Python · requires Python >=3.10 |
| Known vulns | 0 | (pip-audit) |
Answers from our run
Does pip-audit install cleanly?
Yes. In a fresh container with an empty cache, pip install pip-audit finished in 0.5s, leaving 29 packages and 27 MB on disk. pip-audit reported no known vulnerabilities.
What does pip-audit need to run?
Python >=3.10, and nothing compiled: it is pure Python. In our run import pip_audit succeeded in 0.01s.
pip-audit or safety: which should you use?
safety: Use it when hosted policy controls and managed exception workflows justify a commercial product. Our pip-audit 2.10.1 install took 0.5 seconds, used 27 MB across 29 packages, imported in 0.01 seconds, and found no known vulnerabilities in its fresh environment.
When should you not use pip-audit?
You need source-code security analysis; pip-audit matches distribution versions and does not inspect your Python functions
Use it if
- CI needs a noninteractive failure when an exactly pinned Python dependency matches a published advisory
- The same dependency collection should emit CycloneDX JSON or XML for another security system
- Requirements or PEP 751 inputs are trusted, pinned, and preferably hashed before the audit starts
- PyPI or OSV advisory coverage is acceptable without a commercial account or hosted policy console
- You need source-code security analysis; pip-audit matches distribution versions and does not inspect your Python functions
- The risk sits in a system library bundled inside a wheel; the README warns that Python package versions may not identify vendored native code correctly
- The dependency input is untrusted, because resolving a requirements file can execute package build code just like installation
- Exception policy requires owners, reasons, and expiry dates inside the tool; --ignore-vuln stores only repeated advisory IDs
- The only available lock is Poetry, PDM, Pipenv, or uv-specific; export a supported requirements or PEP 751 representation first
Setup reality
We installed pip-audit 2.10.1 in a clean Python 3.12 Bookworm sandbox in 0.5 seconds. The tool left 29 packages and 27 MB on disk. It declares 23 direct dependencies, requires Python 3.10 or newer, and is pure Python. The distribution uses the Apache Software License and does not ship py.typed. import pip_audit worked in 0.01 seconds. Running pip-audit against that fresh environment returned zero known vulnerabilities.
Keep this 29-package tool tree in a dedicated CI or tooling environment instead of the application under inspection. With no input arguments it checks the active interpreter environment. -r reads requirements, a path reads supported project metadata, and --locked targets PEP 751 lockfiles. If the input is not fully resolved, pip-audit creates a temporary environment and invokes packaging machinery. That can take about as long as installation and may execute build hooks, so only audit trusted dependency files.
Exact pins with --no-deps avoid another resolver pass. --require-hashes is a firmer CI boundary because it also requires hashes for every requirement. Private repositories use pip-style index options, but the documented authentication path is noninteractive; supply approved credentials through the runner rather than expecting a prompt. Advisory queries still require network access unless the organization provides a compatible reachable endpoint, and service outages should be distinguished from a clean scan.
Exit code 0 means no matched findings and exit code 1 means one or more findings; the CLI does not suppress that status. --fix --dry-run reports proposed version changes before touching the environment. Each accepted result needs an --ignore-vuln flag, with owner, reason, and review date stored beside the CI command because the flag has no expiry field. Teams that fail only on fixable records need to parse JSON and apply that policy themselves.
Patterns
Audit the active interpreter environment audit-environment
pip-audit
# exclude packages outside the local environment
pip-audit --local--local excludes packages outside the local environment, but PATH still decides which Python installation is examined.
Scan trusted requirement files audit-requirements
pip-audit -r requirements.txt
pip-audit -r requirements.txt -r requirements-dev.txtResolving requirements can run package build hooks; do not point this command at dependency text from an untrusted source.
Avoid a second dependency resolution avoid-resolution
pip-audit --no-deps -r requirements.txt
pip-audit --require-hashes -r requirements.txt--no-deps needs exact pins, while --require-hashes also checks that every requirement carries an integrity hash.
Fail CI on a matched advisory gate-ci
- name: Audit Python dependencies
run: pip-audit -r requirements.txt --require-hashespip-audit exits with status 1 when it reports one or more findings, so the shell step blocks by default.
Ignore one reviewed advisory ignore-advisory
pip-audit -r requirements.txt \
--ignore-vuln GHSA-w596-4wvx-j9j6--ignore-vuln records no owner, reason, or expiry; place those details beside the CI command.
Write machine-readable findings write-json-report
pip-audit -r requirements.txt -f json -o audit.jsonJSON includes advisory aliases and fix versions that a policy step can inspect without scraping the table output.
Emit CycloneDX JSON produce-cyclonedx
pip-audit -r requirements.txt -f cyclonedx-json -o sbom.jsonA completed SBOM file does not force exit status 0; vulnerability findings still determine the process result.
Point OSV queries at a mirror use-osv-mirror
pip-audit -s osv --osv-url https://osv.internal.example/v1/query -r requirements.txtThe supplied URL must implement the OSV query shape expected by pip-audit 2.10.1.
Audit PEP 751 lockfiles audit-pep751-lock
pip-audit --locked .--locked searches for pylock.*.toml; tool-specific lock formats need conversion before this command.
Preview dependency upgrades preview-fixes
pip-audit --fix --dry-run
# after review
pip-audit --fix--fix --dry-run leaves packages unchanged, and applied upgrades still need the application test suite.
Alternatives
| Package | Registry | Pick it when |
|---|---|---|
| safety | PyPI | Use it when hosted policy controls and managed exception workflows justify a commercial product |
| bandit | PyPI | Use it to find insecure patterns in Python source instead of dependency advisories |
| cyclonedx-bom | PyPI | Use it when producing a Python SBOM is the goal and another system handles vulnerabilities |
| osv-scanner | PyPI | Use it for a multi-ecosystem OSV scan rather than a Python packaging-focused command |
More utils guides
lru-cache · ajv · type-fest · p-limit · find-up · js-yaml · the whole shelf →
How this guide is made: grounded in the library's documentation, release notes, changelog, and issue history, on a fixed rubric — not a hands-on install of every release. The 50 most-downloaded entries are additionally install-verified in clean containers. Corrections: contact the desk.