Gérer ses dépendances, c’est traiter trois problèmes distincts : choisir les bons composants, les maintenir à jour, et protéger la chaîne d’approvisionnement contre les attaques. Cette page vous aide à identifier lequel de ces problèmes vous concerne et vous oriente vers le bon guide.
Pourquoi la gestion des dépendances est devenue critique
Section intitulée « Pourquoi la gestion des dépendances est devenue critique »Un projet logiciel moderne repose sur des dizaines, parfois des centaines de composants externes : bibliothèques, frameworks, modules, paquets système. Ces dépendances ne sont pas du code que vous avez écrit, mais du code que vous choisissez de faire tourner en production.
Ce choix a des conséquences directes sur quatre axes :
| Axe | Risque si mal géré | Exemple concret |
|---|---|---|
| Fiabilité | Incompatibilités, régressions | Une mise à jour majeure de React casse votre frontend |
| Vélocité | Dette technique, mises à jour massives | 200 dépendances obsolètes à migrer d’un coup |
| Sécurité | Vulnérabilités connues non corrigées | Heartbleed dans OpenSSL : des millions de serveurs exposés |
| Conformité | Licences incompatibles, audits échoués | Une dépendance GPL dans un produit propriétaire |
Le piège classique : ne rien faire pendant des mois, puis devoir tout mettre à jour en urgence après la publication d’une CVE critique. Les mises à jour deviennent alors risquées car elles embarquent trop de changements d’un coup.
Les trois problèmes à traiter séparément
Section intitulée « Les trois problèmes à traiter séparément »La gestion des dépendances couvre en réalité trois disciplines distinctes. Les confondre, c’est créer des angles morts.
1. Choisir ses dépendances
Section intitulée « 1. Choisir ses dépendances »Avant d’ajouter un paquet à votre projet, évaluez-le :
- Maintenance active : le projet a-t-il des releases récentes ? Des mainteneurs identifiés ?
- Surface d’attaque : combien de dépendances transitives le paquet installe-t-il ?
- Licence : est-elle compatible avec votre usage (MIT, Apache-2.0, GPL) ?
- Alternatives : existe-t-il une solution plus légère ou intégrée au langage ?
Un bon réflexe : pour chaque nouvelle dépendance, vérifiez le score sur OpenSSF Scorecard et le nombre de dépendances transitives qu’elle embarque.
2. Mettre à jour ses dépendances
Section intitulée « 2. Mettre à jour ses dépendances »C’est le quotidien de la maintenance logicielle. L’objectif est de garder un écart minimal entre les versions utilisées et les versions publiées, tout en évitant les régressions.
Les mécanismes fondamentaux à maîtriser :
- Lockfiles : fichiers qui figent les versions exactes installées
(
package-lock.json,poetry.lock,go.sum). Sans lockfile, deux installations du même projet peuvent produire des versions différentes. - Version pinning : épingler explicitement les versions dans vos fichiers de
configuration (
"react": "18.3.1"plutôt que"^18.0.0"). Le pinning strict garantit la reproductibilité, mais nécessite des mises à jour régulières. - Mises à jour manuelles vs automatiques : les mises à jour manuelles fonctionnent pour un petit projet, mais au-delà de 20-30 dépendances, l’automatisation devient indispensable pour éviter l’accumulation de dette.
- Dépendances directes vs transitives : vous déclarez
express, maisexpressinstalle lui-même 30 paquets. Une vulnérabilité dans une dépendance transitive vous affecte tout autant.
La stratégie de test est le filet de sécurité : tests unitaires, tests d’intégration et éventuellement tests end-to-end doivent passer avant de merger une mise à jour.
3. Sécuriser la chaîne d’approvisionnement
Section intitulée « 3. Sécuriser la chaîne d’approvisionnement »Ce troisième problème va bien au-delà de la simple mise à jour. Il s’agit de se protéger contre des menaces actives :
| Menace | Description | Exemple |
|---|---|---|
| Typosquatting | Un paquet au nom presque identique à un paquet populaire | colourama au lieu de colorama |
| Dépendance compromise | Un mainteneur légitime injecte du code malveillant | Incident event-stream (npm, 2018) |
| Mainteneur compromis | Le compte d’un mainteneur est piraté | Prise de contrôle de paquets populaires |
| Registre compromis | Le serveur de distribution est lui-même attaqué | Attaque sur le registre PHP Packagist |
| Build pipeline compromis | Le build produit un artefact différent du code source | Attaque SolarWinds (2020) |
Ces menaces nécessitent des réponses spécifiques : inventaire complet (SBOM), analyse de vulnérabilités, vérification de provenance (SLSA, Sigstore), et politiques CI/CD qui bloquent les composants non vérifiés.
Inventorier et contrôler ses dépendances
Section intitulée « Inventorier et contrôler ses dépendances »Entre la maintenance quotidienne et la sécurité supply chain se trouve une étape charnière : savoir exactement ce que contient votre application.
SBOM (Software Bill of Materials)
Section intitulée « SBOM (Software Bill of Materials) »Un SBOM est l’inventaire complet de tous les composants logiciels de votre application : dépendances directes, transitives, bibliothèques système. C’est l’équivalent de la liste d’ingrédients sur un emballage alimentaire.
En pratique, un SBOM vous permet de :
- Réagir vite quand une CVE est publiée : « est-ce que j’utilise ce composant, et où ? »
- Répondre aux audits de conformité (réglementations CRA, NIS2, exigences clients)
- Détecter les licences incompatibles avant la mise en production
Des outils comme Syft génèrent un SBOM automatiquement à partir de votre code source, de vos images conteneurs ou de vos lockfiles.
VEX (Vulnerability Exploitability eXchange)
Section intitulée « VEX (Vulnerability Exploitability eXchange) »Le SBOM vous dit ce que vous avez. Le VEX vous dit ce qui vous concerne vraiment. Face à une CVE affectant un composant de votre SBOM, le VEX permet de documenter si la vulnérabilité est exploitable dans votre contexte ou non.
Scans de vulnérabilités en CI/CD
Section intitulée « Scans de vulnérabilités en CI/CD »Trivy ou Dependency-Track peuvent scanner vos dépendances à chaque commit et bloquer un merge si une vulnérabilité critique est détectée. Cette approche transforme la sécurité des dépendances d’une vérification ponctuelle en un contrôle continu.
Automatiser les mises à jour
Section intitulée « Automatiser les mises à jour »Au-delà de 20 dépendances, la mise à jour manuelle devient irréaliste. Deux outils dominent le marché :
| Critère | Renovate | Dependabot |
|---|---|---|
| Plateformes | GitHub, GitLab, Bitbucket, Azure DevOps, Gitea | GitHub uniquement |
| Gestionnaires supportés | 90+ (npm, pip, Docker, Terraform, Helm…) | ~20 écosystèmes |
| Configuration | Très granulaire (packageRules, scheduling, grouping) | Simple, peu personnalisable |
| Automerge | Oui, avec conditions | Oui, via GitHub Actions |
| Hébergement | SaaS (Mend) ou self-hosted | Intégré à GitHub |
Pour la plupart des équipes, Renovate offre plus de flexibilité, surtout dans un contexte multi-plateforme ou avec de l’infrastructure as code.
À retenir
Section intitulée « À retenir »- La gestion des dépendances couvre trois problèmes distincts : choisir, mettre à jour, sécuriser la supply chain
- Les lockfiles et le version pinning sont la base de la reproductibilité
- Les dépendances transitives représentent souvent la plus grande surface d’attaque
- L’automatisation (Renovate, Dependabot) est indispensable au-delà de 20 dépendances
- Le SBOM est le point de départ pour toute démarche de sécurité : on ne protège que ce qu’on inventorie
- La sécurité supply chain va bien au-delà des mises à jour : elle couvre les attaques actives sur les registres, mainteneurs et pipelines
- Un pipeline CI/CD avec scan de vulnérabilités transforme la sécurité des dépendances en contrôle continu