Les bogues de sécurité dans les packages open source peuvent prendre beaucoup de temps à être corrigés, sont souvent associés à des changements non liés à la sécurité et à la rupture, et peuvent passer inaperçus pour les projets clients, selon une étude menée par des chercheurs de la North Carolina State University.

L’étude, qui a été menée sur des milliers de packages gratuits et open source dans sept écosystèmes, met en évidence certaines des lacunes des pratiques de sécurité de la communauté des logiciels open source.

Mises à jour de sécurité tardives, opaques et cassantes

Les chercheurs ont utilisé les bases de données de vulnérabilités Snyk et NVD pour suivre 4 377 avis de sécurité et les modifications apportées à leurs référentiels correspondants sur des plates-formes telles que NPM, PIP et NuGet.

L’étude concentré sur le délai entre le développement du correctif de sécurité et sa publication sur le référentiel, la documentation du correctif dans le référentiel, la taille et les caractéristiques des versions de sécurité, et le temps nécessaire pour qu’un avis soit publié sur Snyk ou NVD.

Les chercheurs ont constaté que la version de sécurité médiane intervient dans les quatre jours suivant le correctif correspondant. Mais dans certains cas, les versions de sécurité sont retardées jusqu’à 20 jours. « Un tel retard crée une fenêtre d’opportunité pour les attaquants observateurs, qui seront informés de la vulnérabilité lorsqu’un correctif n’est toujours pas disponible pour les projets clients », préviennent les chercheurs.

Alors que la plupart des packages open source ont documenté leurs correctifs de sécurité, seuls 39% ont explicitement mentionné les implications de sécurité des correctifs. « Le manque de documentation appropriée peut empêcher les projets clients de connaître les correctifs de sécurité disponibles », écrivent les chercheurs.

Dans certains cas, les chercheurs ont constaté que les mainteneurs regroupent les correctifs de sécurité avec des modifications fonctionnelles sans rapport, ce qui peut entraîner une incompatibilité en amont et des complications de mise en œuvre pour les projets clients.

« Notre analyse suggère que les packages open source ne suivent pas la recommandation de publier des versions distinctes pour les correctifs de sécurité », écrivent les chercheurs.

Enfin, les chercheurs ont observé qu’il y a parfois un décalage considérable entre une version de sécurité sur le référentiel et une publication d’avis dans une base de données de vulnérabilités. Cela peut entraîner des projets clients recevant une notification tardive des vulnérabilités.

« Un tel retard élargit encore la fenêtre d’opportunité pour les attaquants… car les projets clients peuvent encore ignorer les vulnérabilités connues et les versions de sécurité disponibles », écrivent les chercheurs.

Nouvelle approche nécessaire

Pour améliorer la sécurité des logiciels open source, les chercheurs recommandent aux mainteneurs de paquets de garder les correctifs de sécurité privés jusqu’à leur publication. Parfois, les messages de validation concernant les problèmes de sécurité sont accessibles au public et faciles à repérer avant même la publication du correctif, ce qui peut conduire à la découverte du bogue non corrigé par des parties indésirables.

Les chercheurs suggèrent que les responsables du projet créent un fork privé pour la version de sécurité et ne la rendent visible publiquement qu’au moment de la prochaine version.

Les chercheurs recommandent également d’utiliser des étiquettes, des métadonnées et des en-têtes pour marquer les versions de sécurité. Cela permettra aux projets clients et aux utilisateurs du package de repérer plus facilement les versions de sécurité, même s’il y a un décalage jusqu’à ce que l’avis soit publié sur une base de données de vulnérabilités.

« Un processus standardisé permettrait aux gestionnaires de packages d’identifier automatiquement les versions de sécurité et de notifier les projets clients lors des prochaines versions de développement des clients », ont-ils déclaré.

L’étude suggère également la mise en place de métriques pour mesurer la conformité des packages open source aux pratiques de sécurité. D’une part, cela aidera les projets clients à avoir une meilleure visibilité sur la fiabilité de leurs dépendances, et d’autre part, cela encouragera les mainteneurs de paquets à adopter de bonnes pratiques de sécurité.

« Le recours aux packages open source dans le développement de logiciels modernes fait que la santé de la sécurité des projets clients est directement corrélée à la santé de la sécurité de leurs packages de dépendance. Par conséquent, les projets doivent sélectionner les dépendances en gardant à l’esprit les pratiques de sécurité d’un package », écrivent les chercheurs.