Veracode fait un état des lieux de la sécurité des bibliothèques open source

Et propose aux développeurs une répartition des types de faille sur les langages de programmation

Nombreuses sont les applications modernes qui font appel à des bibliothèques open source, ces dernières venant les fournir en fonctionnalités qui seraient extrêmement fastidieuses à écrire à partir de zéro. Que nous recherchions une bibliothèque relativement commune avec un ensemble de fonctionnalités riche, comme OpenSSL, ou une bibliothèque JavaScript à quatre lignes qui offre une compatibilité descendante, tout ce code importé représente une fonctionnalité que les développeurs n'ont pas créée, mais devient du code qu’ils doivent gérer.

Veracode, société spécialisée dans la sécurité des applications s’est intéressée à la fréquence à laquelle les bibliothèques open source sont utilisées, les types de faille qui peuvent être rencontré, etc.

Tout d’abord, le spécialiste a analysé plus de 85 000 applications dans sa base de données qui représentaient plus de 351 000 bibliothèques externes uniques. Il a ensuite découpé et réparti ces données par langages, type de faille, dépendances et exploits connus pour leurs failles.


Voici quelques-uns des points clés :

• JavaScript : la plupart des applications JavaScript de l’ensemble de données ont des centaines de dépendances, le nombre de dépendances atteignant plus de 1 000 bibliothèques différentes dans certaines applications. Bien que ce nombre puisse être impressionnant, Veracode rappelle qu’il est utile de garder à l'esprit que la communauté JavaScript a une propension à imbriquer de très petites unités de fonctionnalités. Cela signifie que JavaScript possède un grand nombre de très petites bibliothèques.
• Python : le classement de Python a surpris Veracode, compte tenu de leur expérience personnelle en tant que développeurs Python. Alors que le gestionnaire de packages Python le plus populaire, PyPi, a environ 1 / 5^ème du nombre de packages trouvés dans le référentiel JavaScript le plus populaire npm (221k c. 1.2M), la plupart des applications Python ont seulement 1 / 100^ème du nombre de bibliothèques trouvées dans une bibliothèque typique Application JavaScript.
• Go et Swift : en revanche, Go et Swift ont tendance à n'inclure que quelques dizaines de bibliothèques au plus, ce qui peut être fonction de leurs écosystèmes moins développés et plus petits.

Le rapport présente d’autres données intéressantes. Par exemple, il note que la bibliothèque JavaScript la plus utilisée est héritée, située dans npm. Ce package est constitué de 36 lignes de code, ce qui fournit une enveloppe fine autour de la fonctionnalité hérite du sous-module utils de node.js lorsqu'elle est disponible et fournit sa propre version lorsque ce module natif n'est pas disponible. Il est heureusement exempt de défauts sur la base de l'analyse actuelle.


Type de dépendances

Ces bibliothèques qui sont incluses indirectement sont des dépendances transitives, et elles peuvent se transformer en beaucoup plus de code inclus en cascade dans une application que ne le prévoyait un développeur. Il peut être important de comprendre les dépendances pour identifier où les failles peuvent entrer dans une application. Puisqu'elles ne sont pas explicitement incluses par les développeurs, une grande partie des dépendances transitives peuvent représenter une surface d'attaque qui est en dessous de la visibilité de surface des responsables. Cette dette de dépendance cachée représente une charge de travail supplémentaire, et peut-être inattendue, pour la vérification et la maintenance continues d'une application.

Veracode a donné trois degrés de dépendance :

• Dépendance directe : si l'application possède la plupart (plus de 66%) de ses dépendances d'appels explicites, Veracode les compte dans la catégorie directe.
• Dépendance transitive : si l'application a relativement peu (moins de 33%) de bibliothèques explicitement liées et récupère plutôt la plupart de ses bagages de bibliothèque à partir de ces appels transitifs, Veracode les place dans la catégorie transitive.
• Dépendance équilibrée : si l'application est relativement divisée entre les sources directes et transitives.

Failles dans les bibliothèques open source

Veracode a fait un classement par langage en demandant aux développeurs de garder à l'esprit que si une bibliothèque a plusieurs versions couramment utilisées, cette bibliothèque peut être comptée plusieurs fois.

« À mesure que le pourcentage de bibliothèques contenant une faille augmente, il devient plus important de connaître - et de pouvoir gérer - les bibliothèques défectueuses. Par exemple, si vous choisissez une bibliothèque PHP aléatoire, elle a plus que probablement un défaut. C'est particulièrement important avec PHP, car il est souvent sollicité pour les applications Web côté serveur et, par conséquent, fréquemment exposé à une grande communauté de menaces ».

• Swift : la palme revient à Swift, avec son utilisation spécialisée dans l'écosystème Apple, qui a la plus haute densité de défauts, mais il a un faible pourcentage global de bibliothèques défectueuses.
• PHP : comparé à Go, PHP a un taux encore plus élevé de bibliothèques défectueuses et plus du double de la densité des défauts dans une bibliothèque donnée
• .NET: il y a un contraste entre Swift et .NET, qui gère un pourcentage incroyablement faible de bibliothèques défectueuses sur une population qui est plus de 17 fois plus grande que Swift.
• Go: Go a un pourcentage élevé de bibliothèques avec des défauts, mais un nombre global de défauts faible par bibliothèque individuelle.

Veracode s’est également intéressé aux types de faille, qui n’ont bien sûr pas la même sévérité, puis à leur répartition sur les langages de programmation.


Un défaut dans une bibliothèque va se répercuter en cascade sur toutes les applications utilisant ce code. Selon Chris Eng, directeur de la recherche chez Veracode, « les logiciels open source présentent une variété surprenante de défauts. La surface d'attaque d'une application n'est pas limitée à son propre code et au code des bibliothèques explicitement incluses, car ces bibliothèques ont leurs propres dépendances. En réalité, les développeurs introduisent beaucoup plus de code, mais s’ils connaissent et appliquent les correctifs de manière appropriée, ils peuvent réduire l’exposition aux risques ».

Entre autres constatations, Veracode a noté que les bibliothèques avec de nombreuses failles sont souvent utilisées par les développeurs : « Bien qu'il puisse exister des caractéristiques distinctes sur lesquelles s’appuient les développeurs pour choisir les bibliothèques qu'ils incluent à leur projet, il ne semble pas que les failles de sécurité en soient une ».

Mais l’entreprise précise que « Les défauts peuvent être corrigés manuellement ou atténués d'une autre manière. La présence d'un défaut dans une bibliothèque ne signifie pas que les octets défectueux se trouveront sur le chemin exécutable de l'application. De plus, ce n'est pas parce qu'un défaut existe qu'il y a un attaquant impatient et prêt à l'exploiter ».

Selon le rapport, les failles introduites par les bibliothèques dans la plupart des applications peuvent être corrigées avec seulement une mise à jour de version mineure ; les mises à niveau majeures de la bibliothèque ne sont généralement pas nécessaires.

Toutes les bibliothèques n'ont pas de vulnérabilités et d'expositions communes (CVE) - cela signifie que les développeurs ne peuvent pas se fier uniquement aux CVE pour comprendre les défauts des bibliothèques. Par exemple, plus de 61% des bibliothèques défectueuses en JavaScript contiennent des vulnérabilités sans CVE correspondantes.

Source : Veracode

Et vous ?

Que pensez-vous de cette étude de Veracode ? Est-elle crédible selon vous ?
Avez-vous déjà inclus une ou plusieurs bibliothèques open source dans vos projets ? Si oui, quelles bibliothèques ? Dans quel langage ?
Quels sont vos critères de sélection en matière de bibliothèque open source ?
Procédez-vous régulièrement à des mises à jour ?