Désactivons Dependabot

• Les notifications excessives de Dependabot font perdre du temps aux développeurs au lieu de les aider à résoudre de vrais problèmes de sécurité
• Comme l’a montré un cas survenu dans l’écosystème Go, des milliers de PR et d’alertes sont générées même pour des dépôts non affectés, ce qui crée de la confusion
• En utilisant une GitHub Action basée sur govulncheck, il est possible de détecter uniquement le code réellement vulnérable et d’éliminer les alertes inutiles
• Pour les mises à jour de dépendances, il est plus sûr et plus efficace de les gérer via des tests périodiques et une validation des versions les plus récentes plutôt qu’avec des PR automatisées
• Cette approche est importante pour réduire la fatigue liée aux alertes (alert fatigue) et alléger la charge des mainteneurs open source

---

Les problèmes de Dependabot

• Dependabot génère en masse des alertes de sécurité et des PR automatiques, ce qui complique l’identification des vrais problèmes importants pour les développeurs
  • Une modification mineure du paquet Go filippo.io/edwards25519 a suffi à déclencher des milliers de PR
  • Des alertes de sécurité erronées ont aussi été envoyées à des dépôts non affectés, comme Wycheproof
• Les alertes incluent des scores CVSS erronés et de faibles indicateurs de compatibilité, alimentant une inquiétude inutile
• Cet excès de notifications est présenté comme une cause de baisse de fiabilité et d’efficacité dans la réponse aux incidents de sécurité

Une alternative avec govulncheck

• La Go Vulnerability Database fournit des métadonnées détaillées au niveau des versions, des paquets et des symboles
  • Par exemple, la vulnérabilité GO-2026-4503 n’affecte que le symbole Point.MultiScalarMult
• govulncheck utilise l’analyse statique pour détecter uniquement le code vulnérable réellement appelable
  • Utilisé avec go mod why, il permet de déterminer précisément si une dépendance indirecte a un impact
  • Même si une vulnérabilité existe, l’outil ne signale rien si le code n’appelle pas le symbole concerné
• L’intégration est simple via la CLI (govulncheck -json) ou l’API Go (golang.org/x/vuln/scan)

Remplacement par GitHub Actions

• À la place de Dependabot, on peut configurer une GitHub Action govulncheck pour lancer une vérification automatique chaque jour
  • Une notification n’est envoyée que lorsqu’une vraie vulnérabilité est détectée
  • Comme aucune PR automatique n’est créée, les développeurs peuvent se concentrer sur les enjeux de sécurité réellement importants
• Réduire les fausses alertes permet d’atténuer la fatigue liée aux alertes de sécurité (alert fatigue) et d’améliorer la qualité des réponses
• Cela élimine aussi le problème des PR inutiles envoyées aux mainteneurs open source

Gestion des mises à jour de dépendances

• Les dépendances doivent être gérées de façon groupée selon le cycle de développement propre à chaque projet
  • Des tests peuvent être exécutés chaque jour avec les versions les plus récentes, tandis que les mises à jour effectives ne sont effectuées qu’au moment nécessaire
  • En Go, il est possible de tester les versions les plus récentes avec go get -u -t ./..., et en npm avec la commande npm update
• Cette méthode permet de garantir à la fois la rapidité de réaction face aux vulnérabilités et la stabilité
  • Les tests sur les dernières versions permettent d’identifier tôt les problèmes de compatibilité
  • Elle évite aussi qu’une dépendance contenant du code malveillant soit déployée immédiatement
• Avec geomys/sandboxed-step, l’exécution peut être isolée dans CI via gVisor

Conclusion et contexte de soutien

• L’automatisation de Dependabot génère souvent plus de bruit (noise) que de sécurité
• Une approche fondée sur govulncheck et des tests périodiques constitue une méthode de gestion de la sécurité plus précise et plus durable
• La maintenance open source de l’auteur est soutenue via l’organisation Geomys par des sponsors comme Ava Labs, Teleport, Tailscale et Sentry
• Ce modèle contribue à la pérennité de l’écosystème open source et à l’amélioration de la qualité de la sécurité

[GN⁺]

Avis Hacker News

• Dependabot a une certaine utilité
  Mais un outil qui se contente de comparer des numéros de version avec une base de données de vulnérabilités ne peut pas déterminer si le code réel est exposé à cette vulnérabilité, donc il génère beaucoup de bruit
  L’outil qui m’a récemment le plus impressionné est CodeQL. Il peut être exécuté via GitHub Advanced Security et montre visuellement tout le cheminement en suivant le flux réel du code, depuis les entrées jusqu’à un usage dangereux
  Grâce à ça, il fournit des informations réellement exploitables pour corriger le problème, avec peu de faux positifs. Bien sûr, dans des langages dynamiques comme Python, il y aura toujours du code capable d’échapper à la détection, mais dans la plupart des cas c’est largement utile
  • Avant, CodeQL aidait notre projet, mais récemment c’est devenu insupportable, donc l’équipe l’a désactivé
    On se retrouve avec des commentaires du type « ajoutez des variables intermédiaires inutiles » juste pour contourner les alertes de CodeQL. Ça donne l’impression d’un outil surajusté aux données
  • J’ai du mal à être d’accord avec l’idée qu’il y a « presque zéro faux positifs ». Selon le théorème de Rice, ce genre d’analyse parfaite est impossible
  • D’après mon expérience, CodeQL produit beaucoup de faux positifs et il n’existe pas de moyen simple de l’exécuter en local, ce qui crée une dépendance au fournisseur
  • Mettre à jour une version de dépendance ne garantit pas une amélioration de la sécurité. Une nouvelle version peut aussi introduire de nouvelles vulnérabilités
• Les paquets NPM déclenchent beaucoup trop d’alertes ReDoS. La plupart concernent des paquets utilisés uniquement côté client, donc il y a énormément d’alertes sans rapport avec le backend. Le ReDoS côté client n’a aucun intérêt pour nous
  • En réalité, je pense qu’un DoS n’est pas une vulnérabilité de sécurité mais un problème de disponibilité. C’est bien l’un des éléments du triptyque CIA, mais dans la pratique c’est plus proche d’un sujet d’exploitation. Classer le DoS comme un problème de sécurité n’est qu’un vestige historique
  • Je maintiens le paquet debug, et il y a énormément de signalements ReDoS absurdes. Certains ont même reçu un CVE, au point de me donner envie de quitter l’écosystème JS
  • Je rencontre un problème similaire avec les outils de revue de code par IA. Même quand l’outil s’exécute en local avec les droits de l’utilisateur, il demande de sanitize les entrées sans raison. Au final, c’est juste une perte de temps
  • Nous avons le même problème. En particulier, les alertes ReDoS provenant des Dev dependencies créent beaucoup de bruit inutile
  • Le ReDoS est un bug du moteur d’expressions régulières, et des moteurs comme V8 ne fournissent toujours pas par défaut un moteur regex sûr
• Govulncheck est l’une des meilleures fonctionnalités de l’écosystème Go
  Nous utilisons une GitHub Action qui alerte lorsqu’un appel vulnérable est ajouté dans une PR.
  Combiné à l’auto-merge de Dependabot, c’est aussi une bonne formule pour gérer une base de code JS
  • Govulncheck n’est pas parfait non plus. Il y a des faux positifs, et aucun moyen d’exclure une vulnérabilité précise par numéro de CVE
• Dependabot est utile, mais en même temps il rappelle chaque jour l’importance de minimiser ses dépendances
  • Moi aussi, je commence mes journées en traitant des PR Dependabot.
    Si les tests sont suffisamment bons, on découvre parfois des bugs dans les nouvelles versions, mais cela mène aussi à des contributions open source. C’est pénible, mais ça aide à prendre de bonnes habitudes
  • Je suis d’accord aussi. Je n’ai pas beaucoup de projets, mais je trouve Dependabot plutôt utile
• J’aimerais que Dependabot soit géré sous forme d’onglet dans le dépôt plutôt que par e-mail.
  Les notifications par e-mail sont pénibles, et je n’aime pas voir les PR s’empiler. Je préférerais tout traiter à des moments précis
  • Le fichier de configuration dependabot.yml permet de régler la fréquence d’exécution et le nombre de PR
    Voir la documentation officielle
  • On peut aussi désactiver les PR automatiques et ne les créer manuellement qu’en cas de besoin.
    Il est également possible de réduire le nombre d’issues en corrigeant directement soi-même
  • Avec l’extension Refined GitHub, la vue par défaut devient un peu plus propre.
    Personnellement, je recommande plutôt Renovate. Il prend en charge davantage de langages et d’options d’auto-merge
• L’approche de govulncheck dans Go, qui suit les chemins d’appel réels, devrait devenir la norme dans tous les écosystèmes
  Le vrai problème de Dependabot, c’est qu’il confond gestion des dépendances et sécurité.
  Une vulnérabilité dans une fonction jamais appelée n’est pas un problème de sécurité, c’est du bruit
  En Python, j’ai l’impression que pip-audit --desc est meilleur que Dependabot.
  En attendant une analyse statique parfaite, une vérification manuelle trimestrielle est peut-être plus sûre
  • Mais quand un client scanne le code avec ce genre d’outil, il ne croit pas la réponse « nous n’utilisons pas cette fonction ».
    C’est là que naît l’écart entre la sécurité réelle et les pratiques de sécurité
  • La question « si vous ne l’utilisez pas, pourquoi cette fonction est-elle encore dans le code ? » est aussi légitime
• Je ne comprends pas pourquoi l’industrie a adopté ces scanners de sécurité superficiels
  La plupart des CVE n’ont en réalité aucun impact, mais les entreprises essaient malgré tout de ramener à zéro le nombre de vulnérabilités dans leurs images de conteneurs
  Et en plus, mettre à jour des dépendances finit souvent par introduire de nouveaux CVE. C’est parce que la plupart des logiciels ne font pas de correctifs rétroportés
  • Je ne vois pas très bien comment la partie sur « l’absence de backport » se relie à la phrase précédente
• L’avantage de Dependabot ou Renovate, c’est qu’ils fonctionnent quelle que soit la langue
  Plus on a de dépôts et de langages différents, moins il est réaliste d’ajouter un workflow CI parfait partout
  Ce n’est pas parfait, mais c’est quand même bien mieux que de ne rien faire du tout
• Je me demande d’où vient le score CVSS affiché par Dependabot.
  Est-ce qu’il génère automatiquement des CVE ?
  • Le CVSS est un score basé sur le pire scénario possible, donc il ne reflète pas le risque réel.
    La base de données de vulnérabilités de GitHub privilégie la quantité à la qualité, et Dependabot fonctionne comme une machine à spam sans intelligence
  • On peut même se demander si ce bug est réellement une vraie vulnérabilité.
    Si le problème n’apparaît qu’en appelant une fonction de la mauvaise manière, il est probable que le code ne fonctionnait déjà pas correctement
• Notre entreprise a le même problème.
  Le scan des images de conteneurs GCP envoie à Vanta une énorme quantité d’alertes CVE, dont la plupart sont soit impossibles à corriger, soit situées sur des chemins qui ne sont en réalité jamais utilisés
  Je me demande s’il existe des outils capables de faire ce filtrage contextuel
  • Dans notre entreprise, nous utilisons Aikido Code. L’idée est d’utiliser l’IA pour filtrer l’impact réel des vulnérabilités.
    Les résultats sont globalement positifs, mais avec une grosse base de code et beaucoup de dépendances, il reste difficile de réduire le nombre de CVE