pip-audit: Python Vulnerability Audits and Dependency Fixes

What pip-audit Checks in Python Dependencies

pip-audit addresses a narrow but common supply-chain problem: a Python environment contains a package version for which a public advisory is already known. Its intended users include developers reviewing dependencies, maintainers checking release candidates, and automated CI systems that need to block a build when an installed or declared package is affected. The command describes its central task as auditing the Python environment for dependencies with known vulnerabilities.

The supported inputs include a local environment, one or more requirements-style files, and a local Python project. This matters because an application can have different dependency views. A developer machine may contain packages installed for experiments or unrelated tools, while a requirements file represents a narrower deployment set. The CLI exposes `-r REQUIREMENT` for requirements files, accepts a `project_path`, and provides `--locked` for lock files belonging to local projects.

pip-audit is not a general source-code scanner. Its documented capabilities concern package versions and published vulnerability records. The README does not claim that it finds unsafe code, credentials, malware without a package advisory, or vulnerabilities invented during source analysis. That boundary makes it useful in dependency-focused security checks, but it should not be treated as a complete review of an application or its code.

Advisory Lookup and pip-audit's Data Flow

The default vulnerability service is PyPI. According to the README, pip-audit uses the Python Packaging Advisory Database through the PyPI JSON API for vulnerability reports. In practical terms, the dependency collector identifies package names and versions, the selected service is asked for matching advisories, and pip-audit presents or exports the resulting findings. Its local `pip` cache can be reused during that process, which avoids discarding cached package data that is already available to the Python packaging workflow.

The CLI also supports `osv` and `esms` through `-s SERVICE`. OSV requests normally use the documented URL `https://api.osv.dev/v1/query`, although `--osv-url` can replace that endpoint. Service choice changes where advisory records come from, not the basic purpose of the command. This distinction matters for teams that need records beyond the default PyPI-backed source or already operate around an OSV-compatible service.

Results are not limited to terminal columns. `-f FORMAT` accepts `columns`, `json`, `cyclonedx-json`, `cyclonedx-xml`, and `markdown`. The first is the default, while JSON and CycloneDX formats make the command more suitable for stored reports or downstream tooling. The documented dry-run mode also separates collection from analysis: without `--fix`, `-d` collects dependencies but does not perform the audit. With `--fix`, the audit is performed but no fixes are applied. This is useful when the immediate goal is inventory resolution rather than vulnerability reporting.

Installing pip-audit and Auditing requirements.txt

pip-audit requires Python 3.10 or newer. The README documents installation through the Python package installer. Run the following command in an environment where installing `pip-audit` is appropriate:

python -m pip install pip-audit

The command installs the current package release exposed by the package index in that environment. A successful installation provides both the `pip-audit` entry point and the `python -m pip_audit` invocation. Confirm that the command is available before using it:

pip-audit --help

The help output should describe auditing a Python environment and list options for requirements files, project paths, output formats, vulnerability services, dry runs, and fixes. Using an isolated environment is advisable for a first installation, although the README does not prescribe a particular virtual-environment command.

For a first real audit, point the command at a requirements file:

pip-audit -r requirements.txt

This selects `-r`, whose long form is `--requirement`. The command collects dependencies represented by `requirements.txt`, checks them against the default `pypi` service, and writes columnar results to the terminal. If the command reports known vulnerabilities, review the named packages, affected versions, and advisory details before changing the file. The default output is intended for direct inspection; machine consumers can select JSON with `-f json`.

Auditing Installed Packages and Local Projects

If no requirements file is supplied, the command audits the active Python environment. The module form uses the same CLI entry point, which can help when the executable search path is inconvenient:

python -m pip_audit

The `-l` or `--local` option restricts results to dependencies in the local environment. That is more selective than inspecting every package `pip` can resolve in the broader environment, but the README does not define an automatic boundary between application dependencies and unrelated globally installed tools. A developer working in a virtual environment therefore has fewer unrelated packages to reason about.

For a local project, pass its directory as the positional `project_path`. This shifts the input from merely the active environment or a requirements file to a project-based dependency check. The separate `--locked` option applies only when a project path is supplied and audits the project's lock files. It cannot serve as a general lock-file switch for arbitrary requirements inputs.

These modes answer different operational questions. A requirements audit is a focused pre-release check against declared inputs. An environment audit reports what is installed right now. A project audit inspects the dependency representation associated with that directory. Teams should choose the mode whose inventory matches the artifact they intend to ship, since a clean declaration and a divergent local environment can represent different states.

Automatic Fixes, Dry Runs, and CI Constraints

The `--fix` option enables automatic remediation of vulnerable dependencies. This is a direct package-update operation, not merely a larger report. Because a replacement can alter application behavior, the exact resolution must be checked against project requirements rather than inferred from the fact that an advisory stopped appearing.

A safer first review can combine `--fix` with `-d`. Under the documented dry-run behavior, that combination performs the vulnerability lookup but skips fixes. It shows what the audit would identify without changing the environment during that invocation. The README does not provide a separate dependency-upgrade preview, compatibility report, or automatic rollback procedure, so the organization still needs its own validation criteria.

CI integration has a networking constraint. The documented `pre-commit` example explicitly skips the hook in pre-commit.ci because that service does not allow network calls. Since vulnerability lookups depend on advisory services, a network-restricted runner cannot perform the same audit. pip-audit also has an official GitHub Action, but the repository points users to the separate `pypa/gh-action-pip-audit` documentation for detailed configuration.

Automatic fixing is consequently most defensible for a branch or isolated CI job where dependency changes can be inspected as a patch. It is less suitable for an unobserved production environment where an immediate mutation could turn a security check into an outage.

pip-audit Compared with Direct Advisory Queries

A real alternative is to query the PyPI JSON API directly for each package and version, then compare those records with an inventory obtained from `pip`. This manual approach does not add an extra tool, but it transfers much of pip-audit's work into a script. The caller must normalize package names, handle every supported advisory response, collect the correct environment or requirements set, and format findings consistently.

pip-audit packages that process behind one command. It can reuse local `pip` caches, select among `pypi`, `osv`, and `esms`, emit several report formats, and emit CycloneDX SBOMs. Those features matter when the audit needs to become a repeatable check rather than an occasional spreadsheet review. Its optional `--fix` also changes the process from advisory collection to package replacement.

The direct API route remains reasonable for a controlled one-package investigation or an environment with custom data handling that the CLI cannot express. Its disadvantage is operational rather than conceptual: the comparison, reporting, and remediation logic must already exist elsewhere. For routine auditing across requirements files, dependency trees, and CI artifacts, that amount of custom code usually weakens the point of using a dedicated scanner.

Maintenance, Compatibility, and Apache-2.0 Impact

The repository is not archived, and the last push was on 2026-10-15. The release record also lists v2.10.1 on 2026-06-10, v2.10.0 on 2025-12-01, and v2.9.0 on 2025-04-07. Those dates indicate recent development activity, while the Python Packaging Authority's maintenance relationship gives the project an identifiable upstream home.

Compatibility has a clear floor: `pyproject.toml` requires Python 3.10 or newer and classifies the package as Python 3 only. Upgrading pip-audit can therefore affect projects running older Python versions. The declared runtime dependencies include packaging, pip-api, pip-requirements-parser, requests, rich, CycloneDX libraries, and cache-related packages, so installation can add or update more than a single standalone script.

The project uses the Apache-2.0 license. The repository lists that identifier, and `pyproject.toml` classifies it as an OSI-approved Apache Software License. That is the relevant licensing fact for engineering review. This article does not interpret that license or provide legal advice about distribution, notices, or internal policy.

Release changes should still be reviewed before upgrading a CI gate. Output formats, service behavior, Python compatibility, and fix handling can affect automation even when the user's command remains the same.

Editorial conclusion

pip-audit fits developers and CI pipelines that need to check Python dependency inventories against known advisories before release or deployment. It is a poor choice for detecting unknown vulnerabilities, malicious source code, or licensing conflicts, none of which the documented scanning model addresses. Before adopting automatic fixes, verify whether the build uses hashes, private indexes, or constraints that could make a replacement incompatible. For an initial adoption, require a clean report from a requirements file and preserve `--dry-run` results for comparison before allowing `--fix`.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. pypa/pip-audit on GitHub
4. README
5. Releases