python-security: pip-audit transport/exception failures are reported as "known-vulnerable Python dependencies" #2158

Observed

.github PR #2123 head 7e3b1a40c, pip-audit (Python dependency audit) job 103582668686 (run 34704684147, 2026-09-12 16:18Z). Every audited file printed No known vulnerabilities found, then the step still failed with:

##[error]pip-audit reported known-vulnerable Python dependencies.

The actual cause is inside the pip-audit -r ./requirements-opencode-review-ci-hashes.txt group: pip-audit 2.10.1 raised an unhandled ConnectionResetError: [Errno 104] Connection reset by peer from pip_audit/_service/pypi.py:64 (PyPI advisory query) and exited non-zero. No vulnerability was reported anywhere in the job.

Why it matters

.github/workflows/python-security.yml step "Run pip-audit (hard gate on any known vulnerability)" folds every non-zero exit into one status=1 and prints a single message that asserts a vulnerability finding. A transient PyPI/network error therefore surfaces as a security finding. That misled triage on #2157 (the comment there went looking for "known-vulnerable dependencies" to remediate) and it can mislead the review gate's evidence readers the same way. Failing closed is correct; the classification is not.

Expected

• Keep the hard gate (any non-zero exit still fails the job).
• Distinguish the two outcomes in the printed evidence: a genuine finding (pip-audit output contains Found N known vulnerabilit…) vs. an audit-service/transport failure (traceback, no findings) — e.g. ::error::pip-audit could not complete for <file>: <exception line> so a rerun is the documented next step rather than dependency remediation.
• Do not add an arbitrary retry budget; if a retry on transport errors is wanted, cite the provider-stated condition (directive 3.1).

Ownership / sequencing

python-security.yml currently has 7 open PRs touching it (#1051 pip-audit-specific, #1555, #1639, #2004, #2021, #2040, #2109). Not opening an eighth; the fix is a small change to the audit step's failure reporting plus a contract test, best bundled by #1051's writer or landed after that stack settles. Internal review date: 2026-09-20.

Related: #2157 (its pip-audit evidence on #2123 is this class, not a vulnerability), #2123.