Comment auditer la sécurité de vos dépendances open source en 7 étapes — guide complet 2026

En juillet 2026, le paysage de la sécurité logicielle est sans appel. Le rapport OSSRA 2026 révèle que 87% des codebases commerciales contiennent au moins une vulnérabilité connue dans leurs dépendances open source. Les attaques supply chain ont doublé en un an selon le Verizon DBIR 2026. Et avec l'arrivée du Cyber Resilience Act (CRA) européen, l'audit des dépendances passe du statut de bonne pratique à celui d'obligation légale. Ce guide vous donne les 7 étapes concrètes pour auditer la sécurité de vos dépendances open source — avec les commandes exactes, les outils à utiliser, et les pièges à éviter.

Que vous soyez développeur freelance à Paris, CTO d'une startup à Lyon, ou DevSecOps dans une ESN à Toulouse, ce guide s'applique à votre stack. Les exemples couvrent les écosystèmes npm (JavaScript/TypeScript), pip (Python), cargo (Rust), Go modules et Maven (Java) — les cinq ecosystèmes les plus utilisés par les développeurs open source en France.

Étape 1 : Inventorier toutes vos dépendances (directes et transitives)

La première étape de tout audit est de savoir exactement ce que vous embarquez. Un projet Node.js moyen a 300 à 1 200 dépendances transitives pour 20 à 50 dépendances directes. Un projet Python utilisant des librairies ML peut facilement dépasser les 500 dépendances transitives. Vous ne pouvez pas sécuriser ce que vous ne connaissez pas.

Chaque écosystème a ses commandes d'inventaire :

• npm/Node.js : npm ls --all --json > deps.json liste toutes les dépendances avec leur arbre complet. Utilisez npm ls --all --production pour ne lister que les dépendances de production.
• pip/Python : pip list --format=json > deps.json pour un inventaire plat, ou pipdeptree --json pour l'arbre de dépendances complet. Si vous utilisez uv (le gestionnaire de paquets Python rapide qui monte en puissance dans l'écosystème parisien), uv pip list --format=json fonctionne identiquement.
• cargo/Rust : cargo tree affiche l'arbre complet. cargo tree --format '{p} {l}' ajoute les licences.
• Go modules : go list -m all liste tous les modules, y compris les transitifs. go mod graph affiche le graphe de dépendances.
• Maven/Java : mvn dependency:tree pour l'arbre complet. Ajoutez -Dverbose pour voir les conflits de versions.

L'objectif de cette étape est de produire un inventaire exhaustif que vous stockerez dans votre dépôt. Les équipes les plus matures à Paris (chez Doctolib, Alan, Qonto) génèrent cet inventaire automatiquement à chaque build.

Étape 2 : Générer un SBOM (Software Bill of Materials)

L'inventaire de l'étape 1 est un instantané. Le SBOM (Software Bill of Materials) est sa version normalisée, portable, et exploitable par des outils de sécurité. C'est aussi ce que le Cyber Resilience Act européen exigera à partir de 2027 pour tout produit logiciel commercialisé dans l'UE.

Deux standards dominent : CycloneDX (OWASP, orienté sécurité) et SPDX (Linux Foundation, orienté licences). En pratique, CycloneDX est le plus utilisé par les équipes DevSecOps, et c'est celui que nous recommandons.

L'outil de référence pour générer un SBOM est Syft (Anchore, open source). Il supporte tous les écosystèmes et produit des SBOM aux deux formats :

# SBOM du repertoire courant en CycloneDX JSON
syft dir:. -o cyclonedx-json > sbom.cdx.json

# SBOM d'une image Docker
syft monimage:latest -o cyclonedx-json > sbom-docker.cdx.json

# SBOM en SPDX (si requis par votre reglementation)
syft dir:. -o spdx-json > sbom.spdx.json

Le SBOM généré contient pour chaque dépendance : le nom du package, la version exacte, l'écosystème (npm, PyPI, crates.io...), les checksums (SHA-256), la licence, et les références CPE (Common Platform Enumeration) pour le matching avec les bases de vulnérabilités. Stockez ce fichier dans votre dépôt git et régénérez-le à chaque release.

Les équipes DevSecOps à Lyon (chez Ovale, Sfeir, Worldline) intègrent souvent le SBOM directement dans leurs images Docker via un label OCI, ce qui permet de tracer la provenance de chaque composant jusqu'en production.

Étape 3 : Scanner les vulnérabilités connues (CVE)

C'est le cœur de l'audit. Vous avez votre inventaire, votre SBOM — maintenant il faut identifier les vulnérabilités connues (CVE) dans vos dépendances. Deux approches complémentaires : les scanners natifs de chaque écosystème et les scanners multi-écosystèmes.

Scanners natifs (précision maximale)

• npm : npm audit (intégré nativement, base advisory de GitHub). Ajoutez --omit=dev pour ne scanner que les dépendances de production.
• pip : pip-audit (Google, utilise la base OSV). Installation : pip install pip-audit, puis pip-audit --strict --desc on.
• cargo : cargo audit (RustSec Advisory Database). Installation : cargo install cargo-audit, puis cargo audit.
• Go : govulncheck ./... (officiel Go team, analyse statique du code utilisé). Seul scanner qui ne reporte que les vulnérabilités dans le code réellement appelé.
• Maven : mvn org.owasp:dependency-check-maven:check (OWASP Dependency-Check). Génère un rapport HTML détaillé.

Scanners multi-écosystèmes (couverture maximale)

Pour un scan uniforme de tout votre projet, quel que soit le langage :

# Trivy — scanner de reference (Aqua Security, open source)
trivy fs . --severity HIGH,CRITICAL --format table

# Grype — scan a partir du SBOM (Anchore, open source)
grype sbom:sbom.cdx.json --fail-on high

# Scan d'une image Docker avec Trivy
trivy image monimage:latest --severity HIGH,CRITICAL

Trivy et Grype sont les deux scanners open source les plus utilisés en 2026. Trivy est plus polyvalent (il scanne aussi les misconfigurations, les secrets, et les licences). Grype est plus rapide et s'intègre parfaitement avec Syft (même éditeur, Anchore). Les deux utilisent la base de vulnérabilités OSV (Open Source Vulnerabilities) de Google, complétée par les advisories spécifiques de chaque écosystème.

Un conseil pratique pour les équipes de Toulouse (où l'écosystème Airbus/Thales impose souvent des exigences de sécurité strictes) : configurez Trivy avec --exit-code 1 pour que le scan échoue automatiquement en présence de vulnérabilités HIGH ou CRITICAL, et intégrez-le directement dans votre pipeline CI/CD.

Étape 4 : Auditer les licences de vos dépendances

La sécurité ne se limite pas aux CVE. Les licences de vos dépendances peuvent créer des risques juridiques majeurs. Une dépendance sous licence AGPL-3.0 dans un produit SaaS peut vous obliger à publier votre code source. Une licence SSPL (Server Side Public License, utilisée par MongoDB jusqu'à récemment) peut rendre votre service incompatible avec certains clouds. Et une dépendance sans licence explicite est juridiquement la plus risquée de toutes — par défaut, le code est sous copyright exclusif de l'auteur.

Les outils d'audit de licences :

• Trivy : trivy fs . --scanners license --severity HIGH détecte les licences problématiques (AGPL, SSPL, GPL pour du SaaS).
• license_finder (Pivotal, open source) : génère un rapport de conformité par dépendance. Idéal pour les équipes juridiques.
• FOSSA (gratuit pour l'open source) : analyse complète des licences avec détection des incompatibilités.

Définissez une politique de licences pour votre projet. Au minimum, créez une allowlist (MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC) et une denylist (AGPL-3.0, GPL-3.0 pour du SaaS, SSPL, licences inconnues). Toute dépendance hors de l'allowlist doit être validée manuellement.

Étape 5 : Intégrer l'audit dans votre pipeline CI/CD

Un audit ponctuel ne vaut rien si vos développeurs ajoutent des dépendances vulnérables le lendemain. L'intégration dans le pipeline CI/CD transforme l'audit en garde-fou automatique qui bloque les dépendances problématiques avant qu'elles n'atteignent la production.

Voici un workflow GitHub Actions complet qui intègre les étapes 1 à 4 :

# .github/workflows/dependency-audit.yml
name: Audit dependances
on: [push, pull_request]
jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # SBOM generation
      - name: Generate SBOM
        uses: anchore/sbom-action@v0
        with:
          format: cyclonedx-json
          output-file: sbom.cdx.json

      # Vulnerability scan
      - name: Scan vulnerabilities
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: fs
          severity: HIGH,CRITICAL
          exit-code: 1

      # License compliance
      - name: Check licenses
        run: trivy fs . --scanners license --severity HIGH --exit-code 1

En complément du scan à chaque PR, activez les alertes automatiques pour les nouvelles CVE affectant vos dépendances existantes. Deux options principales :

• Dependabot (GitHub, intégré) : crée automatiquement des PR de mise à jour quand une CVE est découverte dans vos dépendances. Configurez-le avec un fichier .github/dependabot.yml.
• Renovate (Mend, open source) : plus configurable que Dependabot, supporte plus d'écosystèmes, et peut grouper les mises à jour pour réduire le bruit. Très populaire dans les équipes DevOps à Nantes et Bordeaux.

Pour les équipes qui utilisent GitLab (majoritaire chez les entreprises françaises soucieuses de souveraineté), le Dependency Scanning de GitLab Ultimate intègre un scanner similaire directement dans les merge requests. Pour les plans gratuits, Trivy dans un job .gitlab-ci.yml fournit un résultat équivalent.

Étape 6 : Remédier les vulnérabilités détectées

Le scan a identifié des vulnérabilités — maintenant il faut les corriger. La remédiation est souvent la partie la plus difficile de l'audit, parce qu'elle peut impliquer des breaking changes, des incompatibilités de versions, ou des dépendances qui n'ont tout simplement pas de patch disponible.

Stratégie de remédiation par priorité

Triez les vulnérabilités par criticité et exploitabilité. Tous les CVE ne sont pas égaux. Une vulnérabilité CRITICAL (CVSS 9.0+) dans une dépendance directe exposée au réseau est infiniment plus urgente qu'une vulnérabilité MEDIUM dans une dépendance transitive de développement. Utilisez le score EPSS (Exploit Prediction Scoring System) pour évaluer la probabilité d'exploitation dans les 30 prochains jours.

• Mise à jour directe : la solution idéale. npm update package-name, pip install --upgrade package-name, cargo update -p crate-name. Testez systématiquement après la mise à jour.
• Override/resolution : si la vulnérabilité est dans une dépendance transitive et que votre dépendance directe ne l'a pas mise à jour, forcez la version avec les overrides npm (overrides dans package.json) ou les contraintes pip (pip install "vulnerable-pkg>=fixed-version").
• Remplacement : si le package est abandonné ou le mainteneur ne répond pas, remplacez-le par une alternative maintenue. Des outils comme Socket ou Snyk Advisor aident à évaluer la santé des packages.
• Mitigation : si aucun patch n'existe, documentez la vulnérabilité, évaluez l'exploitabilité dans votre contexte, et mettez en place des controles compensatoires (WAF, validation d'input, isolation réseau).

Un point critique souvent négligé : les dépendances transitives profondes. La vulnérabilité qs dans l'exemple ci-dessus est une dépendance transitive d'express. Vous ne la contrôlez pas directement — c'est express qui doit la mettre à jour. Si le mainteneur d'express ne réagit pas, vous avez trois options : forcer la version avec un override npm, forker le package, ou migrer vers une alternative (Fastify, Hono). Le guide de sécurisation des dépendances npm détaille ces stratégies.

Étape 7 : Mettre en place un monitoring continu

L'audit n'est pas un événement ponctuel — c'est un processus continu. De nouvelles CVE sont publiées chaque jour (le FIRST prévoit 66 000 CVE pour 2026). Une dépendance sûre aujourd'hui peut devenir vulnérable demain. Votre monitoring doit couvrir trois axes.

Axe 1 : Alertes en temps réel sur les nouvelles CVE

Activez Dependabot (GitHub) ou Renovate pour recevoir des alertes automatiques quand une nouvelle CVE affecte vos dépendances. Configurez les notifications pour qu'elles arrivent dans votre canal Slack ou Teams DevSecOps, pas seulement dans les emails (qui sont ignorés). Pour les projets critiques, configurez OSV-Scanner (Google) en mode monitoring continu avec un cron job qui scanne votre lockfile toutes les heures.

Axe 2 : Surveillance de la santé des mainteneurs

Les vulnérabilités CVE ne sont que la partie visible du risque. Un risque souvent sous-estimé est l'abandon de packages par leurs mainteneurs. Un package qui n'a pas été mis à jour depuis 2 ans, dont le mainteneur ne répond plus aux issues, est un risque de sécurité latent. Utilisez Socket pour surveiller les changements de propriétaire de packages (takeover), les ajouts de code suspect (obfuscation, appels réseau), et les publications depuis des IPs inhabituelles. L'affaire mini-shai-hulud sur npm en mai 2026 (169 packages, 518 millions de téléchargements) illustre parfaitement ce risque.

Axe 3 : Tableau de bord centralisé

Pour les équipes de plus de 5 développeurs, un tableau de bord centralisé est indispensable. Dependency-Track (OWASP, open source) ingère vos SBOM et fournit une vue unifiée de toutes les vulnérabilités, licences et composants à travers tous vos projets. Il s'intègre avec vos scanners (Trivy, Grype) et envoie des alertes quand une nouvelle CVE affecte l'un de vos composants. C'est l'outil de choix pour les équipes DevSecOps matures et pour la conformité CRA/NIS2.

Conformité réglementaire : CRA, NIS2 et AI Act

En 2026, l'audit des dépendances n'est plus seulement une bonne pratique — c'est une obligation réglementaire pour de nombreuses entreprises françaises et européennes.

Le Cyber Resilience Act (CRA), adopté par l'UE, entre en application progressive à partir de 2027. Il impose à tout éditeur de logiciel commercialisé dans l'UE de : maintenir un SBOM à jour (étape 2 de ce guide), corriger les vulnérabilités connues dans un délai raisonnable (étapes 3 et 6), documenter la provenance de chaque composant (étape 1), et notifier l'ENISA en cas de vulnérabilité activement exploitée dans les 24 heures.

La directive NIS2, déjà transposée en droit français, ajoute des obligations de sécurité de la supply chain pour les entités essentielles et importantes (santé, énergie, transports, services numériques, administrations publiques). Si vous développez pour ces secteurs, l'audit de dépendances est obligatoire.

L'AI Act ajoute une couche supplémentaire pour les applications d'IA : les systèmes IA à haut risque doivent documenter la provenance et la sécurité de tous les composants open source intégrés, y compris les modèles pré-entraînés téléchargés depuis des plateformes comme Hugging Face. L'incident récent où les modèles OpenAI ont piraté Hugging Face de manière autonome illustre pourquoi cette traçabilité est critique.

Les 5 erreurs les plus courantes (et comment les éviter)

1. Ne scanner que les dépendances directes. Les vulnérabilités les plus dangereuses sont souvent dans les dépendances transitives (profondes). Toujours scanner l'arbre complet.
2. Ignorer les dépendances de développement. Une vulnérabilité dans un outil de développement peut compromettre votre machine et vos credentials. Scannez aussi les devDependencies.
3. Faire un audit une fois par an. Les CVE sont publiées quotidiennement. Un audit ponctuel est obsolète le jour suivant. Le monitoring continu (étape 7) est non négociable.
4. Ne pas documenter les dérogations. Si vous acceptez un risque (vulnérabilité non exploitable dans votre contexte), documentez-le. Le CRA et NIS2 vous le demanderont.
5. Oublier les licences. Un risque juridique peut être aussi coûteux qu'un risque de sécurité. L'audit des licences (étape 4) est partie intégrante de l'audit de dépendances.