Vulnérabilités Open Source - Juillet 2020

Comme chaque mois, l'équipe de recherche WhiteSource a examiné les nouvelles vulnérabilités de sécurité publiées en juin pour les programmes open source et collectées par la base de données WhiteSource.

La base de données complète de WhiteSource sur les vulnérabilités open source agrège continuellement des informations provenant de diverses sources, allant de la base de données nationale sur les vulnérabilités (NVD) aux avis de sécurité évalués par des pairs et aux pisteurs de problèmes dans les communautés open source et de sécurité.

Plus de 800 nouvelles vulnérabilités ont été publiées en juin. Alors que l'utilisation de l'open source devient une pratique courante dans les équipes de développement logiciel, et que la communauté de l'open source se développe, cette communauté multiplie les efforts pour détecter et corriger les problèmes de sécurité des composants open source. Près de la moitié de ces vulnérabilités ont été publiées avec une résolution, d’où l’intérêt majeur de suivre de près ces informations.

Nous avons analysé la répartition des vulnérabilités de juin selon leurs « scores » de gravité, car c’est habituellement un facteur déterminant pour les équipes de développement et de sécurité lorsqu’il s’agit de déterminer quelles nouvelles alertes doivent être traitées en priorité.

En examinant les données de cette répartition, il est clair que les scores de gravité ne suffisent pas pour hiérarchiser les vulnérabilités lorsque plus de 50 % d’entre elles sont jugées élevées ou critiques.

Il y a plusieurs raisons pour lesquelles la répartition des scores est si inégale. Il est compréhensible que la communauté de recherche en sécurité consacre des ressources à la découverte et à la divulgation des problèmes de plus haute gravité, ce qui réduit les vulnérabilités faibles et moyennes publiées. Même si le score de gravité doit être une considération lors de la hiérarchisation des alertes de sécurité pour les nouvelles vulnérabilités, il est important de se rappeler qu’il ne peut pas être la seule considération. Le score CVSS est destiné à mesurer la sévérité et non le risque. Le risque et l'impact d'une vulnérabilité sur un produit logiciel dépendent d'un certain nombre d'aspects supplémentaires qui devraient être pris en compte.

En Juin, les trois CWEs les plus courants sont le CWE-79 (XSS), le CWE-200 (Exposition de l'information), le CWE-125 (Lecture hors limites), les vulnérabilités CWE-79 XSS étant dominantes.

Le CWE-79 (XSS) est le type de vulnérabilité le plus répandu depuis deux ans et l'un des trois les plus courants CWE depuis plusieurs années.

L’augmentation des vulnérabilités XSS étant constante, il est important de se rappeler que ce problème peut être évité à l’étape du codage, simplement en suivant les normes de codage de base et les meilleures pratiques. Bien que la détection précoce des problèmes soit extrêmement importante, le codage sécurisé est également une étape essentielle améliorer la sécurité des codes.

En juin, près de 25% des vulnérabilités open source publiées étaient dans des bibliothèques écrites en C. Compte tenu de la quantité de code écrit en C et de la taille des communautés derrière des applications comme le noyau Linux, cela ne devrait pas surprendre. La loi de Linus stipule que « si on augmente le nombre de développeurs, on minimise les bugs ». Donc, avec un langage aussi répandu que C, on s'attend à un grand nombre de vulnérabilités publiées.

Non loin derrière C, on trouve aussi un grand nombre de vulnérabilités publiées en mai pour JavaScript, un langage avec des projets extrêmement populaires, également soutenus par une communauté open source active.

Ces failles de vulnérabilité ne doivent pas être une fatalité. Il existe des solutions pour s’en prémunir, ou à tout le moins en diminuer très significativement l’impact sur vos logiciels. Avec une analyse pertinente de vos applications, vous maitriserez le risque et connaitrez les corrections disponibles.

Accédez à la version détaillée de cet article, ou contactez-nous pour voir comment la technologie SCA (Software Composition Analysis) avancée de WhiteSource peut vous aider à réduire les risques tout en minimisant l’effort de développement dans un cadre de coopération DevSecOps dans votre organisation.