La sécurité des logiciels open source pourrait bientôt s'améliorer

Les relations entre les professionnels de la cybersécurité et les développeurs de logiciels ont toujours été quelque peu tendues, car bon nombre des crises de sécurité qui secouent les entreprises sont liées à des failles dans les applications. Bien qu'il arrive que ces failles soient le résultat d'une erreur humaine, le problème peut également venir d'applications natives codées en C ou C++, particulièrement vulnérables aux attaques par dépassement de tampon.

Fort heureusement, la communauté mondiale se penche de plus en plus sur la question de la sécurité des applications en raison de la médiatisation de nombreuses cyberattaques. Une grande partie de cette attention se concentre sur les logiciels open source, tels que l’outil de gestion des journaux Log4j, majoritairement utilisé pour les applications Java, dont on a récemment découvert qu'il présentait des vulnérabilités critiques que de nombreuses entreprises s'efforcent encore de corriger à l'heure actuelle. Cette crise a conduit l'administration Biden à publier un décret visant à améliorer les processus de maintien de la sécurité des applications pour les agences fédérales. S'en est suivie une réunion au cours de laquelle le gouvernement a exhorté les dirigeants de la communauté des logiciels open source à trouver des solutions pour renforcer leur sécurité.

Comment renforcer la sécurité des logiciels open source ?

L'Open Source Security Foundation (OpenSSF), une branche de la Linux Foundation, vient de dévoiler un plan visant à renforcer la sécurité des logiciels open source en se concentrant sur 10 flux d'investissement qui nécessiteraient plus de 150 millions de dollars. Ce financement devrait couvrir tous les domaines, de la formation des développeurs en cybersécurité à la création d’outils gratuits d'analyse du code avant son déploiement dans un environnement de production, en passant par la mise en place d’une équipe de réponse aux incidents qui pourrait notamment réduire le temps nécessaire à la correction des vulnérabilités de type « zero-day » récemment découvertes. Les fonds nécessaires pour atteindre cet objectif devraient provenir des gouvernements du monde entier et des entreprises qui utilisent aujourd'hui largement les logiciels open source.

Même si 150 millions de dollars peut sembler être une somme conséquente, ce n'est rien en comparaison des dégâts économiques déjà infligés par des vulnérabilités telles que Log4jShell. Si l'on multiplie cette somme par le nombre de projets de logiciels open source susceptibles de mettre au jour des vulnérabilités de type « zero-day » similaires, il semble évident qu'il s'agit d'un montant relativement faible pour réparer des logiciels évalués à plusieurs billions de dollars dont dépendent les économies mondiales. Les professionnels de la cybersécurité se demandent légitimement pourquoi il a fallu autant de temps à la communauté des logiciels pour prendre conscience des réels risques encourus pour l'économie mondiale.

Rappels importants

Bien entendu, aucune des solutions envisagées n'aura d'effet immédiat. N'oublions pas que, depuis des dizaines d'années, nous nous appuyons sur des outils et techniques défaillants pour créer des applications. Nous ne résoudrons donc pas les problématiques soulevées du jour au lendemain. Cependant, les professionnels de la cybersécurité peuvent se consoler en se disant que la sécurité des applications devrait s’améliorer dans les mois et les années à venir.

En attendant, ces derniers devraient rappeler aux développeurs que, quel que soit le degré de popularité d'un projet open source, ils ne doivent en aucun réutiliser le code fourni par un étranger. La plus grande menace qui pèse aujourd'hui sur les chaînes logistiques logicielles est le simple fait que les développeurs ont trop confiance en l'intégrité des référentiels qu'ils utilisent pour accéder au code, que, bien souvent, ils se contentent de « copier-coller » dans des applications. Aux côtés des équipes de cybersécurité qui les soutiennent, ils passent ensuite des mois à rechercher des instances de ce code dès qu’une vulnérabilité de type « zero-day » est inéluctablement découverte.