Dépendances sécurisées

  • 5 minutes

Une grande partie du code présent dans les applications modernes correspond aux bibliothèques et dépendances que vous avez choisies en tant que développeur. Cette pratique courante permet de gagner du temps et de limiter son budget. Elle présente toutefois un inconvénient : même s’il a été écrit par d’autres, vous êtes seul responsable de ce code, car vous l’utilisez dans votre projet. Si un chercheur (ou pire encore, un pirate informatique) détecte une vulnérabilité dans l’une de ces bibliothèques tierces, sachez que cette même faille est également présente dans votre application.

L’utilisation de composants porteurs de vulnérabilités est un problème très sérieux dans notre secteur d’activité. À tel point qu’il est classé 9e dans le top 10 OWASP des plus grandes vulnérabilités auxquelles sont soumises les applications web, et ce depuis plusieurs années.

Surveiller les failles de sécurité connues

Le problème que nous rencontrons se situe au niveau du suivi de la détection des problèmes. Bien sûr, nous pouvons veiller à ce que nos bibliothèques et dépendances soient mises à jour régulièrement (n° 4 dans notre liste !), mais il est encore plus judicieux d’effectuer le suivi des vulnérabilités identifiées susceptibles d’impacter votre application.

Important

Quand un système présente une vulnérabilité connue, il y a de fortes chances pour que des personnes aient créé du code malveillant afin d’attaquer ces systèmes. Si ce code malveillant est rendu public, les systèmes concernés doivent impérativement être mis à jour dans les plus brefs délais.

Mitre est une organisation à but non lucratif qui gère la liste Common Vulnerabilities and Exposures (CVE). Cette liste regroupe un ensemble de vulnérabilités de cybersécurité connues dans les applications, les bibliothèques et les infrastructures. Elle est accessible au public et peut faire l’objet de recherches. Lorsque vous trouvez une bibliothèque ou un composant dans la base de données CVE, alors il présente des vulnérabilités connues.

Quand une faille de sécurité est identifiée dans un produit ou un composant, la communauté de sécurité le soumet le problème. Tout problème publié est associé à un ID, la date de sa découverte et une description de la vulnérabilité. De plus, les solutions de contournement publiques ou les instructions du fournisseur à propos du problème y sont référencées.

Vérifier si vous présentez des vulnérabilités connues dans vos composants tiers

Vous pourriez fixer un rappel quotidien dans votre téléphone pour consulter cette liste, mais heureusement pour vous, de nombreux outils permettent de vérifier la sécurité des dépendances. Vous pouvez exécuter ces outils sur votre base de code, ou mieux encore, les ajouter à votre pipeline CI/CD pour rechercher automatiquement des problèmes dans le cadre du processus de développement.

  • OWASP Dependency Check dispose d’un plug-in Jenkins
  • Snyk est gratuit pour les dépôts open source dans GitHub
  • Black Duck est utilisé par de nombreuses entreprises
  • Retire.js est un outil permettant de vérifier si vos bibliothèques JavaScript sont obsolètes ; il peut être utilisé en tant que plug-in pour différents outils, notamment Burp Suite

Vous pouvez également utiliser d’autres outils conçus spécifiquement pour l’analyse statique du code à ces fins.

Pour plus d’informations sur les risques encourus suite à l’utilisation de composants vulnérables, visitez la page de l’OWASP consacrée à ce sujet.

Récapitulatif

Quand vous utilisez des bibliothèques ou des composants tiers dans le cadre de votre application, vous assumez les risques qui leur sont associés. La meilleure façon de réduire ce risque est de vérifier que vous utilisez uniquement des composants qui ne présentent aucune vulnérabilité connue.