Sécurité des dépendances Python en 2026 — pip-audit, lockfiles et les attaques PyPI que nous voyons sans cesse

Les attaques supply-chain PyPI sont devenues routinières en 2026. Le typosquatting est le bruit long-tail. Les incidents sérieux sont des mainteneurs qui volent des credentials, des attaques de dependency-confusion contre des noms de packages internes privés, et des scripts post-install qui exfiltrent les variables d'environnement à pip install.

Les défenses de l'écosystème Python ont rattrapé plus tard que celles de npm. Elles sont maintenant adéquates. Ce qu'il leur faut, c'est d'être réellement activées.

La porte CI

pip install pip-audit
pip-audit --strict --requirement requirements.txt
 
# pip 24+ — vérifier les attestations de package
pip install --require-hashes -r requirements.lock.txt
 
# Ceinture et bretelles : scanner tiers
pip install safety
safety check --json

--require-hashes fait que pip refuse d'installer si le SHA256 d'un package ne correspond pas à ce qui est pinné dans votre lockfile. Ce seul flag défait la plupart des attaques supply-chain — un mainteneur compromis qui pousse une nouvelle version sous le même numéro n'est pas installé.

L'article complet couvre :

• Pourquoi requirements.txt seul n'est pas un lockfile (et ce qui en est un — pip-compile, uv lock, Poetry)
• L'histoire PEP 740 / sigstore provenance qui a atterri en 2024
• Dependency confusion contre des noms de packages privés — le namespace squat
• Scripts pre-install et arguments --no-build-isolation à éviter
• Le pattern mirror PyPI interne / devpi pour pipelines air-gapped
• Config Renovate pour Python — groupements par défaut sensés et cadence d'update

Nous livrons ces contrôles sur chaque stack Python managée.