Comment auditer les dependances open source de votre projet en 7 etapes

Le rapport OSSRA 2026 de Synopsys, publie en avril, confirme ce que chaque developpeur constate empiriquement : 87 % des bases de code commerciales contiennent des dependances open source avec des vulnerabilites connues. Et ce chiffre ne couvre que les CVE — il ne dit rien des licences incompatibles, des projets abandonnes, ou des paquets dont la provenance n'a jamais ete verifiee.

Chez D-Open, chaque audit de projet que nous menons — que ce soit pour une startup parisienne, une ESN lyonnaise ou un editeur nantais — commence par la meme question : savez-vous exactement ce que contient votre arbre de dependances ? La reponse est presque toujours non. Ce guide formalise la methode que nous appliquons.

Etape 1 : Generer un inventaire complet (SBOM)

Un Software Bill of Materials (SBOM) est a votre logiciel ce qu'une liste d'ingredients est a un produit alimentaire. Sans cet inventaire, toute analyse en aval est partielle.

L'objectif de cette premiere etape est de produire un fichier structure listant chaque composant open source present dans votre projet, avec sa version exacte, sa licence declaree et son origine. Les deux formats standards sont SPDX (Linux Foundation) et CycloneDX (OWASP).

Pour un projet Node.js :

# Avec Syft (recommande, multi-ecosysteme)
syft dir:. -o spdx-json > sbom.spdx.json

# Avec npm natif (depuis npm 10)
npm sbom --sbom-format cyclonedx > sbom.cdx.json

# Avec CycloneDX CLI
cdxgen -o sbom.cdx.json

Pour un projet Python :

# Syft sur un requirements.txt ou un pyproject.toml
syft dir:. -o cyclonedx-json > sbom.cdx.json

# pip-audit genere un SBOM en passant
pip-audit --format=cyclonedx-json -o sbom.cdx.json

Le piege le plus courant a cette etape est d'oublier les dependances non declarees. Un fichier JavaScript copie dans vendor/, un binding C compile localement, un module Go remplace par un fork prive — aucun de ces elements n'apparaitra dans un SBOM genere a partir du seul lockfile. Syft, en scannant le systeme de fichiers complet, en detecte une partie, mais pas tout. L'etape 2 complete cette detection.

Etape 2 : Cartographier l'arbre de dependances transitives

Votre package.json declare peut-etre 40 dependances. Votre node_modules/ en contient probablement 800. La difference, ce sont les dependances transitives — les dependances de vos dependances, recursives jusqu'a sept ou huit niveaux de profondeur.

Ce sont ces dependances profondes qui concentrent le risque. L'attaque supply chain sur 169 paquets TanStack de mai 2026 ciblait une dependance de troisieme niveau. L'incident Laravel Lang touchait des paquets que personne n'avait audites parce qu'ils etaient trop profonds dans l'arbre.

# Arbre npm complet (attention : la sortie est volumineuse)
npm ls --all > dependency-tree.txt

# Arbre Python
pipdeptree --warn silence > dependency-tree.txt

# Arbre Go
go mod graph | head -200

Ce que vous cherchez dans cet arbre :

• Les dependances dupliquees a des versions differentes — signe d'un conflit latent.
• Les dependances profondes avec peu de mainteneurs — le maillon faible classique.
• Les dependances fantomes — presentes dans node_modules/ mais absentes du lockfile (installation manuelle oubliee).

Etape 3 : Analyser les licences et detecter les incompatibilites

La conformite juridique est le parent pauvre de la plupart des audits techniques. Pourtant, utiliser une dependance GPL dans un produit distribue sous licence MIT cree une obligation juridique que l'ignorance ne suspend pas.

L'outil de reference est license-checker pour npm, ou pip-licenses pour Python. Les deux produisent un rapport lisible qui classe chaque dependance par type de licence.

# npm
npx license-checker --summary --production

# Python
pip-licenses --format=table --with-urls --order=license

# Multi-ecosysteme avec Scancode
scancode -l --json-pp licenses.json .

Ce que vous cherchez a cette etape :

• Les licences copyleft fort (GPL, AGPL) dans un projet distribue sous licence permissive.
• Les licences inconnues ou personnalisees — un paquet sans licence explicite est juridiquement un risque maximal (copyright complet par defaut).
• Les licences multiples — certains paquets offrent un choix (MIT OR Apache-2.0). Documentez lequel vous choisissez.
• Les licences incompatibles entre elles dans votre arbre — une dependance Apache 2.0 qui tire une sous-dependance GPLv2 pose un probleme que ni l'une ni l'autre n'a cree seule.

Pour les equipes que nous accompagnons a Lyon et Toulouse, la decouverte la plus frequente a cette etape est la presence de paquets sans licence declaree. Sur un audit recent d'un projet SaaS toulousain, 14 dependances transitives n'avaient aucun champ license dans leur package.json. Chacune represente un risque juridique non quantifie, comme le detaille notre guide complet sur les licences open source.

Etape 4 : Scanner les vulnerabilites connues (CVE)

C'est l'etape la plus connue, et paradoxalement la plus mal executee. La plupart des equipes lancent un npm audit de temps en temps, lisent les resultats en diagonale, et concluent que tout va bien parce que les CVE sont classees « moderate ».

Le probleme est triple. Premierement, npm audit ne couvre que les CVE publiees dans la GitHub Advisory Database — pas celles d'OSV, NVD ou des bases communautaires. Deuxiemement, la classification de severite est celle du paquet amont, pas la votre : une CVE « moderate » dans un parser XML devient critique si votre application traite du XML non fiable. Troisiemement, les faux positifs frequents creent une fatigue d'alerte qui masque les vrais problemes.

# Multi-source (recommande)
trivy fs --scanners vuln --severity HIGH,CRITICAL .

# npm avec OSV (plus complet que npm audit)
osv-scanner --lockfile=package-lock.json

# Python
pip-audit --desc --fix --dry-run

# Docker images
trivy image --severity HIGH,CRITICAL monapp:latest

Notre recommandation : utilisez au moins deux scanners avec des bases de donnees differentes. Trivy (Aqua Security) couvre NVD, GitHub Advisories, Red Hat et plusieurs bases vendor. osv-scanner (Google) couvre OSV, qui agrege des sources que Trivy ne couvre pas toujours. La combinaison des deux offre la meilleure couverture que nous ayons observee en pratique. Les equipes parisiennes qui suivent le cadre CISA publie en aout 2026 retrouveront ici la meme recommandation de defense en profondeur.

Etape 5 : Evaluer la sante et la maintenance des projets amont

Une dependance peut n'avoir aucune CVE connue et pourtant representer un risque majeur. Si le mainteneur unique a disparu depuis 18 mois, si le dernier commit date de 2023, si les issues critiques s'accumulent sans reponse — le probleme n'est pas technique, il est organisationnel.

Les signaux a verifier pour chaque dependance critique (celles dans votre chemin de production) :

• Date du dernier commit et de la derniere release. Plus de 12 mois sans activite sur un projet actif est un signal d'alerte.
• Nombre de mainteneurs actifs. Un seul mainteneur est un single point of failure. L'incident simple-git CVE-2026-6951 a touche un paquet maintenu par une seule personne.
• Ratio issues ouvertes / fermees. Un ratio qui augmente indique un projet qui se noie.
• Presence d'un SECURITY.md. Un projet sans politique de divulgation de vulnerabilites est un projet qui ne traitera pas les rapports de securite correctement.
• Transferts de propriete recents. Un paquet npm dont le mainteneur a change recemment est un vecteur d'attaque supply chain classique, comme le montrent les incidents Phantom Gyp de juin 2026.

Les outils Socket.dev et deps.dev (Google) automatisent une partie de cette verification. Pour un audit approfondi, nous utilisons aussi OpenSSF Scorecard, qui attribue un score composite a chaque repository GitHub.

Etape 6 : Verifier la provenance et l'integrite des paquets

Cette etape est la plus negligee et pourtant la plus critique dans le contexte actuel des attaques supply chain. En 2026, le rapport FIRST prevoit 66 000 CVE, et une part croissante provient de paquets malveillants publies sous des noms legitimes.

La question n'est plus seulement « cette dependance a-t-elle des vulnerabilites ? » mais « cette dependance est-elle bien celle que vous croyez avoir installee ? »

Les verifications essentielles :

• Integrite du lockfile. Votre package-lock.json ou yarn.lock contient les hashes SHA-512 de chaque paquet. Verifiez qu'il n'a pas ete modifie manuellement : npm ci (au lieu de npm install) echoue si les hashes ne correspondent pas.
• Attestations de provenance npm. Depuis npm 10, les paquets peuvent etre publies avec des attestations Sigstore qui lient le paquet publie au commit source exact. Verifiez : npm audit signatures.
• Comparaison source / distribue. Pour les dependances critiques, comparez le code publie sur npm avec le code source sur GitHub. Des outils comme diffoscope automatisent cette comparaison.

# Verifier les signatures npm
npm audit signatures

# Verifier l'integrite via le lockfile
npm ci --ignore-scripts  # echoue si les hashes different

# Scanner les comportements suspects (Socket.dev CLI)
socket scan create --repo . --report

Etape 7 : Automatiser la remediation et la surveillance continue

Un audit ponctuel est utile. Un audit ponctuel sans suivi est un gaspillage. Les dependances evoluent chaque jour : nouvelles versions, nouvelles CVE, nouveaux transferts de propriete. Votre audit du lundi est obsolete le vendredi.

La derniere etape transforme les 6 precedentes en processus continu :

Dans votre pipeline CI/CD :

• Ajoutez trivy fs et osv-scanner comme etapes du pipeline. Faites echouer le build sur les CVE HIGH/CRITICAL.
• Ajoutez license-checker avec une liste blanche de licences acceptees. Faites echouer le build si une licence non approuvee apparait.
• Generez un SBOM a chaque release et archivez-le avec l'artefact de build.

En surveillance continue :

• Configurez Dependabot ou Renovate pour les mises a jour automatiques. Nous detaillons la configuration optimale dans notre guide dedie.
• Activez les alertes Socket.dev pour detecter les comportements suspects en temps reel (obfuscation, appels reseau, acces filesystem).
• Planifiez un audit complet (les 7 etapes) chaque trimestre.

Questions frequentes