L'Open Source Security Foundation, une création tant attendue

L'Open Source Security Foundation (OpenSSF) existe depuis quelques mois déjà, mais la question est de savoir pourquoi sa création a pris autant de temps. Pendant des années, des attaquants ont pu exploiter des bogues dans OpenSSL, Apache Struts et d'innombrables autres projets, négligés par paresse. On ne peut que regretter de ne pas avoir pris, depuis longtemps, l’initiative de combiner les efforts pour protéger la chaîne d'approvisionnement en logiciels libres dont dépend chaque entreprise. Mais nous ne l'avons pas fait. Ce n'est qu'en 2020 que nous avons décidé, en tant qu'industrie, de cesser d’avoir une approche fragmentée de la sécurité. Pourquoi ? C'est la question que j'ai posée à Kim Lewandowski, chef de produit chez Google et membre du conseil d'administration de l'OpenSSF. Selon Mme Lewandowski, « nous dépendons tous de l'open source, et il n'y a aucune raison que chacun essaye de résoudre ce problème individuellement ou selon des modalités en silo ». Elle a raison, mais pourquoi a-t-il fallu autant de temps pour parvenir à ce constat ?

Vous et vous et vous et vous et...

L'un des problèmes de la sécurité des logiciels open source, c’est qu’il ne concerne pas une seule entreprise. Goldman Sachs, par exemple, exige que les logiciels nécessaires à son activité soient sécurisés. Mais, au nom de quoi la banque d’investissement devrait-elle payer pour sécuriser des logiciels que tout le monde utilise ? Idem pour Google, qui a contribué et utilise beaucoup de logiciels open source. Comme l'a déclaré Mme Lewandowski, « Google ne va pas réécrire tous les logiciels open source disponibles aujourd’hui sur Internet, et que nous et nos clients utilisons ». Et même si Google voulait le faire, ce ne serait pas possible, car il y aurait simplement trop de choses à faire. Bien sûr, l'entreprise pourrait corriger OpenSSL ou Apache Struts ou n'importe quel autre projet actuellement vulnérable. Mais l'univers du code open source est gigantesque et en expansion permanente. Ce n'est pas une tâche qu’une entreprise peut raisonnablement accomplir toute seule.

Des projets différents, des besoins différents

Cet état de fait est compliqué par la diversité des besoins de chaque projet. Selon Kim Lewandowski, chaque projet est différent, et même en consacrant de l'argent au problème de la sécurité, cela ne résoudrait pas nécessairement la question. « Il s’est trouvé des cas où certaines personnes chargées de la maintenance d’un projet refusaient soit d’être payées, soit simplement de s’impliquer dans des modifications dont nous avions besoin ». D'autres projets ont besoin d’être aidés pour les audits de sécurité, un aspect que l'OpenSSF a prévu de prendre en charge. De tels audits sont actuellement menés par la Cloud Native Computing Foundation (CNCF) et d'autres fondations ou organisations, mais en l'état, ils ne permettent pas d’aller au bout du processus. Selon Kim Lewandowski, « certains audits sont excellents et ont permis de découvrir beaucoup de choses, mais si l'auditeur ne va pas au bout de l’audit, les projets peuvent se retrouver bloqués avec une montagne de corrections en suspens ». Il arrive parfois que « les gens se contentent aussi de corriger des bogues, juste pour réussir l'audit ou en quête de solution rapide, mais sans résoudre le problème de sécurité sous-jacent ».

Alors, comment faire pour rassembler une communauté dont la charge consistera autant à identifier les problèmes qu’à les résoudre ? Mme Lewandowski a expliqué que l'OpenSSF envisageait actuellement différentes modalités pour inciter les contributeurs à résoudre les vulnérabilités de sécurité, même s’il est probable que cela ne sera pas forcément plus simple. Par exemple, certaines entreprises sont prêtes à apporter l'expertise de leurs ingénieurs pour aider à corriger les bogues, ce qui est une bonne chose. Mais l’OpenSSF peut-elle les tenir responsables de ces modifications ? Par exemple, si un certain nombre d’entreprises, membres de l’OpenSSF, engagent chacune cinq ingénieurs, « comment faire preuve de responsabilité pour que tous ces ingénieurs fassent exactement ce que nous attendons qu'ils fassent au sein de la Fondation ? Ce sont des problèmes difficiles, et nous avons besoin d’une aide supplémentaire pour cela ». Malgré ces défis importants, des progrès ont été réalisés. En partenariat avec l'Internet Security Research Group (ISRG), par exemple, la populaire interface de la bibliothèque de requêtes aux URL pour les clients en ligne de commande cURL a été dotée d'un nouveau système de sécurité écrit en langage RUST qui promet d'améliorer encore la sécurité. Cette collaboration est un excellent exemple des initiatives que l’OpenSSF peut favoriser. Certes, mais pourquoi cela a-t-il pris autant de temps ?

Mieux vaut tard que jamais

« Il est assez inquiétant de voir le nombre de similitudes que l'on peut établir avec la pandémie actuelle », a fait remarquer Kim Lewandowski. « C'est comme si tout le monde avait évité d'en faire trop jusqu'à ce que la pandémie nous affecte tous ». Même s’il n’y a pas eu d'événement déclencheur pour l'OpenSSF, cela fait des années qu’un battement de tambour persistant nous alerte sur la nécessité de cette initiative. Parfois, nous avons réagi. La vulnérabilité Heartbleed présente dans la bibliothèque de cryptographie OpenSSL a poussé à la création de la Core Infrastructure Initiative, menée par la Linux Foundation. Des actions comparables ont été entreprises ailleurs en réponse à différentes menaces. Malgré cela, ces efforts étaient encore trop largement cloisonnés. Certains de ces silos sont le fait d'entreprises qui exploitent des logiciels libres sans le savoir (pas toujours de manière très heureuse).

Les entreprises peuvent penser qu'elles paient pour des logiciels propriétaires mais, comme l’avaient fait remarquer la plateforme open source de gestion de la sécurité et de la conformité des licences WhiteSource et d'autres, plus de 95 % des logiciels comprennent tous des composants open source. Quelle que soit la licence du produit, il y a toujours de l'open source à l'intérieur. Cette réalité commence à s'imposer. C’est pourquoi, le moment est venu pour l'OpenSSF d'avoir un impact significatif sur l'industrie. Bien sûr, comme l'a souligné Mme Lewandowski, « la manière d’en parler demande de la mesure et un sens de l’équilibre. Il faut sensibiliser les gens tout en évitant de faire fuir tout le monde ». On pourrait l’exprimer ainsi : l'open source est aujourd'hui à la base de tous les logiciels, et ces derniers jouent un rôle de plus en plus important dans notre vie. Le processus d’identification et de correction des bogues, qui garantit la qualité de l'open source, est la meilleure approche pour améliorer à la sécurité des logiciels, mais celui-ci serait encore plus efficace si nous coordonnons nos efforts. L'OpenSSF nous offre une chance d'y parvenir et nécessite la participation non seulement des fournisseurs de logiciels, d’entreprises comme JP Morgan Chase, Facebook, Uber, mais aussi, espérons-le, de la vôtre.