Dependabot : l'essentiel sur l'outil de mise à jour de dépendances de GitHub
Depuis juin 2020, GitHub intègre nativement Dependabot, un outil de gestion de mises à jour des paquets dans les dépôts publics et privés. Dans cet article, nous expliquons son fonctionnement, ses avantages et ses limites.
La multiplication des logiciels et des librairies open source a provoqué un nouvel essor de l’IT, mais présente également un risque en matière de cybersécurité. GitHub se doit de proposer des outils pour aider les développeurs à gérer les failles et les vulnérabilités dans leur supply chain.
« Nous sommes le foyer de la plupart des logiciels libres. Et nous pensons que cela nous place dans une position unique qui nous permet d’influer sur la sécurité de l’ensemble de la chaîne d’approvisionnement des logiciels », déclare Justin Hutchings, directeur Product Management chez GitHub.
Aussi, l’entreprise doit faire face à des publics différents. « Vous avez parfois des développeurs amateurs pour qui la sécurité n’est pas du tout leur préoccupation. […] Mais nous avons aussi tous ces clients qui sont des entreprises du Fortune 500 ou des entités gouvernementales qui sont extrêmement soucieuses de la sécurité. Et donc le défi est de construire un ensemble de produits qui peuvent répondre aux besoins de ces deux sortes de développeurs », ajoute le responsable.
Dependabot motorise les mises à jour de dépendances sur GitHub
En 2019, GitHub a acquis Dependabot, un logiciel sous licence propriétaire, mais ouvert (Prosperity Public License) destiné à la mise à jour des dépendances depuis des gestionnaires de paquets (pip, Maven, Terraform, Gradle, yarn, bundler, Docker, ELM, NuGet, etc.) au sein de dépôts publics et privés. Il est accessible nativement depuis le logiciel de gestion de développement depuis juin 2020.
Dependabot aide à scanner les fichiers de dépendances associés aux langages Go, Ruby, Python, JavaScript, Java, .NET, PHP, Elixir et Rust, afin de vérifier s’ils sont à jour ou soumis à des vulnérabilités.
En cas de problèmes, le service envoie des pulls requests afin de signifier aux développeurs, score de confiance à l’appui, une mise à jour disponible. Le développeur réalise les tests, vérifie le changelog lié à la mise à jour de la bibliothèque ciblée et accepte ou ignore le changement de version qui sera réalisé automatiquement. Les tests peuvent être eux aussi appliqués de manière automatisée.
D’ailleurs, GitHub et GitHub Enterprise ne sont pas les seuls outils de gestion de versions de code compatible. Il est possible de l’employer sur GitLab et Azure DevOps, par exemple.
Dependency Graph et Review
Dans GitHub, « Les données de Dependabot s’appuient en réalité sur plusieurs services », indique Justin Hutchings. « Nous avons un service appelé le graphe de dépendances (Dependency Graph). Ce qu’il fait, c’est qu’il surveille le code sur GitHub à la recherche de manifestes de dépendances. Si vous êtes un développeur JavaScript, vous référencez d’autres paquets, des paquets npm par exemple.
Lorsque vous faites cela, il y a un fichier qui est généré appelé package.json. C’est un fichier JSON qui décrit les choses dont vous dépendez. Le graphe de dépendances recherche ce document JSON, ainsi que des fichiers pour quelques autres langages de programmation. Et il construit un jeu de données de tous les logiciels dont vous dépendez et la dernière version que vous avez utilisée », explique le responsable.
En outre, la page « Dependency Review » permet de consulter les relations entre les dépendances. Le tout s’appuie sur les règles de sémantique de versioning (Semver). Pour l’exploration des vulnérabilités, un autre outil entre en jeu.
« Nous avons un autre service appelé GitHub Advisory qui surveille les ensembles de données sur les vulnérabilités en provenance de la National Vulnerability Database (NVD). Nous avons une équipe de curateurs professionnels qui passent en revue chacune d’entre elles et déterminent si elle affecte un package npm, par exemple. Et nous faisons le lien avec le paquet et les versions affectées », affirme Justin Hutchings.
GitHub Advisory Database ne dépend pas seulement de la NVD. Il y a bien sûr le choix des curateurs, mais aussi des algorithmes de machine learning qui détecte les vulnérabilités dans les commits dans les dépôts, les avertissements ou indications de sécurité externes à GitHub, ainsi que les données de la base de données de sécurité de npm. La base de données est accessible séparément de Dependabot.
Données open source, logiciels propriétaires
GitHub Advisory Database n’est pas la seule base de données disponible pour vérifier les failles dans les projets open source. Nous avons récemment évoqué le cas de Snyk, mais d’autres éditeurs s’appuient sur les informations de la NVD et de l’OWASP pour faire la chasse aux anomalies de sécurité. Cependant, il y aurait plusieurs approches à l’œuvre, selon Justin Hutchings qui défend celle de GitHub.
« Les données de vulnérabilité sont un défi pour chaque entreprise qui s’occupe de ce que nous appelons l’analyse de la composition des logiciels. Il faut des curateurs », indique-t-il.
« Qu’il s’agisse de Snyk, d’un White Source, d’un Sonatype ou d’un Black Duck, ils ont tous ces curateurs. L’espoir est que les données soient les mêmes. La seule chose qui est différente, cependant, c’est la manière de les aborder. Nous avons mis nos données à disposition sous une licence Creative Commons. La plupart des autres produits commerciaux dans cet espace ont en fait des restrictions sur leurs mappages de données, où ils ne les rendent pas disponibles à moins que vous ne leur versiez de l’argent. Et nous pensons que cela va à l’encontre de la façon dont les informations sur la vulnérabilité devraient fonctionner. Nous pensons que c’est une bonne chose pour la communauté de s’assurer que chacun peut sécuriser ses dépendances sur les logiciels open source, avec les bonnes données », assure-t-il.
« Nous [les éditeurs] devons nous différencier avec l’expérience utilisateur bâtie par-dessus les données, mais les données elles-mêmes devraient être quelque chose d’ouvert, de sorte que tout le monde puisse être sécurisé, que les organisations paient ou non ».
Dependabot peut s’exécuter tous les jours, de manière hebdomadaire ou mensuelle. L’on peut planifier l’heure à laquelle cette vérification a lieu. Par défaut, Dependabot est réglé pour réaliser cinq pull requets maximum pour les mises à jour de paquets. En ce qui concerne les updates de sécurité, ce seuil est réglé à dix pull requests. L’application n’émet de nouvelles propositions que lorsque ces cinq ou dix PR sont résolues. Ces paramètres sont éditables depuis un manifeste YAML. Le document ressemble à ceci :
# Maintain dependencies for npm
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "daily"
« Si vous regardez notre rapport State of the Octoverse de l’automne dernier, il montre que le temps de remédiation est 1,4 fois plus rapide (13 jours plus tôt en moyenne, indique le document, N.D.L.R.) lorsque vous utilisez des pulls requests de Dependabot, ce qui est un avantage considérable en termes de durée d’exposition [à des vulnérabilités] », vante Justin Hutchings.
Les limites de Dependabot
Pour autant, Dependabot n’est pas un outil parfait, et une telle chose n’existe vraisemblablement pas. Jean Baptiste Le Digou, Développeur Full Stack chez Arkéa, écrivait en juin 2020 dans un billet de blog sur Medium qu’il rencontrait quelques bugs, notamment des clôtures inopinées des PR liées aux packages Maven.
Rien de surprenant lorsque l’on sait que Dependabot s’appuie majoritairement sur les fichiers YAML. Dans le cas de Maven, il lit les fichiers pom.xml afin d’indiquer les mises à jour accessibles, tout comme il interprète les fichiers de configuration build.gradle de Gradle. Il y a aussi le fait que la configuration de Dependabot ait la responsabilité développeur, ce qui permet de découvrir des bugs ou de pointer les limites d’un outil en développement continu.
Dans d’autres cas, les mises à jour plus ou moins automatiques peuvent casser tout ou partie d’une application. Par ailleurs, à charge de l’utilisateur de modifier ses propres changelogs une fois les mises à jour passées. Certains bâtissent des actions GitHub pour automatiser cet aspect.
« Nous ne pensons pas que laisser Dependabot réaliser des automerges sans autorisation soit une bonne idée, car il est possible que des paquets malveillants se propagent assez rapidement si les gens font cela. »
Michael McDonaldStaff product manager, Dependabot, GitHub
Enfin, il faut bien cerner les limites inhérentes à la sécurité de la supply chain. Certains programmeurs se plaignent du bruit généré par l’outil et cherchent, peut-être à tort, à obtenir des validations automatiques, une fonction qui existait avant son intégration dans le système de gestion de versions. « Nous ne pensons pas que laisser Dependabot réaliser des automerges sans autorisation soit une bonne idée, car il est possible que des paquets malveillants se propagent assez rapidement si les gens font cela », défend Michael McDonald, Staff Product Manager, Dependabot chez GitHub dans le cadre d’une discussion sur Twitter.
D’ailleurs, depuis le début du mois de mars, l’éditeur a instauré un système de lecture seul pour empêcher l’accès aux secrets dans les dépôts publics et privés. « Cette modification est apportée pour éviter que des dépendances potentiellement compromises ne capturent des secrets référencés dans vos flux de travail » justifie l’éditeur.
Pour approfondir sur Gestion des vulnérabilités et des correctifs (patchs)
