pip-audit scans Python environments, requirements files and project dependency trees for packages with known vulnerabilities. It looks at packages and versions, not your code, and its own README says it does not detect transitive vulnerabilities in non-Python shared libraries.
What it checks and where the data comes from
By default pip-audit queries the Python Packaging Advisory Database through the PyPI JSON API. You can switch the vulnerability service to OSV with a flag. Because the two sources differ, running both on the same project is a good learning exercise.
Common commands
pip-audit
pip-audit -r ./requirements.txt
pip-audit .
pip-audit -f json
The first audits the current environment. The second audits a requirements file. The third audits a local project, and for that mode the README says only pyproject.toml and pylock files are supported. The last writes JSON, and other formats include columns, markdown and CycloneDX.
Exit codes
Exit code 0 means no known vulnerabilities were found. Exit code 1 means one or more were. That makes it simple to fail a CI job, and you can ignore a specific ID with the ignore option when you have documented a reason.
Fixing with care
The tool can try to upgrade vulnerable dependencies automatically, and a dry run option previews what it would change without touching anything. Use the dry run first. An automatic upgrade can pull in a new major version, so read the changes and run your tests.
The blind spots
Write these in your lab notes.
| Blind spot | What it means for you |
|---|---|
| Packages and versions only | It cannot say whether your code calls a vulnerable function |
| Non-Python shared libraries | A Python wheel that bundles a native library may carry issues the tool does not see |
| Known issues only | A flaw with no published advisory is invisible |
| Environment versus project | Auditing the environment shows what is installed, not what a clean build would install |
The last row matters. Audit what you will actually ship, from a clean install built from your lock or requirements file.
A practice exercise
- Create a virtual environment and install two or three packages pinned to older versions.
- Run pip-audit against the requirements file and save the JSON.
- Run it again with the OSV service and diff the two results.
- Pick one finding and read the advisory, the affected range and the fixed version.
- Upgrade, rerun, and confirm it clears.
If you also want to see how this fits in a bigger workflow, our post on reading a GitHub security advisory shows what each field means.
Using it in CI
A common pattern is to run the audit on every pull request against the requirements file, and to fail the job on any finding that has a fixed version. Findings without a fixed version can be tracked in an issue with an owner and a review date instead of blocking every build. Whatever rule you choose, write it down so contributors know what to expect.
Quick check
Does pip-audit work with lock files?
The README documents a locked mode for local projects. Check the current README for supported file types before relying on it.
What exit code means vulnerabilities were found?
Exit code 1.
Sources
Last reviewed: 19 October 2026.
