Yes. pip-audit can query more than one vulnerability service, and the choice, plus how requirements are resolved or pinned, can change what it reports. When you compare it with another Python scanner, record the service, the flags and the input file, because each can explain a difference.
What the tool documents
The pip-audit README says it audits Python environments, requirements files and dependency trees for known vulnerabilities. With no input it audits the current environment. It can also audit a requirements file, or a local project by path, where it currently supports pyproject.toml and pylock files.
It supports multiple vulnerability services, listed as PyPI and OSV. The default is PyPI, drawing on the Python Packaging Advisory Database through the PyPI JSON API. You can switch to OSV with the service option.
Three settings that change the answer
| Setting | What it does | Effect on comparison |
|---|---|---|
| Vulnerability service | Picks the advisory source | Different databases can hold different entries and ranges |
| No deps mode | Skips dependency resolution and needs every requirement pinned to an exact version | Transitive packages are not examined unless you list them |
| Require hashes | Checks each requirement against a hash and needs pins and hashes for every entry | Repeatable audits, fails on unpinned entries |
The README calls hash checking the preferred option over the no deps mode, since it adds integrity checking and matches pip's hash checking mode.
Why this matters when you compare tools
Suppose you compare pip-audit on a requirements file with another scanner on a lockfile. Several differences are possible at once.
- The input files list different packages, since a requirements file may omit transitive packages that a lockfile includes.
- The services differ, so one flaw is present in one and absent in the other.
- Version resolution happens at different times.
- Name spelling differs between files, and Python names are normalized by lowercasing and collapsing dots, dashes and underscores, per the Python Packaging specification.
Each is solvable once you know it is in play.
A comparison routine
- Record the exact command and flags you used for pip-audit.
- Pin the input. Use the same pinned requirements for both tools.
- Try both services. Run pip-audit once with each service. If the two runs differ, the difference is data, and you have learned that your own tool matters less than the source.
- Normalize names before joining the results with the other tool's output.
- Read the advisory for each remaining difference, using the affected and fixed fields in the OSV schema.
Fixing automatically
The tool has a fix option that upgrades vulnerable dependencies, and a dry run mode that shows what would change without changing anything. Use the dry run first, and read the plan against your own compatibility needs, since an upgrade chosen by one tool's data may not match what another tool recommends.
Quick check
Does the default service cover everything OSV covers?
Not necessarily. Entries and ranges can differ between sources, so test both on your own project.
Why does the tool fail on unpinned requirements?
In the no deps and hash modes, the tool needs exact versions to audit repeatably, so it stops when a requirement is not pinned.
Sources
Last reviewed: 19 October 2026.
