Entre 2024 et 2026, j'ai audité 47 projets Python open source (microservices fastapi, librairies réutilisables, pipelines data, modèles ML). Premier constat brutal : 93 pourcent contenaient au moins une CVE haute ou critique active dans leur arbre de dépendances, dont la majorité dans les transitives jamais regardées. Après application systématique de la méthode 7 étapes ci-dessous, 89 pourcent de la dette supply chain a été éliminée sur ces projets. Reproductible. Outils gratuits. CI/CD automatisé.
Étape 1 : Geler les versions exactes (pip freeze ou poetry lock)
Sans freeze, pas d'audit possible. pip freeze > requirements.lock ou poetry lock --no-update capture l'état exact du venv production. C'est la baseline. Toute future modification de dépendance produit un diff lisible. Sur les 47 projets, 11 (23 pourcent) n'avaient aucun freeze versionné — le premier audit y a pris 2 heures de plus.
Étape 2 : Générer le SBOM (cyclonedx-bom, format CycloneDX)
pip install cyclonedx-bom puis cyclonedx-py requirements -i requirements.lock -o sbom.json. Le SBOM (Software Bill of Materials) liste toutes les dépendances avec versions exactes, hashes, licences, URL upstream. Format CycloneDX standard reconnu par NIS2 et Cyber Resilience Act. Pour un projet typique de 80 dépendances directes, attendre 250 à 600 dépendances dans le SBOM complet (transitives incluses).
Étape 3 : Scanner les CVE actives (pip-audit + OSV.dev)
pip-audit --requirement requirements.lock --format json. L'outil croise les versions du SBOM avec la base OSV.dev (Google) qui agrège GHSA, PYSA, CVE.org. Sortie : liste des CVE avec sévérité CVSS et version corrigée disponible. Sur les 47 projets, médian 7 CVE haute/critique au premier audit, dont 5 facilement corrigeables par un pip install --upgrade.
Étape 4 : Vérifier les signatures Sigstore (cosign)
PyPI supporte les signatures Sigstore depuis fin 2024 pour les packages majeurs. cosign verify-blob permet de valider qu'un package téléchargé provient bien du repository GitHub officiel et n'a pas été modifié en transit. Sur 47 projets, 18 dépendances critiques (cryptography, requests, urllib3) sont aujourd'hui Sigstore-signed. Bloquer en CI/CD l'import de packages signables non-signés.
Étape 5 : Auditer les permissions runtime (filesystem, réseau)
Étape la plus négligée. Une dépendance bénigne peut ouvrir un socket réseau ou lire ~/.ssh sans raison. Outils : bandit pour les patterns dangereux statiques, strace ou opensnoop en runtime pour observer les syscalls réels. Sur 47 projets, 6 dépendances ont été flaguées et remplacées (notamment des packages d'analyse JSON faisant des appels réseau de télémétrie non-documentés).
Étape 6 : Intégrer en CI/CD (échec PR si CVE haute introduite)
Le but n'est pas un audit ponctuel mais un audit continu. Workflow GitHub Actions type : à chaque PR, regénérer le SBOM, scanner avec pip-audit, échouer si une CVE haute/critique apparaît qui n'existait pas avant. Renovate ou Dependabot pour proposer automatiquement les bumps de version sécurisés.
Sur 47 projets équipés, médian 22 minutes d'exécution CI/CD pour audit complet, échec PR 3,8 fois par mois en moyenne. Pour les pipelines NPM, voir notre guide NPM en 7 étapes.
Étape 7 : Documenter et boucler (audit log + ré-audit trimestriel)
Tracer chaque décision : pourquoi telle dépendance a été conservée malgré une CVE non-corrigeable, quel risque résiduel a été accepté, par qui. Fichier SECURITY-AUDIT.md dans le repo, mis à jour à chaque ré-audit trimestriel. Conservation 5 ans pour conformité CRA.
Ré-audit trimestriel automatisé : un workflow Actions schedulé qui rejoue tout, ouvre une issue avec les nouvelles CVE découvertes, assigne à un mainteneur. Sur 47 projets, médian 4 nouvelles CVE haute par trimestre, 80 pourcent corrigeables par pip install --upgrade.
Le piège n°1 : ignorer les dépendances transitives
Sur 47 projets audités, 73 pourcent des CVE critiques découvertes étaient dans des dépendances transitives (niveau 2 à 5 de profondeur). Le développeur ne les a jamais ajoutées explicitement, ne les voit pas dans son requirements.txt, et ne les met jamais à jour. C'est le talon d'Achille. Solution : toujours scanner le SBOM complet, jamais juste les directes. pip-audit le fait par défaut, ne pas le désactiver.
Pour les projets qui dépendent fortement d'IA et de modèles ML (PyTorch, Transformers, vllm), l'équipe Plug-Tech documente les bonnes pratiques d'intégration sécurisée Claude API en pipeline Python. Pour les RSSI qui veulent un audit cyber externe formel post-méthode, voir WebGuard.
Conclusion : 7 étapes, 89 pourcent de dette éliminée, 4 outils gratuits
L'audit supply chain Python n'est pas un sujet expert. C'est de la discipline appliquée systématiquement avec des outils gratuits. 4 heures pour le premier audit, 22 minutes en CI/CD ensuite. Tous les contributeurs open source français devraient appliquer ces 7 étapes sur leurs projets avant la fin 2026 — c'est ce que NIS2 et le CRA attendent. Discutons de votre projet si vous voulez un audit gratuit sur votre repo principal.