2 pièce(s) jointe(s)
Google, Microsoft et d'autres rejoignent la Linux Foundation pour lancer l'Open Source Security Foundation
Google, Microsoft et d'autres rejoignent la Linux Foundation pour lancer l'Open Source Security Foundation,
afin d'améliorer la sécurité des logiciels open source
Les logiciels open source sont devenus monnaie courante dans toutes sortes d'environnements. En raison de son processus de développement, le logiciel open source qui atteint les utilisateurs finaux a une chaîne de contributeurs et de dépendances. Il est important que les responsables de la sécurité de leur utilisateur ou de leur organisation soient capables de comprendre et de vérifier la sécurité de cette chaîne de dépendances. Aussi, la Linux Foundation a lancé la création de l'Open Source Security Foundation (OpenSSF). Il s'agit d'une collaboration intersectorielle qui rassemble des leaders pour améliorer la sécurité des logiciels open source en créant une communauté plus large avec des initiatives ciblées et les meilleures pratiques.
L'OpenSSF rassemble les initiatives de sécurité open source les plus importantes de l'industrie et les individus et entreprises qui les soutiennent. La Core Infrastructure Initiative (CII) de la Linux Foundation, fondée en réponse au bogue Heartbleed de 2014, et l'Open Source Security Coalition, fondée par le GitHub Security Lab, ne sont que quelques-uns des projets qui seront réunis dans le cadre du nouvel OpenSSF. La gouvernance de la Fondation, la communauté technique et ses décisions seront transparentes, et toutes les spécifications et tous les projets développés seront indépendants du fournisseur. L'OpenSSF s'engage à collaborer et à travailler à la fois en amont et avec les communautés existantes pour faire progresser la sécurité open source pour tous.
L'OpenSSF a été créé sur le principe que les chercheurs en sécurité ont besoin d'un mécanisme pour leur permettre de traiter en collaboration les méthodes nécessaires pour sécuriser la chaîne d'approvisionnement de sécurité open source. Il reconnaît que les chercheurs en sécurité du monde entier au sein des organisations ont des intérêts et des préoccupations communs. OpenSSF facilite le dialogue soutenu et le travail de projet entre les entités privées, les fondations et les universités.
Google, Microsoft et d'autres entreprises rejoignent l'OpenSSF
La liste des membres initiaux comprend Google, Microsoft, GitHub, IBM, Red Hat, etc. Le CTO d’Azure, Mark Russinovich, a expliqué clairement pourquoi la sécurité open source doit être un effort de la communauté :
« Les logiciels open source sont au cœur de la stratégie technologique de presque toutes les entreprises et leur sécurisation est un élément essentiel de la sécurisation de la chaîne d'approvisionnement pour tous, y compris la nôtre. Avec l'omniprésence des logiciels open source, les attaquants exploitent actuellement les vulnérabilités d'un large éventail de services et d'infrastructures critiques, notamment les services publics, l'équipement médical, les transports, les systèmes gouvernementaux, les logiciels traditionnels, les services cloud, le matériel et l'IdO.
« Les logiciels open source sont intrinsèquement axés sur la communauté et, à ce titre, aucune autorité centrale n'est responsable de la qualité et de la maintenance. Comme le code source peut être copié et cloné, la gestion des versions et les dépendances sont particulièrement complexes. Les logiciels open source sont également vulnérables aux attaques contre la nature même de la communauté, telles que les attaquants devenant les mainteneurs de projets et introduisant des logiciels malveillants. Compte tenu de la complexité et de la nature communautaire des logiciels open source, la création d'une meilleure sécurité doit également être un processus mené par la communauté ».
Les initiatives techniques initiales de l'OpenSSF porteront sur:
- Les divulgations de vulnérabilités : sur la page, il est expliqué que la vision est un écosystème de logiciels open source où le temps nécessaire pour corriger une vulnérabilité et déployer cette correction dans l'écosystème est mesuré en minutes, et non en mois. Il est question de créer un format et une API unifiés pour les rapports de vulnérabilité / la divulgation coordonnée et favoriser une large adoption
- Les outils de sécurité : La mission déclarée est de fournir les meilleurs outils de sécurité pour les développeurs open source et de les rendre universellement accessibles. Le collectif voudrait créer un espace où les membres peuvent collaborer ensemble pour améliorer les outils de sécurité existants et en développer de nouveaux pour répondre aux besoins de la communauté open source plus large.
- Identifier les menaces de sécurité pour les projets Open Source : ici il est question de permettre aux parties prenantes d'avoir une confiance éclairée dans la sécurité des projets Open Source. Le collectif voudrait identifier un ensemble de mesures clés et créer des outils (API, interface utilisateur Web) pour communiquer ces mesures aux parties prenantes, permettant à ces parties prenantes de mieux comprendre l'état de sécurité des composants open source individuels.
- Les bonnes pratiques de sécurité : l'objectif est de fournir aux développeurs open source des recommandations de bonnes pratiques.
- La sécurisation des projets critiques : l'objectif est d'effectuer des audits, des assurances, des équipes d'intervention, des améliorations et un travail tactique pratique.
De plus, l'OpenSSF visera à aider les projets critiques à obtenir le soutien dont ils ont besoin pour garantir leur sécurité : « Qu'il s'agisse de l'aide dédiée d'experts spécialisés ou simplement d'accorder de l'argent ou des crédits cloud, nous reconnaissons qu'il n'y a pas deux projets identiques et que le soutien peut prendre de nombreuses formes. Nous avons l'intention de travailler avec les responsables en amont pour comprendre l'aide et le support dont ils ont besoin, puis de développer des processus évolutifs pour rendre cette aide disponible ».
Entre autres, Google et Microsoft ont annoncé leur participation à l'OpenSSF avec un accent particulier sur un certain nombre de domaines, y compris les schémas partagés et les métadonnées pour mieux appliquer les meilleures pratiques de sécurité; la gestion des dépendances et évaluation des risques pour cartographier les vulnérabilités à des versions de code spécifiques ; des outils de vérification de build, comme Tekton Chains; et l’utilisation de Developper Identity pour associer les modifications à leurs auteurs.
Pour ce dernier point, il est expliqué que sans trop d'efforts, un attaquant pourrait insérer du code malveillant dans une bibliothèque open source populaire et mener une attaque. Un attaquant pourrait y parvenir en recherchant un paquet hautement importé qui se trouve au bas de la pile mais qui peut toujours affecter la communication, peut-être même avoir un accès root, et qui est peu [ledit paquet], voire pas surveillé.
Ce type d'attaque a déjà été mené. Par exemple, des hackers ont introduit une porte dérobée dans une bibliothèque open source largement utilisée dans le but de voler subrepticement des fonds stockés dans des portefeuilles bitcoins. Le code malveillant a été inséré en deux étapes dans event-stream, une bibliothèque qui comptabilisait en 2018 plus de deux millions de téléchargements et était utilisée aussi bien par des entreprises figurant dans le Fortune 500 que par des startups.
Selon la discussion sur GitHub qui a exposé la porte dérobée, le développeur de event-stream n'avait plus le temps de fournir des mises à jour. Donc, plusieurs mois avant cette découverte, il a accepté l'aide d'un développeur inconnu. Le nouveau développeur a pris soin de cacher la porte dérobée. En plus de l’implémenter progressivement, il ne ciblait également que l'application de portefeuille Copay. Le code malveillant était également difficile à détecter, car le module flatmap-stream était chiffré.
Les objectifs ici sont donc de :
- Donner aux mainteneurs open source un moyen de travailler sous le nom de leur choix, en représentant leurs vrais employeurs de manière sécurisée.
- Donner aux projets open source des outils et une infrastructure pour vérifier l'identité de leurs mainteneurs.
- Donner aux consommateurs de bibliothèques open source plus de données pour déterminer les risques de dépendre de ladite bibliothèque.
- Donner aux consommateurs et aux responsables de la maintenance un registre public de ceux qui ont mis en œuvre les modifications d'un projet de logiciel Open Source.
- Respecter la vie privée de toutes les personnes impliquées.
- Donner aux mainteneurs OSS une meilleure capacité à garantir le respect des politiques de gouvernance de projet (comme l'approbation indépendante).
- Offrir aux consommateurs OSS des outils pour détecter les pics d'activité des committers inconnus.
Sources : Microsoft, Google, Tekton Chains, Developer Identity, GitHub, Open Source Security Foundation
