Dependabot suffit-il pour sécuriser vos dépendances ?
Par l'équipe Lysbor · publié le · 4 min de lecture
Si votre code est sur GitHub, Dependabot est probablement déjà activé. Il est gratuit, il ne demande aucune installation, et il ouvre tout seul des pull requests pour mettre à jour les dépendances vulnérables. Pour beaucoup d'équipes, c'est le premier réflexe, et c'est un bon réflexe. La question est de savoir à partir de quand il ne suffit plus.
Dependabot, c'est le détecteur de fumée de chaque pièce. Il sonne quand il y a de la fumée dans sa pièce. Il ne sait pas combien de pièces compte la maison, il ne tient pas le registre des alertes passées, et il ne remplit pas le formulaire de l'assureur.
Ce que fait Dependabot
- Les alertes (Dependabot alerts) : à partir du graphe de dépendances du dépôt et de la GitHub Advisory Database, il signale les dépendances touchées par une vulnérabilité connue.
- Les mises à jour de sécurité (security updates) : il ouvre une pull request qui monte le paquet vulnérable vers une version corrigée.
- Les mises à jour de version (version updates) : il peut aussi proposer régulièrement les nouvelles versions, même sans vulnérabilité.
Il couvre les principaux écosystèmes (npm, pip, Maven, Gradle, NuGet, RubyGems, Composer, Go, Cargo…) et peut mettre à jour les références d'images dans les Dockerfile et certains manifestes.
Ses limites en pratique
1. Il ne scanne pas vos images Docker
Dependabot peut proposer une nouvelle version de l'image de base citée dans votre Dockerfile, mais il n'analyse pas le contenu de l'image construite : les paquets Debian, Alpine ou Ubuntu qu'elle contient ne sont pas confrontés aux bases de vulnérabilités. Pour une application conteneurisée, c'est souvent la moitié du risque.
2. Il raisonne dépôt par dépôt
Chaque dépôt a ses alertes. Il n'existe pas, dans l'offre gratuite, de vue consolidée qui réponde à « quelles applications de l'entreprise sont touchées par cette CVE ? ». Des vues d'ensemble existent au niveau organisation avec les offres payantes de sécurité de GitHub.
3. Il ne trace pas les décisions de façon exploitable pour un audit
Vous pouvez ignorer une alerte en indiquant une raison, mais il n'existe ni politique de délais, ni mesure de leur respect, ni rapport qu'un auditeur NIS2 ou ISO 27001 pourrait lire.
4. Il ne priorise pas vraiment
Chaque vulnérabilité devient une alerte, souvent une pull request. Sur un projet un peu ancien, cela donne des dizaines de PR que personne ne fusionne. Sans signal d'exploitation réelle (KEV, EPSS), difficile de savoir laquelle traiter en premier.
5. Il peut introduire le risque qu'il combat
Une PR de mise à jour automatique propose par définition des versions récentes. Or les paquets malveillants publiés après la compromission d'un mainteneur sont justement des versions récentes. Sans règle d'âge minimum ni vérification avant fusion, une PR Dependabot fusionnée trop vite peut faire entrer le problème.
6. Il est lié à GitHub
Si une partie de votre code est sur GitLab, Bitbucket ou un serveur interne, elle échappe à Dependabot.
Tableau récapitulatif
| Besoin | Dependabot (gratuit) | Dependabot + Lysbor |
|---|---|---|
| Alerte sur une dépendance vulnérable | oui, par dépôt | oui, tous projets confondus |
| PR de correction automatique | oui | oui (Dependabot) |
| Paquets système des images Docker | non | oui |
| Code hors GitHub | non | oui |
| Priorisation par exploitation réelle (KEV, EPSS) | limitée | oui, plan de correction ordonné |
| Blocage des paquets malveillants avant fusion | partiel | garde de pull request, âge minimum |
| Décisions tracées et délais mesurés | non | oui |
| Rapport pour un client ou un auditeur | non | PDF NIS2 et ISO 27001 |
La bonne combinaison
Nous recommandons de garder Dependabot. Il fait très bien une chose : proposer la pull request de correction. Ajoutez par-dessus ce qui lui manque :
- un inventaire consolidé de toutes les applications et de leurs images ;
- une surveillance quotidienne qui n'alerte que sur le nouveau, avec priorisation par exploitation réelle ;
- une vérification bloquante sur les PR qui ajoutent ou montent des dépendances ;
- la trace des décisions et un rapport pour l'auditeur.
C'est le rôle de Lysbor, qui fonctionne à côté de Dependabot sans le remplacer : Lysbor vous dit lesquelles des PR de Dependabot comptent vraiment, dans quel ordre, et garde la preuve.
Questions fréquentes
Dependabot est-il gratuit ?
Oui, les alertes et les mises à jour de sécurité Dependabot sont gratuites sur GitHub, y compris pour les dépôts privés. Certaines fonctions avancées de sécurité de GitHub relèvent de ses offres payantes.
Dependabot détecte-t-il les vulnérabilités des images Docker ?
Non. Il peut mettre à jour la référence de l'image de base dans un Dockerfile, mais il n'analyse pas les paquets présents dans l'image. Il faut pour cela un scanner d'image (Trivy, Grype, Syft et une base de vulnérabilités) ou un service qui l'intègre.
Faut-il désactiver Dependabot si on utilise un autre outil ?
Non. Ses pull requests de correction restent très pratiques. L'important est de décider qui fait quoi : Dependabot propose les corrections, l'autre outil priorise, contrôle et prouve.