Comment securiser les dependances open source d’un projet Python en 7 etapes

Si vous developpez en Python, vous utilisez des dependances open source. C’est une evidence en 2026 : Django, Flask, FastAPI, Requests, NumPy, Pandas, SQLAlchemy — l’ecosysteme PyPI heberge plus de 550 000 paquets, et un projet Python moyen importe directement une vingtaine de librairies. Mais chacune de ces librairies tire elle-meme ses propres dependances, et les dependances de ces dependances, creant un arbre de 150 dependances transitives ou plus que vous n’avez jamais auditees.

Chaque dependance est un vecteur d’attaque potentiel. Les incidents de supply chain Python se multiplient : l’attaque ChocoPoc sur PyPI en aout 2026, la faille BadHost dans Starlette/FastAPI en mai, les campagnes de typosquatting qui touchent des dizaines de paquets chaque mois. Dans ce contexte, securiser vos dependances n’est plus optionnel — c’est une obligation professionnelle, bientot reglementaire avec le Cyber Resilience Act europeen.

Ce guide detaille les 7 etapes concretes pour securiser les dependances open source de vos projets Python. Chaque etape est illustree avec des commandes pretes a copier, des exemples de configuration et des recommandations d’outils testes en production. Que vous mainteniez une API FastAPI, une application Django ou un pipeline de data science, ces etapes s’appliquent a votre projet.

Etape 1 : Dresser l’inventaire complet des dependances

Avant de securiser quoi que ce soit, il faut savoir exactement ce que contient votre projet. La majorite des developpeurs Python connaissent leurs dependances directes (celles listees dans requirements.txt ou pyproject.toml), mais ignorent les dependances transitives — les librairies que vos dependances importent elles-memes. C’est pourtant dans ces dependances transitives que se cachent la plupart des vulnerabilites exploitees.

Commande de base : pip list --format=columns affiche toutes les librairies installees dans l’environnement actif, mais sans distinguer les dependances directes des transitives.

Arbre des dependances : pip install pipdeptree && pipdeptree --warn silence affiche l’arbre complet des dependances avec les relations parent-enfant. C’est l’outil indispensable pour comprendre quelles librairies tirent quelles sous-dependances. Un projet Django typique revele souvent 40 a 80 dependances transitives que le developpeur n’a jamais explicitement installees.

Premier scan de securite : pip install pip-audit && pip-audit realise un premier scan de toutes les dependances installees contre la base de donnees OSV (Open Source Vulnerabilities). Le rapport liste les CVE connues, leur severite et les versions corrigees disponibles. Executez cette commande aujourd’hui sur chaque projet Python actif de votre organisation.

Conseil pratique : exportez l’inventaire dans un fichier pour reference : pipdeptree --json > deps-inventory.json. Ce fichier servira de baseline pour les etapes suivantes et pour la generation du SBOM a l’etape 5.

Etape 2 : Epingler les versions avec verification de hash

Un fichier requirements.txt avec des versions flottantes (requests>=2.28) est une bombe a retardement. Chaque pip install peut tirer une version differente, et un attaquant qui compromet PyPI peut publier une version malveillante qui sera automatiquement installee par votre pipeline.

L’epinglage strict avec verification de hash est la solution. Au lieu de requests>=2.28, votre requirements.txt doit contenir :

requests==2.32.3 \
    --hash=sha256:70761cfe03c773ceb22aa2f671b4757976145175cdfca038c02654d061d6dcc6

La commande pip install --require-hashes -r requirements.txt verifie que le hash SHA256 du paquet telecharge correspond exactement au hash enregistre. Si le contenu du paquet a ete modifie (meme d’un seul octet), l’installation echoue. C’est la protection la plus efficace contre les attaques de substitution de paquets.

Generer automatiquement les hash : utilisez pip-compile (du package pip-tools) pour generer un fichier requirements.txt avec toutes les versions epinglees et les hash :

pip install pip-tools
pip-compile --generate-hashes requirements.in -o requirements.txt

Le fichier requirements.in contient vos dependances directes avec des contraintes souples (django>=4.2,<5.0), et pip-compile resout l’arbre complet, epingle chaque version et calcule les hash. Pour les projets utilisant pyproject.toml, les alternatives modernes comme uv (de la meme equipe qu’Astral/Ruff) offrent des fonctionnalites equivalentes avec des performances superieures.

Etape 3 : Scanner les vulnerabilites connues avec les bons outils

Le scan de vulnerabilites est le coeur de la securisation des dependances. L’objectif est de detecter toute dependance affectee par une CVE connue et de la mettre a jour ou la remplacer avant qu’elle ne soit exploitee. En 2026, trois outils dominent l’ecosysteme Python.

pip-audit est l’outil officiel de la Python Packaging Authority (PyPA). Il interroge la base OSV (Open Source Vulnerabilities) maintenue par Google, qui agrege les advisories de NVD, GitHub Security Advisories, PyPI et d’autres sources. L’utilisation de base est simple : pip-audit --strict --desc. Le flag --strict fait echouer la commande (exit code non nul) si une vulnerabilite est trouvee, ce qui est essentiel pour l’integration CI/CD. Le flag --desc ajoute une description de chaque vulnerabilite trouvee.

Safety (SafetyCLI) utilise sa propre base Safety DB, qui inclut parfois des vulnerabilites non encore publiees dans les bases publiques. La version gratuite couvre les scans basiques : pip install safety && safety check. La version commerciale ajoute l’analyse de licence, le suivi historique et des rapports detailles.

Grype (Anchore) est un scanner multi-ecosysteme qui couvre Python, npm, Go, Rust, Java et les images de conteneurs. Si votre projet combine plusieurs langages, Grype offre une vue unifiee : grype dir:. --only-fixed scanne le repertoire courant et n’affiche que les vulnerabilites pour lesquelles un correctif existe.

Recommandation : executez pip-audit ET Safety en parallele dans votre pipeline CI/CD. Les deux outils utilisent des bases de donnees differentes, et la combinaison maximise la couverture de detection. Un script simple :

#!/bin/bash
set -e
echo "=== pip-audit ==="
pip-audit --strict --desc
echo "=== Safety ==="
safety check --full-report
echo "Aucune vulnerabilite detectee."

Etape 4 : Isoler les environnements avec virtualenv ou uv

L’isolation des environnements Python est une mesure de securite fondamentale que trop de developpeurs negligent encore. Sans environnement virtuel, toutes les dependances sont installees globalement dans le systeme, ce qui cree deux problemes majeurs : la contamination croisee entre projets (une dependance d’un projet peut introduire une vulnerabilite dans un autre) et l’impossibilite de maitriser exactement quels paquets sont utilises par chaque projet.

Les outils d’isolation en 2026 :

• python -m venv .venv — Le module standard, inclus dans Python. Simple et fiable, suffisant pour la majorite des projets. Activation : source .venv/bin/activate.
• uv venv .venv — Le gestionnaire de paquets ultra-rapide d’Astral (createurs de Ruff). 10 a 100x plus rapide que pip pour la resolution et l’installation des dependances. Recommande pour les gros projets.
• virtualenv .venv — L’outil historique, plus de fonctionnalites que venv (creation plus rapide, support de plusieurs versions Python), mais rarement necessaire en 2026.
• poetry et pdm — Des gestionnaires de projet complets qui integrent l’isolation, la resolution de dependances et le lock file dans un seul outil.

Regle de securite : chaque projet doit avoir son propre environnement virtuel, cree a la racine du projet (.venv/), ajoute au .gitignore, et recree a partir du requirements.txt (ou pyproject.toml) lors de chaque deploiement. Ne partagez jamais un environnement virtuel entre projets, et ne committez jamais le repertoire .venv/ dans le depot Git.

Conteneurisation : pour une isolation maximale en production, combinez l’environnement virtuel avec un conteneur Docker. L’image Docker doit utiliser une image de base minimale (python:3.12-slim), installer les dependances avec --require-hashes et executer l’application sous un utilisateur non root. Cette approche isole non seulement les dependances Python mais aussi les dependances systeme.

Etape 5 : Generer un SBOM pour la tracabilite

Un Software Bill of Materials (SBOM) est l’inventaire exhaustif et structure de tous les composants logiciels (dependances, runtimes, outils de build) qui constituent votre application. Le SBOM est a votre logiciel ce que la liste d’ingredients est a un produit alimentaire : il permet a quiconque de savoir exactement ce qui se trouve « a l’interieur ».

En 2026, le SBOM passe du « nice to have » au « must have ». Le Cyber Resilience Act (CRA) europeen, vote en 2024 et en cours d’application, imposera aux editeurs de logiciels (y compris open source commercialise) de fournir un SBOM pour chaque produit. Aux Etats-Unis, l’executive order 14028 impose deja le SBOM pour les logiciels vendus au gouvernement federal. Ne pas generer de SBOM aujourd’hui, c’est accumuler une dette de conformite qui devra etre payee demain.

Les deux formats standards sont CycloneDX (OWASP, format JSON ou XML, oriente securite) et SPDX (Linux Foundation, format JSON, RDF ou tag-value, oriente licence). Pour les projets Python, CycloneDX est generalement recommande car l’outillage est plus mature.

# Installer le generateur CycloneDX pour Python
pip install cyclonedx-bom

# Generer le SBOM depuis requirements.txt
cyclonedx-py requirements \
    -i requirements.txt \
    -o sbom.json \
    --format json \
    --schema-version 1.5

# Generer le SBOM depuis l'environnement installe
cyclonedx-py environment \
    -o sbom-env.json \
    --format json

Integration CI/CD : le SBOM doit etre genere automatiquement dans votre pipeline a chaque release et stocke comme artefact de build. Il peut aussi etre publie avec votre release sur GitHub (en piece jointe de la release). Cela permet a vos utilisateurs et a vos clients de verifier les composants de chaque version et de reagir rapidement quand une dependance est affectee par une nouvelle CVE.

Etape 6 : Integrer les checks de securite dans le pipeline CI/CD

Les etapes precedentes sont inutiles si elles ne sont pas automatisees. Un scan de dependances execute manuellement une fois par trimestre ne protege contre rien. Les vulnerabilites sont publiees quotidiennement, les attaques supply chain se produisent a tout moment, et la seule defense efficace est un controle automatise a chaque commit, chaque pull request et chaque deploiement.

Voici un exemple de workflow GitHub Actions qui integre pip-audit et Safety comme gates obligatoires avant le merge d’une pull request :

# .github/workflows/security-deps.yml
name: Securite des dependances
on:
  pull_request:
    paths:
      - "requirements*.txt"
      - "pyproject.toml"
      - "poetry.lock"
  schedule:
    - cron: "0 8 * * 1"  # Chaque lundi a 8h

jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: |
          pip install pip-audit safety
          pip install -r requirements.txt
      - name: pip-audit
        run: pip-audit --strict --desc --format json -o audit.json
      - name: Safety check
        run: safety check --full-report
      - name: SBOM
        run: |
          pip install cyclonedx-bom
          cyclonedx-py environment -o sbom.json --format json
      - uses: actions/upload-artifact@v4
        with:
          name: security-reports
          path: |
            audit.json
            sbom.json

Les points cles de cette configuration : le workflow se declenche sur chaque PR qui modifie les fichiers de dependances (pas sur chaque commit pour eviter le bruit), et aussi chaque lundi matin pour detecter les nouvelles CVE publiees pendant la semaine. Le flag --strict de pip-audit fait echouer le job si une vulnerabilite est trouvee, ce qui bloque le merge. Les rapports sont stockes comme artefacts pour l’audit trail.

Pour GitLab CI, la configuration equivalente utilise include: Security/Dependency-Scanning.gitlab-ci.yml qui active le scanner de dependances integre. Pour Jenkins, le plugin OWASP Dependency-Check offre des fonctionnalites similaires. Quel que soit l’outil CI/CD, le principe est le meme : automatiser, bloquer et reporter. Notre guide sur la securisation des pipelines CI/CD GitHub Actions couvre les aspects complementaires (protection des secrets, attestation de build).

Etape 7 : Monitorer en continu avec Dependabot et alertes automatiques

Les etapes 1 a 6 securisent vos dependances a un instant T. Mais les vulnerabilites sont publiees en continu : en 2026, une nouvelle CVE est publiee toutes les 8 minutes en moyenne (source : rapport FIRST). Votre projet peut etre parfaitement securise aujourd’hui et vulnerable demain si une nouvelle CVE est decouverte dans une de vos 150 dependances. Le monitoring continu est donc la derniere piece du puzzle.

Dependabot (GitHub natif) surveille vos fichiers de dependances et ouvre automatiquement des pull requests quand une mise a jour de securite est disponible. La configuration se fait dans .github/dependabot.yml :

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "pip"
    directory: "/"
    schedule:
      interval: "daily"
    open-pull-requests-limit: 10
    labels:
      - "dependencies"
      - "security"
    reviewers:
      - "equipe-securite"
    # Grouper les mises a jour mineures
    groups:
      minor-and-patch:
        update-types:
          - "minor"
          - "patch"

Renovate Bot (Mend, open source) est l’alternative a Dependabot avec plus de flexibilite. Il supporte tous les ecosystemes (pip, Poetry, PDM, Pipenv), permet des regles de merge automatique pour les mises a jour de patch, et offre un dashboard de suivi des dependances. Il s’installe comme une GitHub App ou se deploie en self-hosted.

GitHub Security Advisories : activez les alertes Dependabot dans les parametres de securite de votre repository. GitHub vous notifiera par email et dans l’interface des qu’une CVE affecte une de vos dependances, meme si Dependabot ne peut pas creer de PR automatique (par exemple si la mise a jour introduit un breaking change).

Strategie de merge : ne mergez pas aveuglément les PR de mise a jour. Les mises a jour de patch (ex : 2.32.2 → 2.32.3) pour des correctifs de securite peuvent etre auto-mergees apres passage des tests CI. Les mises a jour mineures (ex : 2.32 → 2.33) doivent etre revues par un developpeur. Les mises a jour majeures (ex : 2.x → 3.x) necessitent une analyse d’impact complete. Automatisez le premier cas, supervisez les deux autres. L’article sur l’audit des dependances Python et la supply chain complete ce guide avec des strategies avancees.

Checklist recapitulative : les 7 etapes en un coup d’oeil

Questions frequentes