4 étapes pour remédier aux dépendances vulnérables
7 juillet 2016
0 minutes de lectureIl y a quelques semaines, nous avons lancé l’intégration étroite de Snyk à GitHub. En la développant, nous voulions faciliter au maximum la remédiation des vulnérabilités connues et avons cherché les actions les plus simples et les plus claires à entreprendre. Nous avons finalement réduit le processus à 4 étapes, qui se sont révélées valables dans tous les environnements, de npm à Maven, en passant par les outils d’infrastructure en tant que code comme Chef et Puppet.
Cet article présente ces étapes et explique comment les mettre en œuvre avec Snyk (pour npm). Notez que, même si les exemples Snyk portent sur les tests d’applications avec GitHub, vous pouvez aussi suivre ces étapes à l’aide de la Snyk CLI.
Les étapes
Quels que soient vos outils ou votre environnement, voici les étapes à suivre pour remédier aux vulnérabilités connues dans vos dépendances :
Repérez les dépendances vulnérables
Corrigez les vulnérabilités
Empêchez l’ajout de nouveaux paquets vulnérables
Réagissez rapidement et efficacement aux nouvelles vulnérabilités divulguées.
Les deux premières étapes vous permettent d’éliminer les vulnérabilités. Elles sont toutes deux nécessaires : repérer les problèmes sans les corriger ne sert pas à grand-chose, mais vous ne pouvez pas corriger des problèmes dont vous ignorez l’existence. Il est essentiel de faciliter la correction, car il est bien trop tentant d’ignorer les alertes auxquelles il est difficile de donner suite. Les outils doivent donc non seulement permettre de corriger les problèmes, mais aussi rendre cette tâche très simple.
Une fois les vulnérabilités éliminées, les deux étapes suivantes vous aident à maintenir cette situation à mesure que votre code évolue et que de nouvelles vulnérabilités sont divulguées. Votre application et les connaissances publiques sur les vulnérabilités évoluent constamment : il vous faut donc une solution continue pour résoudre ce problème.
1) Repérez les vulnérabilités dans vos dépôts
La première étape consiste à tester tous vos projets pour détecter les vulnérabilités connues.
Chez Snyk, nous vous proposons une vue unique pour tester tous vos dépôts. Cliquez simplement sur « Tester mes dépôts » sur cette page de blog ou sur notre page de test pour accéder à une page qui répertorie les vulnérabilités dans tous vos dépôts utilisant npm.
Pour chaque dépôt utilisant npm, Snyk cartographie les dépendances et les compare à notre base de données de vulnérabilités open source. Les vulnérabilités sont classées selon leur gravité — élevée, moyenne ou faible — pour faciliter leur hiérarchisation. Vous pouvez cliquer sur chacune d’elles pour consulter des rapports de test détaillés.

2) Corrigez les vulnérabilités
Pour les projets dont les dépendances sont vulnérables, l’étape suivante consiste bien sûr à éliminer ces vulnérabilités. Repérer les problèmes permet d’évaluer votre niveau de risque actuel, mais ce que vous voulez vraiment, c’est les corriger. Il est essentiel d’investir dans des outils qui simplifient les corrections, sans quoi vous finirez vite par ne plus prêter attention à ces erreurs et par les ignorer. Le même phénomène se produit avec le linting, les tests de performance et d’autres tests qualité.
Chez Snyk, faciliter la correction est notre priorité. Nous l’avons réduite à un simple bouton « Corriger » qui génère automatiquement les modifications de code nécessaires pour éliminer les vulnérabilités. Pour cela, surveillez un dépôt depuis l’écran mentionné plus haut, puis accédez à la page de projet Snyk en cliquant sur « Voir le projet ». Vous y trouverez en haut à droite un bouton « Corriger les vulnérabilités », qui crée une pull request contenant le minimum de modifications nécessaires pour résoudre le problème et vous permettre de reprendre votre travail sur le code.
Pour corriger les problèmes, Snyk recherche d’abord la mise à niveau directe minimale permettant d’obtenir une version non vulnérable du paquet concerné. Si aucune mise à niveau de ce type n’existe, Snyk tente de corriger la vulnérabilité à l’aide de correctifs open source issus de notre base de données de vulnérabilités.

"features-alert.png3) Empêchez l’ajout de paquets vulnérables
Comme la qualité, la sécurité est un processus continu. Une fois les vulnérabilités éliminées, vous devez veiller à ne pas ajouter de nouvelles dépendances vulnérables à mesure que votre projet évolue. Et comme pour tout autre enjeu de qualité, plus tôt vous repérez une erreur de ce type, plus sa correction est simple et peu coûteuse.
Pour détecter les problèmes rapidement, intégrez-les à votre processus de tests continus, généralement sous la forme de tests exécutés pendant l’intégration continue ou dans le cadre d’une pull request GitHub.
Lorsque vous intégrez un projet GitHub à Snyk (en cliquant sur le bouton « Surveiller » mentionné plus haut), Snyk ajoute également ses tests aux étapes de vérification de vos pull requests. Ainsi, chaque fois qu’un développeur crée une pull request, Snyk teste ses modifications pour vérifier si elles rendent l’application vulnérable. Si c’est le cas, le test échoue clairement et indique les mesures à prendre.

L’ajout de tests aux pull requests rend les paquets vulnérables très visibles sans entraver le travail (vous pouvez configurer le seuil). Les membres de l’équipe peuvent ainsi repérer rapidement les erreurs involontaires. C’est également un bon moyen pour les projets open source de s’assurer que les contributions ne comportent pas de failles de sécurité. Les tests des pull requests ne sont généralement pas bloquants : si vous êtes pressé et avez évalué les conséquences, vous pouvez toujours choisir de fusionner une modification malgré les vulnérabilités.
4) Réagissez aux nouvelles vulnérabilités
Cette dernière étape distingue quelque peu la sécurité des autres enjeux de qualité. Dans la plupart des cas, vous ne créez de nouveaux bugs qu’en modifiant votre code. En revanche, des vulnérabilités connues peuvent apparaître même si votre code n’a pas changé.
De nouvelles vulnérabilités sont divulguées régulièrement, révélant des failles de sécurité jusque-là inconnues dans votre application. Ces failles étaient déjà présentes dans votre application et ses dépendances, mais leur divulgation augmente considérablement le risque que des attaquants les exploitent. Pour rester en sécurité, vous avez besoin d’une solution qui vous permette de découvrir rapidement et efficacement ces nouvelles divulgations et de les corriger avant que des attaquants ne puissent les exploiter.
Chez Snyk, nous cherchons là encore à simplifier votre réaction. Lorsque vous utilisez l’intégration GitHub, Snyk mémorise les dépendances utilisées par votre application et suit également l’évolution de votre fichier package.json. Lorsqu’une nouvelle vulnérabilité est divulguée et ajoutée à notre base de données, Snyk vérifie si votre projet est concerné et, le cas échéant, en informe toutes les personnes de votre organisation Snyk par e-mail. En parallèle, nous créons automatiquement une pull request de correction, ce qui vous évite une étape supplémentaire.

Protégez tous vos projets
Lors d’un test, il est tentant de ne s’intéresser qu’aux projets qui présentent aujourd’hui des dépendances vulnérables. Ce sont effectivement les seuls qui nécessitent la deuxième étape : la correction.
Toutefois, gardez à l’esprit qu’un projet non vulnérable aujourd’hui peut le devenir demain. Veillez à surveiller tous vos projets afin de pouvoir prévenir et traiter l’apparition de nouvelles dépendances vulnérables.
En résumé
Et voilà. En suivant ces 4 étapes, vous serez bien armé pour remédier aux dépendances vulnérables. Pour les dépendances npm, Snyk simplifie considérablement le processus. Pour les autres plateformes, vous pouvez choisir les outils qui vous conviennent (s’ils existent), mais veillez à suivre les quatre étapes.
Lancez-vous dès maintenant : cliquez simplement sur « Tester mes dépôts » et le tour est joué !
Lancez-vous dans les compétitions Capture The Flag
Apprenez à résoudre des défis Capture The Flag en regardant à la demande notre atelier virtuel d’initiation.


