Python dependency security in 2026 — pip-audit, lockfiles, and the PyPI attacks we keep seeing

PyPI supply-chain attacks have become routine in 2026. Typo-squatting is the long-tail noise. The serious incidents are credential-stealing maintainers, dependency-confusion attacks against private internal package names, and post-install scripts that exfiltrate environment variables on pip install.

The Python ecosystem's defences caught up later than npm's. They are now adequate. What they need is to actually be turned on.

The CI gate

pip install pip-audit
pip-audit --strict --requirement requirements.txt
 
# pip 24+ — verify package attestations
pip install --require-hashes -r requirements.lock.txt
 
# Belt-and-braces: third-party scanner
pip install safety
safety check --json

--require-hashes makes pip refuse to install if a package's SHA256 doesn't match what's pinned in your lockfile. This single flag defeats most supply-chain attacks — a compromised maintainer who pushes a new version under the same number doesn't get installed.

The full write-up covers:

• Why requirements.txt alone is not a lockfile (and what is — pip-compile, uv lock, Poetry)
• The PEP 740 / sigstore provenance story landed in 2024
• Dependency confusion against private package names — the namespace squat
• Pre-install scripts and --no-build-isolation arguments to avoid
• The internal PyPI mirror / devpi pattern for air-gapped pipelines
• Renovate config for Python — sensible default groupings and update cadence

We ship these controls on every managed Python stack.