pip-audit reports a vulnerable Python package: separate the fixable findings from the pinned and the unfixed

Know what was audited

pip-audit can examine the current Python environment, a requirements file or a dependency tree, and the three can give different answers. An environment reflects what happens to be installed on one machine; a requirements file reflects what you intend to install. By default it asks the PyPI JSON API, which exposes the Python Packaging Advisory Database, and it can use OSV instead. Decide which input represents what you deploy, and audit that. The README warns that auditing a requirements file is roughly equivalent to installing it, and that if you would not pip install something you should not audit it, so run the audit in a throwaway environment with none of your secrets.

• Audit the requirements file or lock that production uses, in an isolated environment.
• Record the tool version, the vulnerability source and the date with the result, since advisories change.

Sort findings into fixable and not

Each finding lists the affected package, the version you have and, when one exists, the versions that fix it. A finding with a fix version is a candidate for an update. A finding with none cannot be cleared by upgrading, and the tool offers no option to ignore unfixed findings: the README suggests producing JSON output and filtering on the fix_versions field with another tool. The exit status is 1 whenever anything is found, including findings you have decided to defer, so a build that fails on the audit needs its own rule for known, accepted findings, written down with a reason. Do not hide a finding by deleting the check.

• Make three lists: has a fix version, has none, and deferred with a reason.
• Review the deferred list on a date, since a fix may appear later.

Preview the fix before you apply it

The --fix option upgrades vulnerable dependencies. Used together with --dry-run it audits and reports what it would upgrade or skip without changing anything, which is the safest first look. Apply the upgrades on a branch, then run the project's tests and its build. Where requirements are pinned with hashes, --require-hashes makes audits repeatable by insisting that every requirement has one. A hash pin means an update changes the pinned file, so update the hashes together with the version, and review the diff for anything you did not expect.

• Use the dry run to see which findings the tool can upgrade itself and which it skips.
• Run the same tests before and after, and compare the pass and fail lists, not just the totals.

What blocks an upgrade, and how the paid job is accepted

An upgrade can be blocked because a pin in your own file holds the version back, because another package requires an older version, or because the fixed release is a major version that changes behaviour. Each of those is a decision to record rather than force. A framework or runtime upgrade belongs in its own job with its own tests. The dependency update job takes one repository, one scanner and one agreed severity. It updates what can be fixed safely, runs the build and tests before and after, and lists every remaining finding with the reason. A clean result means that known advisories at that threshold are cleared in the packages scanned. It is not a statement that the application is secure, and it is not a penetration test.