Garder le Dependabot sous contrôle

Le Dependabot est un bot intégré à GitHub qui scanne les dépendances d'un dépôt afin de détecter celles qui ont été signalées comme vulnérables. Lorsque c'est le cas, il crée une alerte visible dans l'onglet "Security / Dependabot alerts" sur GitHub et soumet une pull request avec un correctif qui met à jour la version figurant dans le manifest (par exemple le fichier package-lock.json et / ou package.json).

Le bot est assez malin pour proposer une montée de version qui soit la moins éloignée possible de l'actuelle en respectant les conditions fixées par le manifest. Parfois il n'y arrive pas, pour diverses raisons mais dans ce cas l'alerte est accompagnée d'un message assez clair sur la marche à suivre.

Le Dependabot, ce voisin bruyant

Le problème du Dependabot c'est que par défaut, il peut être assez bruyant. Le fait est que l'arbre de dépendances d'un projet JavaScript moyen est très... riche (les packages JavaScript ont tendance à suivre le principe du "fais une chose mais fais le bien"). Quand on additionne les dépendances du projet avec ses sous dépendances, ses sous-sous dépendances, et etc. on multiplie les chances d'être touché par une vulnérabilité.

En revanche ces vulnérabilités ne sont pas toujours exploitables dans le contexte du projet. Par exemple la dépendance vulnérable n'est peut-être utilisé qu'au moment de build l'application. Ce qui se fait en général dans un environnement isolé où le code vulnérable n'est pas accessible par un attaquant potentiel. Ou alors la vulnérabilité fait partie du code publié mais les conditions de son exploitation ne sont pas réunies. Par exemple elle concerne une partie d'une librairie qui est inutilisée.

Recevoir de nombreuses alertes non pertinentes en continue peut distraire une équipe et lui faire baisser sa garde. Si on s'habitue au bruit et qu'on l'ignore, il devient facile de passer à côté d'une vraie alerte. C'est là le vrai danger du bruit et c'est pour cette raison qu'il faut tout faire pour le réduire et le rendre pertinent.

Configurer le Dependabot pour le rendre pertinent

Mise à jour du 04/05/2023 : GitHub a publié une nouvelle fonctionnalité qui permet de rejeter automatiquement les "faux-positifs". Pas évident de savoir ce qu'ils entendent exactement par là mais ils mentionnent notamment les devDependencies. Commence par l'essayer avant de te résoudre à le configurer manuellement :

• Annonce : Dependabot relieves alert fatigue from npm devDependencies
• Documentation de la fonctionnalité : Using alert rules to prioritize Dependabot alerts
• Suivre les mises à jour : Changelog Dependabot

Un bon moyen de limiter les alertes au code sensible du projet c'est d'indiquer au Dependabot de ne s'intéresser qu'aux dépendances de "production". C'est à dire les dépendances dont le code est exploitable par un attaquant potentiel. Pour un projet JavaScript, il s'agit des dépendances listées dans le champ dependencies du manifest package.json. À l'inverse, le champ devDependencies lui liste les dépendances qui ne sont utilisées que dans un environnement de développement. Pour ça, il suffit de créer le fichier .github/dependabot.yml avec la configuration suivante :

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    allow:
      - dependency-type: "production"

Mais attention, si vous vous arrêtez là vous allez réveiller la partie en sommeil du Dependabot qui va se mettre à vous proposer de mettre à jour toutes vos dépendances. En effet, si le Dependabot est activé par défaut sur les dépôts publics pour les mises à jour de sécurité, l'ajout de ce fichier de configuration activera également les montées de version. Le bot se mettra alors à proposer de mettre à jour les dépendances vers des versions plus récentes. Si votre intention était de réduire le bruit, il y a des chances que ce comportement ne soit pas le bienvenue. Pour désactiver cette partie du Dependabot et affecter les mises à jour de sécurité quand même, il vous faudra la configuration suivante :

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    open-pull-requests-limit: 0
    allow:
      - dependency-type: "production"

L'astuce consiste à mettre une limite de 0 au nombre de pull requests que le Dependabot peut ouvrir. Ce paramètre est l'un de ceux qui n'a pas d'influence sur les mises à jour de sécurité. L'autre paramètre incompatible est target-branch qui permet de spécifier la branche cible pour les pull requests. Si il pourrait être tentant de faire passer la mise à jour par une étape de recette en mergeant sur une branche du type develop, ce n'est pas possible. Et c'est même pire que ça puisque la documentation indique que si ce paramètre est présent, les mises à jour de sécurité ignoreront complètement la configuration :

When you use this option, the settings for this package manager will no longer affect any pull requests raised for security updates.

On peut comprendre la motivation, ça n'a pas de sens de mettre une limite sur le nombre d'alertes. Et quand une vulnérabilité est signalée, c'est déjà trop tard. Elle est dans la nature depuis un certain temps et des attaquants l'exploitent peut-être déjà. Il faut donc proposer un correctif le plus vite possible en production. Mais c'est à garder à l'esprit si vous souhaitez configurer les deux aspects du Dependabot.

Enfin, si cette approche est un bon moyen de réduire les chances de passer à côté d'un vrai risque, il ne faut pas s'arrêter là. Ce n'est pas parce que le code vulnérable n'est utilisé qu'en développement que ce n'est pas un risque. Si il s'exécute sur la machine d'un développeur, il pourrait lui voler sa clé ssh, lire les variables d'environnement, ou encore envoyer des fichiers. Des attaques qui peuvent finir par avoir un impact sur le projet ou l'équipe.

Au delà du Dependabot

Il ne faut donc pas tomber dans le piège de tout ignorer et rejeter. La présence de bruit dans les processus d'une équipe peut être le symptôme d'un problème plus grand. Peut-être que l'équipe manque de temps pour les tâches de maintenance parce qu'elles ne font pas partie intégrante de leur routine. Dans ce cas il serait intéressant de les considérer comme les autres tâches, en les ajoutant au sprint.

Enfin, il existe des alternatives ou compléments au Dependabot comme Snyk ou Socket. Ces services proposent souvent plus d'options de configuration et des interfaces qui donnent un plus grand contrôle. C'est un bon moyen de se simplifier la vie tout en prenant le sujet au sérieux.

👋 Restons en contact

Je tweet chaque jour plein de retours d'expérience comme celui-ci qui te feront gagner du temps : @gabinaureche.