Les bonnes nouvelles d’abord : selon l'Open Source Security Foundation (OpenSSF), il faudra dépenser moins de 150 millions de dollars pour sécuriser les logiciels open source. Autre bonne nouvelle : les géants de l'industrie que sont Amazon, Intel, Google et Microsoft se sont déjà engagés à verser 30 millions de dollars. Donc, pas plus de 120 millions de dollars pour sécuriser l'avenir de l'open source, n'est-ce pas ? Eh bien, non ! Car la mauvaise nouvelle, c’est qu'aucune approche généralisée de la sécurité des logiciels open source ne donnera de résultats. Comme l’a déclaré Brian Behlendorf, directeur général de l'OpenSSF, lors d'une récente conférence de presse, « le plan en 10 points de l’OpenSSF pour favoriser une approche multidimensionnelle de la sécurité est formidable, et il a plus de chances de réussir que les approches plus fragmentaires du passé, car aucune cause ou approche unique ne peut tout résoudre ». Et il a raison. Mais c'est précisément pour cela que je crains que notre manière d’aborder encore une fois la sécurité des logiciels open source ne soit erronée.

Le plan de l’OpenSSF

Je ne veux pas faire croire que je dénigre ces efforts. Comme je l'ai déjà écrit, je suis optimiste. Les tentatives de l'OpenSSF pour rallier l'industrie tranche de façon importante avec les orientations précédentes. Je trouve aussi que le processus open source par lequel nous trouvons et corrigeons les bogues est la bonne méthode pour aborder la sécurité logicielle. L'association offre une chance de coordonner les efforts.

De ce point de vue-là, le plan en 10 points de l'organisation est encourageant :

- Offrir une formation à la sécurité à tous ceux qui travaillent dans la communauté.

- Établir un tableau de bord d'évaluation des risques pour les principaux composants open-source.

- Accélérer l'adoption des signatures numériques.

- Remplacer les langages non sûrs pour la mémoire afin de supprimer la cause première de nombreux bogues.

- Mettre en place une équipe de réponse aux incidents dédiée aux logiciels open source.

- Améliorer l'analyse du code par les mainteneurs et les experts afin de trouver les bogues plus rapidement.

- Réaliser des examens de code par des tiers pour 200 des composants les plus critiques.

- Coordonner le partage des données de recherche à l'échelle du secteur.

- Améliorer les outils et la formation relatifs à la nomenclature des logiciels (SBOM) afin d'en favoriser l'adoption.

- Améliorer les 10 systèmes de construction, les gestionnaires de paquets et les systèmes de distribution les plus critiques avec de meilleurs outils de sécurité et de meilleures pratiques.

Cette approche intelligente et holistique de la sécurité devrait inciter davantage encore les développeurs à aimer l'open source. En fait, quand je dirigeais l'équipe de stratégie et de marketing Open Source Strategy and Marketing d'AWS, nous avions commandé une enquête en 2020 pour savoir pourquoi les développeurs aimaient l'open source. En tête de liste figurait la sécurité :

Les développeurs ayant répondu à cette enquête connaissaient Heartbleed et les autres vulnérabilités de projets open source critiques. Mais ils s’étaient quand même prononcés en faveur de l'open source. Grâce aux efforts de l'OpenSSF, beaucoup d’autres développeurs pourront choisir l'open source plus facilement. Il ne faut pas imaginer que ce financement ou tout autre investissement résoudra les problèmes de sécurité des logiciels open source, au même titre qu’aucune somme d'argent n'a rendu AWS, Google ou Microsoft imperméables aux vulnérabilités logicielles. Tous les logiciels sont bogués, maintenant et pour toujours.

Le processus, meilleur que le plan

Le processus de développement des logiciels libres a toujours été le meilleur garant de leur sécurité. Et cela reste vrai même avec l'excellent plan de l’OpenSSF. Par exemple, le plan promet de « procéder à des examens de code par une tierce partie pour 200 des composants les plus critiques ». C'est formidable ! Mais comment définir un « composant critique » ? La réponse ? Une faille de sécurité qui met en péril l'industrie. Idem pour « établir un tableau de bord d'évaluation des risques pour les principaux composants open source ». Si nous étions capables de décider à l'avance quels composants open source sont les meilleurs, nous aurions moins de failles de sécurité car nous trouverions des moyens de les financer afin que les développeurs concernés puissent mieux prendre soin de leur propre sécurité.

Bien sûr, souvent, les développeurs responsables des « meilleurs composants open source » ne veulent pas consacrer tout leur temps à sécuriser leurs logiciels. Cela varie beaucoup d'un projet à l'autre, mais les développeurs concernés ont souvent des motivations très différentes pour justifier leur implication. Il n'existe pas d'approche unique pour financer le développement de l'open source (même si je continue à penser que l'open source le plus durable bénéficie d'une participation importante des entreprises, qu'il s'agisse d'une communauté (Kubernetes) ou d'une seule entreprise (MySQL/Oracle). Il est vrai aussi que les pirates sont incroyablement innovants dans la manière d’exposer les lacunes des logiciels propriétaires et open source. Il est quasi certain qu'ils creusent déjà dans des composants que personne ne considère comme « critiques » ou « de premier plan » aujourd'hui, mais qui le deviendront quand le logiciel sera compromis. C'est la raison pour laquelle je préfère les approches « méta » du plan en 10 points de l’OpenSSF, comme le remplacement des langages non sécurisés en mémoire (par des langages comme Rust) ou l'adoption de signatures numériques. Ces approches permettent d'intégrer la sécurité dans un projet tout en laissant au processus de développement le soin de corriger les bogues quand ils sont découverts.

Il faut le répéter : la popularité croissante de l'open source a entraîné une prolifération des bogues, comme l'ont expliqué WhiteSource et d'autres entreprises. L'univers du code open source s'étend à une vitesse spectaculaire, et les vulnérabilités se sont développées en parallèle. Identifier à l'avance tous ces composants critiques est une tâche monumentale, voire impossible. Alors, ce plan en 10 points va-t-il gaspiller inutilement de l’argent ? Non, pas du tout. Mais je crains que nous ne nous trompions en croyant que 150 millions de dollars vont nous permettre d'assurer la sécurité des logiciels open source une fois pour toutes. Ce ne sera pas le cas. Même s'ils sécurisaient les composants d'aujourd'hui, il faudrait encore que l'industrie mette à niveau les anciens systèmes utilisant des « composants open source critiques » plus anciens et moins sûrs. Par conséquent, la seule façon pour faire de la sécurité des logiciels open source une réalité est que chaque projet individuel prenne en charge la sécurité et la prenne très au sérieux, et que chaque utilisateur de ce projet la prenne également très au sérieux. L'OpenSSF ne permettra pas à tout le monde d'atteindre cet objectif, mais si cela peut aider, ce serait une bonne façon de dépenser ces 150 millions de dollars.

Matt Asay, contributeur et travaille chez MongoDB