Créer le plugin Gulp Snyk : entretien avec Doug Wade

Doug Wade est ingénieur front-end senior chez Indeed. Doug a créé le formidable plugin gulp-snyk, qui vous permet d’intégrer Snyk en toute simplicité à votre processus de build Gulp. La découverte de ce plugin nous a vraiment enthousiasmés : nous avons donc voulu échanger avec Doug pour en savoir un peu plus.

Pourquoi avez-vous commencé à utiliser Snyk ?

L’année dernière, alors que j’étais mentor au Node Summit, j’ai eu l’occasion d’assister à l’excellente présentation de Guy et à sa démo en direct montrant comment exploiter certaines alertes de sécurité concernant minimatch que je négligeais dans mes projets. Une expérience à la fois instructive et inquiétante.

Pendant le cocktail, j’ai discuté avec Guy des raisons qui me feraient passer de nsp à Snyk. Il m’a parlé de ce que je considère comme la « fonctionnalité phare » de Snyk : snyk protect.

Pendant longtemps, publier des fichiers .nsprcs sur Github pour que mes builds Travis passent m’a dérangé. Pour des projets comme React Server, j’avais l’impression de publier un inventaire de vulnérabilités dont les attaquants pourraient se servir pour exploiter des sites comme www.redfin.com. C’était tout le contraire de mon objectif ! Mais, concrètement, c’était la seule solution.

Au début de l’histoire de npm, Isaac Z. Schlueter (inventeur et PDG de npm) a pris une décision qui, selon moi, a joué un rôle essentiel dans l’explosion du nombre de packages npm et dans l’accessibilité de npm comme moyen de commencer à contribuer au développement open source. Isaac a décidé d’éviter l’enfer des dépendances à la Java en fournissant à chaque dépendance sa propre copie indépendante des dépendances déclarées.

Cela signifie que, lorsqu’on développe seul des modules sur npm — comme c’est souvent mon cas pour mes projets open source —, on peut travailler très vite en modifiant et en mettant à niveau ses dépendances sans craindre que ses utilisateurs restent bloqués sur une ancienne version en attendant que toutes les dépendances soient compatibles.

En contrepartie, pour les développeurs d’applications qui doivent éliminer les dépendances vulnérables de leur arborescence de dépendances — comme c’est mon cas au travail —, mettre à niveau ses dépendances directes ne suffit pas. Il faut aussi s’assurer que chacune de leurs dépendances passe à une version sécurisée. Après m’être fait vertement réprimander par un développeur que je respecte énormément pour avoir soumis une issue et une PR visant à mettre à jour une dépendance vulnérable dans un projet de la Node Foundation, j’ai compris que la méthode de nsp — fichiers nsprc et attente que les correctifs se propagent dans l’écosystème — n’était pas viable.

L’approche de Snyk résout ce problème en corrigeant mon application au moyen d’un script postinstall. Je n’ai donc pas à attendre que la modification se propage dans l’écosystème, et mon manifeste ne répertorie plus les vulnérabilités existantes, mais celles qui ont été corrigées.

Pourquoi avez-vous finalement créé gulp-snyk ?

Je développe avec Node depuis la version 0.8, surtout parce que c’était le seul environnement de développement que j’avais réussi à configurer sur mon ordinateur Windows quand j’apprenais à programmer. J’ai donc encore un bon nombre de modules qui utilisent Gulp comme système de build.

Selon moi, les systèmes de build ont avant tout pour rôle de standardiser les tâches courantes et de les rendre faciles à trouver. Plutôt que de demander aux nouveaux contributeurs de repérer les tâches dispersées entre un fichier package.json et un fichier gulpfile, je voulais disposer d’une liste unique de tâches. Écrire mes tâches Snyk dans Gulp ne nécessitait pas beaucoup de code répétitif, mais suffisamment pour que je ne veuille pas le copier-coller d’un projet à l’autre. J’ai donc publié le plugin sur npm.

J’ai réalisé l’essentiel du développement en deux soirées après le travail. Il s’avère qu’il existe une API programmatique non documentée, utilisée par gulp-snyk pour lancer la cible de test.

J’ai ouvert une issue pour essayer de coordonner cela avec Snyk. Pour moi, cet épisode illustre l’un des aspects que je préfère dans les langages dynamiques : je n’avais pas besoin de connaître quoi que ce soit à Snyk. Il me suffisait de lancer un REPL (Read-Eval-Print-Loop) et d’explorer.

Comment utilisez-vous gulp-snyk aujourd’hui ?

J’utilise gulp-snyk pour protéger Clefs et name-suffixes, et je prévois de l’ajouter à React Server. J’utilise Snyk pour 17 de mes modules Node et compte étendre son utilisation à mes 33 modules.

Trente-trois modules NPM ! Qu’est-ce qui vous motive à contribuer autant ?

Je pense qu’en tant que développeurs, nous avons l’obligation éthique de contribuer à la communauté, vu tout ce qu’elle nous apporte. Mais, honnêtement, je crois qu’une grande partie de ma motivation est profondément égoïste.

Quand je propose une PR pour Node, npm ou Lerna, j’ai l’occasion d’explorer le code et de recevoir une revue de code de la part de certains des esprits les plus brillants du développement logiciel. Quand je publie pour la première fois un projet sur lequel j’ai travaillé sur Reddit ou Hacker News, je reçois des commentaires sur la conception de l’API, l’architecture et la documentation, bien plus adaptés à mon domaine d’expertise que ceux que je reçois au bureau.

D’une certaine façon, je suppose que c’est aussi ma manière de ne pas retirer l’échelle une fois arrivé en haut. Ma carrière s’est construite sur le travail avec des logiciels libres et open source (FOSS), et sur tout ce que j’ai appris grâce à eux. Ainsi, sans FOSS, je ne serais tout simplement pas là où j’en suis aujourd’hui.

À ce propos, si des personnes souhaitent contribuer à gulp-snyk, où doivent-elles se rendre ?

Le plugin gulp-snyk est disponible sur npm et vous pouvez l’installer avec npm (npm install --save-dev gulp-snyk) ou yarn (yarn add --dev gulp-snyk). Si vous souhaitez contribuer, le code est disponible sur GitHub.