L'utilisation de logiciels open source est devenue presque omniprésente dans la communauté du développement logiciel. Les écosystèmes de développement sont devenus de plus en plus dépendants des bibliothèques et des packages tiers pour rationaliser le développement. La conscience de l'impact de l'augmentation de la prévalence des logiciels open source sur la sécurité des les organisations d'entreprises semblent également se développer.
De son côté, la communauté open source ne reste pas inactive. En novembre 2019, GitHub (acquis en 2018 par Microsoft) a annoncé le lancement du GitHub Security Lab avec un accès gratuit à son outil de révision de code CodeQL et l'ouverture de sa base de données Advisory au public.
Cependant, la question demeure : cette sensibilisation accrue se traduit-elle par une amélioration de la sécurité et des pratiques liées à l'utilisation de logiciels open source ? Dans le cadre de son rapport annuel sur l'état de la sécurité open source, le spécialiste de l’open source Snyk a tenté d’y répondre afin d'aider la communauté du développement à exploiter l'open source en toute sécurité.
L’univers de l’open source
La tendance à une croissance incroyable de l'utilisation et de la contribution des logiciels open source dans divers écosystèmes de développement de logiciels s'est poursuivie en 2019. Dans le rapport State of the Octoverse, GitHub a signalé que plus de 10 millions de nouveaux utilisateurs ont rejoint GitHub l'année dernière, ce qui porte le nombre total de développeurs sur cette plateforme à plus de 40 millions.
« Nos recherches sur plusieurs écosystèmes et référentiels étaient conformes aux tendances de croissance globales observées dans la communauté open source. En termes d'écosystèmes de développement, nous avons continué de suivre les progrès de cinq des écosystèmes open source les plus courants.
« La croissance des packages open source est principalement due à la popularité et à la croissance continues de l'écosystème JavaScript. À l'inverse, moins de nouveaux packages ont été créés pour Java et Ruby que l'année précédente. Dans l'ensemble, dans ces cinq écosystèmes, le nombre total de colis a considérablement augmenté. En particulier, npm a augmenté de plus de 33 % entre fin 2018 et fin 2019 ».
Les implications du développement open source pour la sécurité
Un facteur de risque clé lorsque les entreprises envisagent la sécurité de l'utilisation de leurs logiciels open source se concentre sur l'idée de maintenir une nomenclature logicielle. Les organisations ont du mal à comprendre quelles bibliothèques et quels packages open source sont inclus dans le logiciel qu'elles produisent. Ce défi vient de la difficulté à comprendre non seulement les dépendances open source directes définies dans leur code, mais aussi les dépendances indirectes qui en résultent.
« Dans notre enquête, nous avons interrogé les participants sur leur capacité à suivre les dépendances open source dans leur logiciel. Plus de 60 % ont déclaré ne pas avoir une bonne vue sur les arbres de dépendance complets de leur logiciel. En conséquence, il serait extrêmement difficile d'identifier si une vulnérabilité récemment découverte dans un package open source affecte ou non leur code ».
Lorsque vous considérez ces informations à la lumière de la croissance et de l'utilisation répandue d'écosystèmes comme Node.js, le risque que le développement open source pose aux organisations devient bien trop réel. Snyk déclare analyser chaque année les vulnérabilités qu’elle a identifiées dans des centaines de milliers de projets : « nous continuons de constater que la majorité des vulnérabilités Node.js, Java et Ruby identifiées sont introduites via des dépendances indirectes ».
Snyk a déclaré que 86% des bogues de sécurité JavaScript, 81 % des bogues Ruby et 74 % des bogues Java affectaient les bibliothèques qui étaient des dépendances des composants principaux chargés dans un projet.
Snyk fait valoir que les entreprises qui analysent leurs dépendances principales à la recherche de problèmes de sécurité sans explorer leur arbre de dépendance complet à plusieurs niveaux vers le bas finiraient par avoir des produits vulnérables aux bogues imprévus.
« Ces dernières années, nous avons vu qu'en termes de vulnérabilités totales identifiées dans les packages open source à travers les écosystèmes, Node.js et Java ont traditionnellement montré le plus grand nombre de nouvelles vulnérabilités chaque année. Cette tendance s'est poursuivie en 2019, peut-être – du moins dans une certaine mesure – en raison de la popularité relative de ces écosystèmes. Un signe potentiellement encourageant est que, dans les six écosystèmes populaires que nous avons examinés, il y avait moins de nouvelles vulnérabilités signalées en 2019 qu'en 2018. Bien qu'un an ne permette pas d’obtenir assez de données pour tirer une conclusion significative sur la poursuite ou non de cette tendance, ce pourrait être un signe positif que les efforts pour améliorer la sécurité des logiciels open source commencent à porter leurs fruits ».
Mais alors que les bogues de sécurité étaient répandus en JavaScript, Ruby et Java, ce n'était pas en PHP et Python, où la grande majorité des bogues étaient dans les dépendances directes (composants principaux). Cependant, il pourrait y avoir une explication.
« Je trouve honnêtement que c'est plus une question d'approche de développement au sein des écosystèmes eux-mêmes », a noté Alyssa Miller, conseillère en sécurité des applications chez Snyk. Et de continuer en ces termes :
« Les projets Java et Node.js, en particulier, semblent exploiter les dépendances beaucoup plus lourdes que les autres écosystèmes. En particulier, lorsque vous regardez la taille de l'écosystème Node.js, les packages qui se construisent ou tirent parti des fonctionnalités clés d'autres packages sont plutôt dans la norme.
« Demandez à n'importe quel développeur Node, et ils ont probablement une histoire d'attente pendant de longues périodes pour ouvrir un projet pendant que npm essaie de tirer toutes les dépendances nécessaires », a ajouté Miller. « L'un de nos exemples préférés est une application Java de 80 lignes qui spécifie 7 dépendances. Cependant, lorsque vous parcourez l'arborescence de dépendances entière, vous trouvez 59 sous-dépendances, et tout à coup, les 80 lignes de code se transforment en 740 000 lignes.
« Ce "danger étranger", comme nous aimons le surnommer, est au cœur de certaines violations importantes et une cause clé de complexité en termes de sécurité de la chaîne logistique des logiciels ».
Sévérité de vulnérabilités et impact sur les projets logiciels
« Comment ces vulnérabilités se traduisent-elles par leur impact sur les projets logiciels ? L'analyse de cette question est particulièrement importante, car elle montre à quel point les expositions aux attaques sont répandues dans la communauté des logiciels. Les vulnérabilités sont moins dangereuses si les packages concernés ne sont utilisés que dans une poignée de projets. Cependant, lorsqu'une vulnérabilité est signalée dans un package très populaire affectant des milliers de projets, cela augmente la probabilité que cette vulnérabilité soit exploitée à des attaquants.
« À cette fin, nous avons examiné le nombre de vulnérabilités identifiées dans les centaines de milliers de projets analysés et surveillés par Snyk. Les résultats étaient assez intéressants dans l'histoire qu'ils racontent. Malgré la forte prévalence de vulnérabilités de script intersite signalées, ces vulnérabilités n'ont affecté que 6,7 % des projets analysés ».
En clair, une découverte intéressante est que la plupart des nouvelles failles de sécurité découvertes en 2019 étaient des bogues de script intersite (XSS), mais malgré leur nombre élevé, celles-ci n'ont affecté qu'une petite partie des projets du monde réel.
Par contre, deux douzaines de bogues de pollution par les prototypes ont eu le plus grand impact de tous les bogues découverts l'année dernière, affectant plus de 115 000 projets open source différents (et probablement encore plus de projets privés).
Parmi ceux-ci, les bogues de pollution par les prototypes dans jQuery et LoDash ont eu le plus grand impact, car ces frameworks sont parmi les jeux d'outils de développement JavaScript les plus largement utilisés aujourd'hui.
« La pollution par les prototypes est un vecteur potentiel par lequel les attaquants peuvent introduire du code malveillant dans des packages par ailleurs fiables. La prévalence de la pollution par prototype dans un si grand nombre de projets est probablement le résultat de multiples vulnérabilités importantes découvertes en 2019. La première vulnérabilité a été découverte dans jQuery et divulguée via HackerOne. Compte tenu de la popularité relative de jQuery, un nombre important de projets ont été touchés
« En juillet de l'année dernière, les chercheurs de Snyk ont découvert un prototype de vulnérabilité à la pollution dans le très populaire package Lodash. La vulnérabilité, CVE-2019-10744, affectait toutes les versions du package au moment de la découverte et, par conséquent, son impact était très répandu, entraînant un nombre très élevé de projets impactés ».
Source : rapport
Et vous ?
Ce rapport vous semble-t-il crédible ou non ?
Quelle lecture faites-vous de ces différentes statistiques ?
Estimez-vous avoir une bonne vue de l'arbre de dépendances complet de vos logiciels ?
Voir aussi :
Apache Spark : la version 3.0 du framework open source de traitement big data disponible avec une amélioration des API Python, une meilleure compatibilité ANSI SQL et est deux fois plus rapide
L'Allemagne a proposé en open source tout le code de Corona-Warn-App, son application de contact tracing qui va lui coûter 3 millions d'euros tous les mois
Le nombre de vulnérabilités rapportées sur des logiciels open source a doublé en 2019, selon un rapport de RiskSense
Rust 1.44.0 est disponible et apporte la commande cargo tree à Cargo, pour l'impression d'un graphe arborescent des dépendances
Plus de 75% des vulnérabilités dans les projets open source résident dans des dépendances indirectes
Plutôt que dans les composants directement chargés
Plus de 75% des vulnérabilités dans les projets open source résident dans des dépendances indirectes
Plutôt que dans les composants directement chargés
Le , par Stéphane le calme
Une erreur dans cette actualité ? Signalez-nous-la !