Cela fait plus de trois ans que Log4Shell, une vulnérabilité critique dans une bibliothèque open source peu connue, a été découverte. Avec un score CVSS de 10, sa relative omniprésence et sa facilité d'exploitation en ont fait l'une des failles logicielles les plus graves de la décennie. Mais même des années après sa correction, plus d'un téléchargement sur dix de cet utilitaire populaire concerne des versions vulnérables. Il y a clairement quelque chose qui cloche quelque part.

Un nouveau rapport de la Linux Foundation apporte un éclairage précieux sur les défis systémiques auxquels sont confrontés l'écosystème open source et ses utilisateurs. Malheureusement, il n'existe pas de solution miracle, mais les utilisateurs finaux peuvent au moins atténuer certains des risques les plus courants en suivant les bonnes pratiques du secteur.

Une étude de cas catastrophique

Les composants logiciels libres sont omniprésents ; même les développeurs de logiciels propriétaires s’en servent pour accélérer leurs processus DevOps. Selon une estimation , 96 % des bases de code contiennent des composants libres, et les trois quarts présentent des vulnérabilités importantes. Sachant que près de sept mille milliards de composants ont été téléchargés en 2024, cela représente un risque potentiel considérable pour les systèmes du monde entier.

Log4j est un excellent exemple de ce qui peut mal tourner. Il met en lumière un problème majeur de visibilité : les logiciels ne contiennent pas seulement des « dépendances directes » (c’est-à-dire des composants open source auxquels un programme fait explicitement référence), mais aussi des dépendances transitives. Ces dernières ne sont pas importées directement dans un projet, mais utilisées indirectement par un composant logiciel. En réalité, ce sont des dépendances de dépendances directes. Comme Google l’expliquait à l’époque, c’est la raison pour laquelle tant d’instances de Log4j n’ont pas été détectées.

« Plus la vulnérabilité est profonde dans une chaîne de dépendance, plus il faut d’étapes pour la corriger », a-t-il noté.

Brian Fox, directeur technique de Sonatype, explique que la « mauvaise gestion des dépendances » dans les entreprises est une source majeure de risque de cybersécurité open source.

« Log4j est un bon exemple. Nous avons constaté que 13 % des téléchargements de Log4j concernaient des versions vulnérables, et ce, trois ans après la mise à jour de Log4Shell », explique-t-il à ISMS.online. « Ce problème n’est pas propre à Log4j non plus : nous avons calculé qu’au cours de l’année dernière, 95 % des composants vulnérables téléchargés avaient déjà une version corrigée. »

Toutefois, les risques liés à l'open source ne se limitent pas aux vulnérabilités potentielles apparaissant dans des composants difficiles à trouver. Les acteurs malveillants implantent également activement des logiciels malveillants dans certains composants open source, dans l'espoir qu'ils seront téléchargés. Sonatype a découvert 512,847 2024 packages malveillants dans les principaux écosystèmes open source en 156, soit une augmentation annuelle de XNUMX %.

Défis systémiques

Log4j n'était que la pointe de l'iceberg à bien des égards, comme le révèle un nouveau rapport sur Linux. Il met en évidence plusieurs défis majeurs à l'échelle de l'industrie liés aux projets open source :

Technologies obsolètes : De nombreux développeurs continuent d’utiliser Python 2, malgré la sortie de Python 3 en 2008. Cela engendre des problèmes d’incompatibilité et des logiciels pour lesquels aucun correctif n’est plus disponible. Les anciennes versions de logiciels persistent également dans les écosystèmes car leurs remplaçants intègrent souvent de nouvelles fonctionnalités, ce qui les rend moins attractives pour les utilisateurs.

Absence de schéma de dénomination standardisé : les conventions de dénomination des composants logiciels sont « uniques, individualisées et incohérentes », ce qui limite les initiatives visant à améliorer la sécurité et la transparence.

Un bassin limité de contributeurs :

« Certains projets OSS largement utilisés sont gérés par une seule personne. En examinant les 50 principaux projets non-npm, 17 % des projets avaient un développeur et 40 % avaient un ou deux développeurs qui représentaient au moins 80 % des commits », explique David Wheeler, directeur de la sécurité de la chaîne d'approvisionnement open source d'OpenSSF, à ISMS.online.

« Un projet avec un seul développeur présente un risque plus élevé d’abandon ultérieur. De plus, il présente un risque plus élevé de négligence ou d’insertion de code malveillant, car il peut manquer de mises à jour régulières ou de révisions par les pairs. »

Bibliothèques spécifiques au cloud : cela pourrait créer des dépendances vis-à-vis des fournisseurs de cloud, des failles de sécurité potentielles et un verrouillage vis-à-vis du fournisseur.

« Le principal enseignement à tirer est que l’open source continue de prendre de l’importance pour les logiciels qui alimentent l’infrastructure cloud », explique Fox de Sonatype. « L’utilisation de l’open source a connu une croissance en forme de crosse de hockey, et cette tendance ne fera que se poursuivre. Dans le même temps, nous n’avons pas constaté que le soutien, financier ou autre, aux mainteneurs de l’open source augmentait au même rythme que cette consommation. »

Langages non sécurisés en matière de mémoire : L’adoption du langage Rust, sécurisé en matière de mémoire, est en hausse, mais de nombreux développeurs privilégient encore le C et le C++, qui contiennent souvent des vulnérabilités liées à la sécurité de la mémoire.

Comment ISO 27001 peut vous aider

Comme le souligne Hervé Beraud, contributeur chez Red Hat , nous aurions dû anticiper les problèmes de Log4Shell, car l'utilitaire lui-même (Log4j) n'avait pas fait l'objet d'audits de sécurité réguliers et était maintenu uniquement par une petite équipe de bénévoles, un risque déjà mentionné. Il affirme que les développeurs doivent examiner plus attentivement les composants open source qu'ils utilisent, en s'interrogeant sur le retour sur investissement, les coûts de maintenance, la conformité légale, la compatibilité, l'adaptabilité et, bien sûr, en vérifiant si des tests de vulnérabilité sont effectués régulièrement.

Les experts recommandent également des outils d’analyse de la composition logicielle (SCA) pour améliorer la visibilité sur les composants open source. Ces outils aident les organisations à maintenir un programme d’évaluation et de correctifs continus. Mieux encore, envisagez une approche plus globale qui couvre également la gestion des risques dans les logiciels propriétaires. La norme ISO 27001 fournit un cadre structuré pour aider les organisations à améliorer leur posture de sécurité open source.

Cela comprend de l’aide pour :

  • Évaluations et atténuations des risques pour les logiciels open source, y compris les vulnérabilités ou le manque de support
  • Maintenir un inventaire des logiciels open source pour garantir que tous les composants sont à jour et sécurisés
  • Contrôles d'accès pour que seuls les membres autorisés de l'équipe puissent utiliser ou modifier des logiciels open source
  • Politiques et procédures de sécurité sur l'utilisation, la surveillance et la mise à jour des composants
  • Gestion des relations avec les fournisseurs pour garantir que les fournisseurs de logiciels open source adhèrent aux normes et pratiques de sécurité
  • Gestion continue des correctifs pour remédier aux vulnérabilités de sécurité des logiciels open source
  • Processus de gestion des incidents, y compris la détection et la réponse aux vulnérabilités ou aux violations provenant de l'open source
  • Promotion d'une culture d'amélioration continue pour renforcer l'efficacité des contrôles de sécurité
  • Formation et sensibilisation des collaborateurs pour comprendre les risques liés aux logiciels open source

Il y a encore beaucoup à faire, notamment des programmes gouvernementaux de chasse aux bugs, des efforts de sensibilisation et des financements communautaires de la part des géants de la technologie et d'autres grandes entreprises utilisatrices de logiciels open source. Ce problème ne sera pas résolu du jour au lendemain, mais au moins les choses ont commencé à tourner.