Nouveau livre O’Reilly : Sécuriser les bibliothèques open source, par Guy Podjarny

Snyk s’est associé à O’Reilly pour proposer un nouveau livre, Sécuriser les bibliothèques open source : gérer les vulnérabilités des packages de code open source. Dans ce livre, Guy Podjarny, PDG et fondateur de Snyk, aborde plusieurs sujets pour vous aider à gérer le risque lié aux bibliothèques open source vulnérables utilisées par vos applications aujourd’hui.

Les dépendances vulnérables sont les éléments de votre application que les attaquants sont le plus susceptibles d’exploiter. Ce livre présente quelques bonnes pratiques et outils essentiels pour protéger vos applications à grande échelle.

Téléchargez gratuitement votre livre dès maintenant !

Guy commence par expliquer ce qu’est une vulnérabilité connue et comment celles-ci sont consignées dans des bases de données publiques, comme CVE et NVD. Il explique pourquoi il ne suffit pas de s’appuyer uniquement sur ces bases. Guy aborde également la divulgation responsable et les mesures à prendre lorsque vous découvrez des vulnérabilités.

Au chapitre 2, Guy entre dans le vif du sujet et examine comment une vulnérabilité peut emprunter plusieurs chemins dans votre application. Cela se produit lorsqu’une bibliothèque vulnérable apparaît plusieurs fois dans votre arborescence de dépendances.

Prenons l’exemple d’une application qui utilise deux packages, A et B, sachant que A utilise également B (dans la même version). On obtient alors l’arborescence de dépendances suivante :

Supposons maintenant que B@1.0.0 présente une vulnérabilité connue de déni de service (DoS). Lors du test de l’application, combien de vulnérabilités devons-nous signaler ? D’un côté, l’application ne présente qu’une seule vulnérabilité connue : le DoS dans B@1.0.0. De l’autre, cette vulnérabilité est présente à deux endroits. Que faut-il signaler : une ou deux vulnérabilités ?

Un autre sujet essentiel est le moment où effectuer les tests. Le livre examine les avantages des tests au niveau du code source et des applications compilées. Cependant, tester le code source ne donne qu’une approximation, tandis que tester une application compilée est plus précis. La meilleure solution consiste à utiliser les deux !

Pour combiner les deux approches, certains outils testent les _built_apps, mais recherchent aussi les fichiers manifestes des packages, construisent une arborescence logique et tentent d’y intégrer les bibliothèques détectées. Vous bénéficiez ainsi de la couverture des tests sur les applications compilées et, dans la mesure du possible, de la compréhension approfondie qu’offre l’analyse du code source.

Vous pouvez également utiliser les deux approches à différentes étapes de votre développement. Par exemple, vous pouvez analyser le code source dans le cadre de votre workflow GitHub/GitLab/BitBucket, et tester une application compilée dans votre processus de build ou comme condition préalable au déploiement. Dans la plupart des cas, les deux approches donnent les mêmes résultats et restent cohérentes. Dans le cas contraire, les tests sur l’application compilée vous évitent de déployer une application vulnérable. 

Le chapitre explique comment rechercher les vulnérabilités connues dans votre SCM, en ligne de commande, dans les registres de conteneurs et dans le navigateur. Mais ce n’est que la moitié de l’histoire. Le plus intéressant, c’est de savoir comment agir sur les données dont vous disposez. Guy explique comment mettre à niveau vos dépendances directes et indirectes, ainsi que comment appliquer des correctifs lorsqu’aucune mise à niveau n’est possible. Des conflits peuvent toutefois survenir dans certains langages :

De nombreux langages, comme Ruby et Python, exigent que les dépendances soient globales. Des outils comme bundler pour Ruby et pip pour Python déterminent quelles versions de bibliothèques peuvent coexister. Par conséquent, la mise à niveau d’une bibliothèque peut créer un conflit avec une autre. Les développeurs savent gérer ce type de conflit, mais il arrive que certains problèmes soient tout simplement insolubles.

En plus de traiter les vulnérabilités des applications, le livre explique comment corriger les vulnérabilités dans vos images de conteneurs. Guy explique que, contrairement aux vulnérabilités des applications, les vulnérabilités du système d’exploitation disposent rarement d’une version corrigée vers laquelle il suffit de mettre à niveau. Il est donc d’autant plus important de bien prioriser les problèmes. 

Le chapitre 4 aborde un sujet essentiel dans le monde du développement moderne, où tout va très vite : intégrer des tests de sécurité à vos pipelines existants, afin de tester les modifications à mesure qu’elles passent du développement à la production. On parle souvent de pipeline DevSecOps.

Téléchargez le livre complet !

Préparer une remédiation rapide

La réaction de vos équipes à la découverte de nouvelles vulnérabilités est un aspect essentiel de ce processus, que celles-ci soient dues à une modification du code ou à la divulgation d’une nouvelle vulnérabilité. Qui devez-vous contacter à la réception d’une nouvelle notification de sécurité ? L’équipe de sécurité ? Les développeurs ? La direction ? À quelle vitesse devez-vous réagir en fonction du type et de la gravité des problèmes ? Faut-il interrompre les builds en cas de nouvelle vulnérabilité ? Les mises à jour de la chaîne de dépendances vous exposent-elles à des risques ? Téléchargez le livre dès maintenant pour découvrir des conseils et des recommandations pratiques afin de commencer à sécuriser vos bibliothèques open source.