Les composants open source sont les briques de construction de nombreuses applications logicielles actuelles, mais cela les place sous un contrôle accru en matière de sécurité.Le spécialiste de la gestion open source WhiteSource a publié un nouveau rapport qui montre que les vulnérabilités des logiciels open source divulguées en 2019 ont grimpé à plus de 6000, en hausse de près de 50 %.
Selon le rapport, « cela peut être attribué à l'augmentation de la sensibilisation à la sécurité open source suite à l'adoption généralisée de composants open source et à la croissance massive de la communauté open source au cours des dernières années, ainsi qu'à l'attention des médias dirigée contre les récentes violations de données. Le nombre de vulnérabilités Open Source signalées a augmenté de près de 50 % en 2019 ».
Vulnérabilités de sécurité Open Source par an
La bonne nouvelle est que plus de 85 % des vulnérabilités open source ont déjà été révélées et que des correctifs sont déjà disponibles : « les géants de la tech ont investi massivement dans une meilleure sécurisation et gestion des projets open source au cours des dernières années, et la communauté travaille d'arrache-pied à la recherche sur la sécurité pour publier les vulnérabilités de sécurité open source récemment découvertes avec un correctif. Le correctif sera généralement une version mise à jour ou un correctif pour le code vulnérable ».
Cependant, les informations sur les vulnérabilités ne sont pas publiées dans un emplacement centralisé, plutôt dispersées sur des centaines de ressources, et parfois mal indexées, ce qui complique souvent la recherche de données spécifiques : « malheureusement, les utilisateurs ne sont pas toujours en mesure de bénéficier des efforts de la communauté. Seulement 84 % des vulnérabilités open source connues apparaissent dans le NVD. Bien que 45 % des vulnérabilités open source signalées ne soient pas initialement signalées au NVD, beaucoup finissent publié dans le NVD, des mois après avoir été signalé dans d'autres ressources ».
Sur la base de la base de données de WhiteSource, seulement 29 % de toutes les vulnérabilités open source signalées en dehors de la NVD (Nartional Vulnerability Database) y sont finalement publiées.
Vulnérabilités et langages de développement
De plus, les chercheurs ont comparé la façon dont les sept langages de développement les plus populaires sont associés aux vulnérabilités signalées en 2019, puis ont comparé ces chiffres aux dix dernières années.
Vulnérabilités Open Source par langue, 2019 vs 2009-2018
C a toujours le pourcentage le plus élevé de vulnérabilités en raison du volume élevé de code écrit dans ce langage. Le nombre relatif de vulnérabilités de PHP a augmenté de manière significative, alors qu'il n'y a aucune indication de la même augmentation de popularité. Python a un pourcentage relativement faible de vulnérabilités, même si sa popularité, en particulier dans la communauté open source, continue d'augmenter. L’auteur du rapport espère que cela soit le résultat de pratiques de codage sécurisées et non d'une recherche de sécurité laxiste pour les projets Python.
Vulnérabilités et notes CVSS (Common Vulnerability Scoring System)
Le rapport examine également si la note CVSS (Common Vulnerability Scoring System) est la meilleure mesure sur laquelle baser les priorités de correction. CVSS a été mis à jour plusieurs fois au cours des dernières années dans le but d'atteindre une norme mesurable et objective qui aide à soutenir toutes les organisations et industries. Mais dans le processus, il a également changé la définition de ce qu'est une vulnérabilité de gravité élevée. Cela signifie qu'une vulnérabilité qui aurait été notée 7,6 sous CVSS v2 pourrait être une 9,8 sous CVSS v3.0, ce qui signifie que les équipes sont confrontées à un nombre plus élevé de problèmes de gravité élevés et critiques. Plus de 55 pour cent sont désormais très graves ou critiques.
« CVSS a été mis à jour plusieurs fois au cours des dernières années (v2 à v3, et plus récemment v3.1), dans l'espoir d'atteindre une norme mesurable et objective qui aide à soutenir toutes les organisations et les industries. Cependant, cela a également changé la définition de ce qu'est une vulnérabilité de gravité élevée.
« Nous avons examiné plus de dix mille vulnérabilités de 2016 à 2019 et vérifié leurs CVSS v2, v3.0 et v3.1 pour comparer la répartition de la gravité des vulnérabilités dans chaque version de notation au cours des quatre dernières années.
« Le changement le plus notable que nous avons vu dans la mise à jour de la v2 à la v3 est que les notes ont considérablement augmenté, car une vulnérabilité qui aurait été notée 7,6 sous CVSS v2 pourrait rapidement se retrouver avec un 9,8 sous CVSS v3.0. Avec CVSS v3.0, les équipes étaient confrontées à un nombre plus élevé de vulnérabilités de gravité élevée et critique.
« Il manque encore les outils pour les hiérarchiser et les traiter, ou même comprendre pleinement l'impact des vulnérabilités, sur leur projet.
« En regardant la distribution de gravité du nouveau score CVSS v3.1, nous pouvons voir que ce n'est pas une distribution normale, puisque 17 % des vulnérabilités sont critiques et seulement 2 % sont faibles.
« Alors que la communauté s'efforce de trouver une norme de notation objective de la gravité pour aider les utilisateurs à faire face à l'évolution du paysage de la sécurité, la norme doit encore être perfectionnée. Des facteurs supplémentaires susceptibles de provoquer ce déséquilibre sont la concentration accrue sur les problèmes importants et critiques, et le fait que la création d'une CVE est un effort fastidieux que certains préfèrent éviter lorsqu'il s'agit de problèmes de moindre gravité.
« La question demeure: comment pouvons-nous nous attendre à ce que les équipes hiérarchisent efficacement les vulnérabilités lorsque plus de 55% sont de haute gravité ou critiques? »
CVSS v3.x Répartition de la gravité dans le temps
Vulnérabilités et CWE (Common Weakness Enumeration)
Un autre aspect que les auteurs ont voulu examiner était les types de vulnérabilités les plus courantes en 2019. Common Weakness Enumeration ou CWE est une liste des vulnérabilités que l'on peut rencontrer dans les logiciels.
« Les cinq premiers CWE en 2019 ont été cohérents au cours des dernières années et sont tous liés à la divulgation d'informations. Ce qui est inquiétant, c'est que les CWE les plus courants sont dus à de simples erreurs de code et à un codage imprécis, que tous les développeurs pourraient éviter en respectant des normes de codage assez basiques ».
CWE les plus courants en 2019
« Bien qu'ils ne figurent pas dans le top cinq, il est intéressant de noter que CWE-352 - Cross-Site Request Forgery (CSRF), a émergé dans le top 10 des CWE cette année, et que CWE-89 - SQL Injection, a réapparu alors qu’il avait quitté le podium depuis 2015. Cela pourrait être dû à une augmentation du volume de projets Web open source développés, et cela pourrait indiquer que les vulnérabilités Web sont en augmentation et que nous devons garder à l'esprit lors du codage ».
CWE les plus courants par an
Les auteurs du rapport concluent en ces termes :
« Le point le plus important à retenir de cette liste est que ce n'est pas parce que les projets open source populaires présentent des vulnérabilités qu'ils sont intrinsèquement non-sécurisés.
« Cela signifie seulement qu'en tant qu'utilisateur de projets open source, vous devez être conscient des risques de sécurité et vous assurer de maintenir à jour vos dépendances open source.
« Les composants open source font désormais partie intégrante de nos projets logiciels. Le paysage des vulnérabilités open source peut sembler complexe et difficile au premier abord, mais il existe des moyens de gagner en visibilité et en contrôle sur les composants open source qui composent les produits que nous publions ».
Source : rapport WhiteSource
Et vous ?
Quelle lecture faites-vous de ces données ? À quoi pouvez-vous attribuer cette augmentation du nombre de vulnérabilités rapportées ? Comment pouvez-vous expliquer la répartition des vulnérabilités rapportées en fonction du langage de développement ? À quelle fréquence effectuez-vous des mises à jour de votre outil open source ? Dès qu'une MàJ est disponible ? Dès qu'une MàJ fonctionnelle est disponible ? Dès qu'une MàJ de sécurité est disponible ? Ou autres ?