Problèmes de dépendance : résoudre le problème mondial de sécurité des logiciels open source – War on the Rocks

L’idée d’un programmeur solitaire s’appuyant sur son propre génie et sa perspicacité technique pour créer le prochain grand logiciel était toujours exagérée. Aujourd’hui, c’est plus un mythe que jamais. Les forces concurrentielles du marché signifient que les développeurs de logiciels doivent s’appuyer sur du code créé par un nombre inconnu d’autres programmeurs. En conséquence, la plupart des logiciels sont mieux considérés comme des composants de bricolage divers, généralement open source, souvent appelés dépendances, assemblés avec des morceaux de code personnalisé dans une nouvelle application.

Ce paradigme d’ingénierie logicielle, les programmeurs réutilisant des composants logiciels open source plutôt que de dupliquer à plusieurs reprises les efforts des autres, a conduit à des gains économiques massifs. Selon la meilleure analyse disponible, les composants open source représentent désormais 90 % de la plupart des applications logicielles. Et la liste des composants open source économiquement importants et largement utilisés, le cadre d’apprentissage en profondeur de Google TensorFlow ou son concurrent PyTorch sponsorisé par Facebook, la bibliothèque de chiffrement omniprésente OpenSSL ou le logiciel de gestion de conteneurs Kubernetes est longue et s’allonge. La communauté militaire et du renseignement dépend également des logiciels open source : des programmes comme Palantir sont devenus cruciaux pour les opérations de lutte contre le terrorisme, tandis que le F-35 contient des millions de lignes de code.

Le problème est que la chaîne d’approvisionnement des logiciels open source peut introduire des faiblesses de sécurité inconnues, voire intentionnelles. Une analyse précédente de toutes les compromissions de la chaîne d’approvisionnement logicielle signalées publiquement a révélé que la majorité des attaques malveillantes ciblaient les logiciels open source. En d’autres termes, les attaques de la chaîne d’approvisionnement logicielle qui font la une des journaux sur des logiciels propriétaires, comme SolarWinds, constituent en fait la minorité des cas. En conséquence, arrêter les attaques est désormais difficile en raison de l’immense complexité de l’arbre de dépendances logicielles moderne : des composants qui dépendent d’autres composants qui dépendent d’autres composants À l’infini. Savoir quelles sont les vulnérabilités de votre logiciel est un travail à plein temps et presque impossible pour les développeurs de logiciels.

Heureusement, il y a de l’espoir. Nous recommandons trois étapes que les producteurs de logiciels et les régulateurs gouvernementaux peuvent suivre pour rendre les logiciels open source plus sûrs. Tout d’abord, les producteurs et les consommateurs doivent adopter la transparence des logiciels, en créant un écosystème vérifiable où les logiciels ne sont pas simplement des blobs mystérieux transmis via une connexion réseau. Deuxièmement, les concepteurs de logiciels et les consommateurs doivent adopter des outils d’intégrité et d’analyse des logiciels pour permettre une gestion éclairée des risques de la chaîne d’approvisionnement. Troisièmement, les réformes gouvernementales peuvent contribuer à réduire le nombre et l’impact des compromissions sur les logiciels open source.

Le chemin de la dépendance

Les récits conventionnels de l’essor des composants logiciels réutilisables le datent souvent des années 1960. Des experts en logiciels tels que Douglas McIlroy de Bell Laboratories avaient noté les dépenses énormes liées à la création de nouveaux logiciels. Pour faciliter la tâche, McIlroy a appelé à la création d’une sous-industrie des composants logiciels pour produire en masse des composants logiciels qui seraient largement applicables sur les machines, les utilisateurs et les applications ou, en d’autres termes, exactement ce que les logiciels open source modernes offrent.

Lorsque l’open source a commencé, il s’est d’abord regroupé autour de communautés techniques qui assuraient la supervision, une partie de la gestion et le contrôle de la qualité. Par exemple, Debian, le système d’exploitation basé sur Linux, est pris en charge par un réseau mondial de développeurs de logiciels open source qui maintiennent et implémentent des normes sur les packages logiciels qui feront ou ne feront pas partie de la distribution Debian. Mais cette surveillance relativement étroite a cédé la place à un système plus libre et sans doute plus innovant de registres de paquets largement organisés par langage de programmation. Considérez ces registres comme des magasins d’applications pour les développeurs de logiciels, permettant au développeur de télécharger gratuitement des composants open source à partir desquels créer de nouvelles applications. Un exemple est le Python Package Index, un registre de packages pour le langage de programmation Python qui permet à n’importe qui, du bénévole idéaliste à l’employé d’une entreprise en passant par un programmeur malveillant, de publier du code dessus. Le nombre de ces registres est stupéfiant, et maintenant chaque programmeur est pratiquement obligé de les utiliser.

L’efficacité de ce modèle logiciel rend une grande partie de la société dépendante des logiciels open source. Les défenseurs de l’open source sont prompts à défendre le système actuel en invoquant la loi de Linuss : avec suffisamment d’yeux, tous les bogues sont superficiels. Autrement dit, parce que le code source du logiciel est libre d’inspecter, les développeurs de logiciels travaillant et partageant du code en ligne trouveront des problèmes avant qu’ils n’affectent la société, et par conséquent, la société ne devrait pas trop s’inquiéter de sa dépendance à l’égard des logiciels open source car cette armée invisible protégera ce. Cela peut, si vous louchez, avoir été vrai en 1993. Mais beaucoup de choses ont changé depuis lors. En 2022, quand il y aura des centaines de millions de nouvelles lignes de code open source écrites, il y aura trop peu d’yeux et les bogues seront profonds. C’est pourquoi en août 2018, il a fallu deux mois complets pour découvrir qu’un code de vol de crypto-monnaie avait été glissé dans un logiciel téléchargé plus de 7 millions de fois.

Flux d’événements

L’histoire a commencé lorsque le développeur Dominic Tarr a transféré les droits de publication d’un package JavaScript open source appelé event-stream à une autre partie connue uniquement par le pseudonyme right9ctrl. Le transfert a eu lieu sur GitHub, une plate-forme d’hébergement de code populaire fréquentée par des dizaines de millions de développeurs de logiciels. L’utilisateur right9ctrl avait proposé de maintenir le flux d’événements, qui était, à ce moment-là, téléchargé près de deux millions de fois par semaine. La décision de Tarrs était sensée et banale. Il avait créé ce logiciel open source gratuitement sous une licence permissive, le logiciel était fourni tel quel mais ne l’utilisait plus lui-même. Il a également déjà maintenu plusieurs centaines d’autres logiciels open source sans compensation. Ainsi, lorsque right9ctrl, qui que ce soit, a demandé le contrôle, Tarr a accordé la demande.

Transférer le contrôle d’un logiciel open source à une autre partie se produit tout le temps sans conséquence. Mais cette fois, il y a eu une tournure malveillante. Après que Tarr ait transféré le contrôle, right9ctrl a ajouté un nouveau composant qui tentait de voler des bitcoins à l’ordinateur des victimes. Des millions et des millions d’ordinateurs ont téléchargé ce progiciel malveillant jusqu’à ce que le développeur Jayden Seric remarque une anomalie en octobre 2018.

Le flux d’événements était simplement le canari dans la mine de code. Ces dernières années, les chercheurs en sécurité informatique ont trouvé des attaquants utilisant une gamme de nouvelles techniques. Certains imitent le squattage de noms de domaine : ils incitent les développeurs de logiciels qui orthographient mal un nom de package à télécharger des logiciels malveillants (dajngo contre django). D’autres attaques tirent parti des erreurs de configuration des outils logiciels qui incitent les développeurs à télécharger des packages logiciels à partir du mauvais registre de packages. La fréquence et la gravité de ces attaques ont augmenté au cours de la dernière décennie. Et ces décomptes n’incluent même pas les cas sans doute plus nombreux de vulnérabilités de sécurité involontaires dans les logiciels open source. Plus récemment, la vulnérabilité involontaire du progiciel log4j largement utilisé a conduit à un sommet de la Maison Blanche sur la sécurité des logiciels open source. Après la découverte de cette vulnérabilité, un journaliste a intitulé un article, avec une légère exagération, The Internet Is on Fire.

Le plan en trois étapes

Heureusement, les producteurs et les consommateurs de logiciels, y compris le gouvernement américain, peuvent prendre plusieurs mesures qui permettraient à la société de bénéficier des avantages des logiciels open source tout en minimisant ces risques. La première étape, qui a déjà reçu le soutien du département américain du commerce et de l’industrie, consiste à rendre les logiciels transparents afin qu’ils puissent être évalués et compris. Cela a commencé par des efforts pour encourager l’utilisation d’une nomenclature logicielle. Cette facture est une liste ou un inventaire complet des composants d’un logiciel. Avec cette liste, le logiciel devient plus facile à rechercher des composants qui peuvent être compromis.

À long terme, ce projet de loi devrait aller au-delà d’une simple liste de composants pour inclure des informations sur qui a écrit le logiciel et comment il a été construit. Pour emprunter la logique de la vie quotidienne, imaginez un produit alimentaire avec des ingrédients clairement spécifiés mais inconnus et non analysés. Cette liste est un bon début, mais sans une analyse plus approfondie de ces ingrédients, la plupart des gens passeront. Les programmeurs individuels, les géants de la technologie et les organisations fédérales devraient tous adopter une approche similaire des composants logiciels. Une façon de le faire serait d’adopter les niveaux de la chaîne d’approvisionnement pour les artefacts logiciels, un ensemble de lignes directrices pour les chaînes d’approvisionnement en logiciels des organisations inviolables.

L’étape suivante implique que les sociétés de sécurité logicielle et les chercheurs créent des outils qui, premièrement, signent et vérifient les logiciels et, deuxièmement, analysent la chaîne d’approvisionnement logicielle et permettent aux équipes logicielles de faire des choix éclairés sur les composants. Le projet Sigstore, une collaboration entre la Fondation Linux, Google et un certain nombre d’autres organisations, est l’un de ces efforts axés sur l’utilisation de signatures numériques pour rendre la chaîne de contrôle des logiciels open source transparente et auditable. Ces approches techniques constituent l’équivalent numérique d’un scellé inviolable. L’équipe logicielle Platform One du Department of Defenses a déjà adopté des éléments de Sigstore. De plus, un observatoire de la chaîne d’approvisionnement en logiciels qui collecte, organise et analyse la chaîne d’approvisionnement en logiciels dans le monde en vue de contrer les attaques pourrait également être utile. Un observatoire, potentiellement géré par un consortium universitaire, pourrait simultanément aider à mesurer la prévalence et la gravité des compromissions de logiciels open source, fournir les données sous-jacentes qui permettent la détection et comparer quantitativement l’efficacité de différentes solutions. Le Software Heritage Dataset fournit les germes d’un tel observatoire. Les gouvernements devraient aider à soutenir cette initiative et d’autres initiatives similaires axées sur la sécurité. Les entreprises technologiques peuvent également adopter divers projets d’étiquetage nutritionnel, qui fournissent un aperçu en un coup d’œil de la santé d’une chaîne d’approvisionnement de projets logiciels.

Ces efforts relativement techniques bénéficieraient toutefois de réformes gouvernementales plus larges. Cela devrait commencer par fixer la structure d’incitation à l’identification et à la divulgation des vulnérabilités open source. Par exemple, les clauses DeWitt couramment incluses dans les licences de logiciels nécessitent l’approbation du fournisseur avant la publication de certaines évaluations de la sécurité des logiciels. Cela réduit les connaissances de la société sur les pratiques de sécurité qui fonctionnent et celles qui ne fonctionnent pas. Les législateurs devraient trouver un moyen d’interdire cette pratique anticoncurrentielle. Le Département de la sécurité intérieure devrait également envisager de lancer un fonds à but non lucratif pour les primes de bogues des logiciels open source, qui récompense les chercheurs pour avoir trouvé et corrigé de tels bogues. Enfin, comme l’a proposé la récente Cyberspace Solarium Commission, un bureau de cyberstatistiques pourrait suivre et évaluer les données de compromission de la chaîne d’approvisionnement des logiciels. Cela garantirait que les parties intéressées ne soient pas bloquées dans la construction d’ensembles de données dupliqués et idiosyncratiques.

Sans ces réformes, les logiciels modernes ressembleront au monstre de Frankenstein, une compilation disgracieuse de pièces suspectes qui se retournera finalement contre son créateur. Avec la réforme, cependant, l’économie américaine et l’infrastructure de sécurité nationale peuvent continuer à bénéficier du dynamisme et de l’efficacité créés par la collaboration open source.

John Speed ​​Meyers est un scientifique des données de sécurité chez Garde-chaîne. Zack Newman est ingénieur logiciel senior chez Chainguard. Tom Pike est doyen de la Oettinger School of Science and Technology de la National Intelligence University. Jacqueline Kazil est ingénieure de recherche appliquée chez Rebellion Defence. Toute personne intéressée par la sécurité nationale et la sécurité des logiciels open source peut également en savoir plus sur la page GitHub d’un naissant surveillance de quartier de logiciels open-source. Les opinions exprimées dans cette publication sont celles des auteurs et n’impliquent pas l’approbation du Bureau du directeur du renseignement national ou de toute autre institution, organisation ou agence gouvernementale américaine.

Image : photo d’archives