Sécurité de l’open source : les pistes des fondations pour la renforcer

Open source : des vannes largement ouvertes

Dans son étude « State of Open Source Vulnerabilities 2021 », WhiteSource explique que le nombre de vulnérabilités détectées dans les projets open source a crû de 58 % entre 2019 et 2020 (6 111 failles répertoriées en 2019, contre 9 658 en 2020). L’éditeur semble toutefois préciser que 2020 est une année exceptionnelle à cause de la crise sanitaire et du confinement. Les analystes se réfèrent entre autres aux travaux de GitHub qui a noté une forte augmentation de nouveaux dépôts Git sur sa plateforme dès mars 2020.

WhiteSource et GitHub ne sont pas les seuls à observer cette explosion. Dans son « État de la chaîne logistique logicielle en 2021 », SonaType relève que les quatre écosystèmes open source les plus importants ont publié 6 millions de nouvelles versions en douze mois, proposant ainsi 37 millions de moutures de composants OSS, « soit une hausse de l’offre mondiale open source de 20 % en un an ». Aussi, le volume de téléchargement d’artefacts libres aurait augmenté de 73 %.

En clair, la popularité de l’open source ne cesse de croître. À titre d’exemple, dans son State of Software Security 12, Veracode indique qu’en moyenne 97 % des applications Java sont bâties à partir de librairies open source. Pour rappel, Log4j est un outil de logging conçu pour les environnements Java.

Dans un même temps, l’augmentation du nombre de CNA (CVE Numbering Authorities) a favorisé le dévoilement de failles dans les logiciels libres, selon WhiteSource. Le 16 novembre 2021, le CVE Program a annoncé avoir dépassé la barre symbolique des 201 CNA en provenance de 32 pays. Si 178 organisations se sont enregistrées entre 2016 et 2021, pas moins de 23 d’entre elles, dont Thales, ont rejoint le programme au quatrième trimestre 2021.

GitHub, lui-même a lancé son GitHub Security Lab en novembre 2019, accélérant ainsi la détection de vulnérabilités dans les quelque 200 millions de repos hébergés par la filiale indépendante de Microsoft. Au 21 février 2022, le laboratoire indique avoir publié 196 CVEs depuis mars 2020, 319 au total. Et si de manière générale les chercheurs automatisent leurs scans, une seule CVE peut rassembler plusieurs brèches, tout comme plusieurs CVE peuvent en réalité découler d’un même défaut de sécurité.

« La sécurité de la supply chain n’est pas toujours un sujet lié à l’open source ».

Notons que les entreprises se préoccupent de plus en plus des failles : Veracode observe que le nombre d’applications scannées a triplé entre 2011 et 2021.

En face, les cyberattaquants n’y vont pas de main morte. « Ce que l’on constate, c’est que de plus en plus d’attaques ciblent la chaîne d’approvisionnement logicielle », remarque Nicolas Massé, Solutions Architect chez Red Hat auprès du MagIT.

Selon le bilan de SonaType, les attaques de chaîne logistique logicielle ont augmenté de 650 % entre 2020 et 2021. Les méthodes sont connues – confusion de dépendances, typosquattage, injection de code malveillant, exploitations de failles zero-day, etc. – mais peuvent se révéler particulièrement dévastatrices.

« La sécurité de la supply chain n’est pas toujours un sujet lié à l’open source », tient à préciser Gaël Blondelle, VP écosystème de développement chez la Fondation Eclipse.

Les compromissions de SolarWinds, de différents dépôts GitHub, GitLab, Atlassian et de Kaseya, pour ne citer que ceux-là, le prouvent.

Outre l’accélération des programmes de type bug bounty, la sécurisation de la supply chain devient essentielle. Les acteurs du marché et les organisations open source l’ont bien compris.

Rendre les dépôts de code « fiables »

Et cela passe d’abord par une meilleure gestion des identités des contributeurs.

« Dans toutes les conversations au sujet de la cybersécurité, la question la plus importante est : “en qui avez-vous confiance ?” », indique Massimiliano Gori, Product Manager for Cybersecurity Compliance chez Canonical.

« Dans toutes les conversations au sujet de la cybersécurité, la question la plus importante est : “en qui avez-vous confiance ? ».

L’une des premières démarches consiste en la mise en place de systèmes d’authentification multiple (Multi-factor authentication ou MFA). Il s’agit d’éviter l’usurpation d’identité des développeurs ayant des droits d’accès à certains dépôts de code, publics ou non. GitHub tend à pousser un système d’authentification à double facteur (2FA) par défaut.

Au regard des nombreuses failles qui touchent certains projets, l’éditeur a décidé en décembre 2021 de le rendre obligatoire pour les mainteneurs des 100 paquets NPM les plus populaires (plus d’un million de téléchargements hebdomadaires ou 500 dépendants). Le déploiement général de la mesure aura lieu dès le 1er mars 2022. La semaine du 25 janvier, GitHub a également annoncé la disponibilité d’un module 2FA pour ses applications iOS et Android. GitLab propose aussi un moyen de forcer l’extension de l’authentification à double facteur, mais laisse le choix aux organisations et aux contributeurs principaux de l’imposer ou non.

« Je pense qu’il faut des repositories autour desquels les processus sont clairs et documentés : bâtir une véritable gouvernance ».

Contrôler les conditions d’accès au code ne suffit pas, « il faut rendre les dépôts open source fiables », selon Gaël Blondelle. « Je pense qu’il faut des repositories autour desquels les processus sont clairs et documentés : bâtir une véritable gouvernance », affirme-t-il. « Malgré tout, c’est la force des fondations open source, en tout cas celle de la Fondation Eclipse qui est née pour gérer les compatibilités entre différentes propriétés intellectuelles ».

Si plusieurs initiatives et solutions existent au sein de la fondation Eclipse, tous les éléments ne sont pas encore définis. « Nous maîtrisons le développement et la mise en place de processus, il s’agit maintenant de l’appliquer plus systématiquement pour renforcer la sécurité de la supply chain logicielle », avance le VP écosystème de développement.

« L’on pourrait forcer l’authentification multifacteur, l’une des bonnes pratiques du moment », complète Mikael Barbero, responsable Release Engineering et technologie pour la Fondation Eclipse. « Il y a aussi l’identification des contributeurs à un dépôt. Aujourd’hui, un contributeur chez Eclipse doit signer un accord avec la fondation, non pas pour donner ses droits de propriété, mais pour que l’on sache que cette personne existe, afin de la contacter en cas de problème », explique-t-il.

« Que ce soit sur les dépôts Maven Central ou sur npm.js, ce suivi n’est pas mis en place par défaut et il n’y a pas non plus de vérification d’attribution des namespaces », remarque Mikael Barbero. « Avoir la possibilité d’attester l’identité d’un contributeur et donc s’assurer qu’il peut commit dans un namespace spécifique, c’est quelque chose de vraiment important ».

« Aujourd’hui, quand quelqu’un pousse du code sur un des 400 projets de la Fondation Eclipse, nous vérifions automatiquement qu’il possède un compte Eclipse.org et que cette personne a bien signé électroniquement l’accord », avance Gaël Blondelle.

La Fondation Eclipse propose déjà de faire signer chaque commit afin d’identifier l’auteur derrière un push de code dans un dépôt. « Un commit qui est effectué par une personne non autorisée est détecté assez rapidement, parce que la communauté est vigilante. Par ailleurs, nous interdisons la réécriture d’historique, donc personne ne peut lancer des “force push”. En revanche, la revue systématique des commits est décidée par les mainteneurs », indique Mikael Barbero.

En ce qui concerne la sécurité des projets eux-mêmes, la fondation Eclipse pousse l’initiative « Reproductible Builds ». « Une build reproductible vise à garantir que la build que les utilisateurs vont exécuter correspond bien au code source qui a été mis à disposition par un projet au sein de la fondation », explique Gaël Blondelle.

Reproductible Builds est une suite de méthodes et d’outils pour s’assurer qu’une build peut être compilée à l’identique. Une dérive du code pourrait renseigner sa compromission au moment de la compilation.

Il y a d’autres mécanismes pour vérifier l’identité de l’auteur et l’intégrité du code. Certains packages JAR ou Debian de la Fondation Eclipse sont signés avec des clés de chiffrement PGP. GitHub et GitLab proposent une solution équivalente en option. Là non plus, rien de systématique.

« Les contributeurs au kernel Linux utilisent depuis longtemps les signatures PGP pour authentifier le code », note Massimiliano Gori. « Cela ressemble un peu au modèle du protocole SSH, c’est une assez bonne solution, mais on ne peut pas s’arrêter là : tous les contributeurs open source et les entreprises doivent s’impliquer davantage dans cette direction ».

« Quand cette chaîne de confiance débute-t-elle ? Est-ce qu’elle doit commencer au moment de pousser du code dans un dépôt, par exemple celui du kernel Linux ? Faut-il qu’elle se lance quand Canonical utilise le kernel pour l’intégrer dans Ubuntu ? Ou alors, faut-il la déployer au moment de la distribution des images par les fournisseurs de cloud ? », s’interroge-t-il.

Les nouvelles initiatives des fondations open source

À ce titre, Red Hat et Google collaborent avec l’Université Purdue pour développer une solution capable de garantir la provenance et l’intégrité des artefacts open source.

« Red Hat a mis en place plusieurs initiatives pour aider à mieux sécuriser la chaîne d’approvisionnement logicielle. La dernière en date se nomme sigstore », affirme Nicolas Massé. »C’est un registre public destiné à être alimenté avec toutes les versions logicielles des communautés open source », précise-t-il. « L’idée est de garantir, par le biais d’une signature cryptographique, qu’un artefact livré n’a pas fait l’objet de modifications non autorisées tout au long de la chaîne, et ce jusqu’à sa destination. L’aspect novateur de sigstore est de démocratiser la signature de code auprès des développeurs et d’assurer une traçabilité publique ».

Sigstore est porté par la Fondation Linux (LF). Le projet combine les solutions open source Cosign, Rekor, Open ID Connect et Fulcio. Cosign permet de réaliser une signature chiffrée de conteneurs, de fichiers. tar ou de binaires compilés. Les métadonnées de cette signature sont stockées dans Rekor, un registre immuable chargé de la « transparence des logs ». Open ID Connect sert à administrer l’identification des utilisateurs et Fulcio joue le rôle d’autorité de certification source (Root CA).

Au début du mois de février 2022, le projet était proche de la disponibilité générale et aurait déjà permis de « certifier » 1,2 million d’artefacts. À l’avenir, les responsables du projet souhaitent que sigstore serve à signer des fichiers de type JAR ou même des manifestes, tels des SBOM.

Ce n’est qu’un des projets de la Fondation Linux visant à sécuriser la supply chain logicielle. La LF soutient TUF, un framework conçu pour sécuriser les systèmes de mise à jour (en sus de sa variante Uptane), et in-toto, une méthode et des mécanismes pour renforcer la chaîne logistique logicielle via un dispositif de certificats chiffrés.

En 2020, la fondation a également créé OpenSSF (Open Source Security Foundation) pour embarquer les entreprises et les organisations dans une initiative de sécurisation des projets open source. Voici quelques-uns des projets de l’OpenSSF :

• SLSA, une méthodologie regroupant des modèles pour évaluer la sécurité de la supply chain logicielle,
• AllStars, un système pour imposer des règles de conformité dans les dépôts GitHub,
• Security ScoreCard, un mécanisme automatisé de vérification et de notation de la sécurité des projets lié à GitHub Actions,
• Package Analysis, des composants pour analyser des paquets libres,
• et des badges pour indiquer que les porteurs de projets open source suivent les meilleures pratiques de sécurité.

Un problème culturel

Dans un même temps, Randall Degges, responsable des relations avec la communauté de développeurs chez Snyk notait dans un billet de blog que cet élan sécuritaire autour du logiciel est assez récent et que la plupart des programmeurs sont démunis face à cette explosion des cyberattaques.

« La plupart des développeurs (qu’ils travaillent sur l’open source ou non) n’ont pas les connaissances, la formation et l’outillage nécessaires pour effectivement “prendre la sécurité au sérieux ».

« La plupart des développeurs (qu’ils travaillent sur l’open source ou non) n’ont pas les connaissances, la formation et l’outillage nécessaires pour effectivement “prendre la sécurité au sérieux” », tranche-t-il. « Notre rapport 2019 sur l’état de la sécurité des logiciels libres a révélé que seuls trois mainteneurs de logiciels open source sur dix se considéraient comme ayant des “connaissances élevées en matière de sécurité ».

Ce dernier point est pourtant l’une des conditions pour l’obtention d’un « Best Practice Badge » auprès de l’OpenSSF.

« Ce n’est pas la faute des développeurs open source, c’est un échec de l’ensemble de l’écosystème : la sécurité a été une excroissance de l’industrie aussi longtemps que je me souvienne, alors que si nous voulons construire des logiciels plus fiables, la sécurité doit devenir un élément central du processus de développement », martèle-t-il.

« Je pense que c’est un problème culturel », complète Bryan Vermeer, Developer Advocate chez Snyk. « Dans de nombreux cas, la sécurité reste une expertise cloisonnée qui n’est pas intégrée dans les équipes de développement/DevOps. C’est là qu’intervient l’approche DevSecOps, où nous essayons de bâtir des logiciels en tenant compte de la sécurité dès le départ », affirme-t-il auprès du MagIT.

D’ailleurs, l’instauration de certaines mesures demeure complexe. Les organisations open source – Eclipse, Apache, la LF et les autres – n’imposent pas, elles encouragent les bonnes pratiques.

« Ce n’est pas la faute des développeurs open source, c’est un échec de l’ensemble de l’écosystème ».

« La généralisation des builds reproductibles demande avant tout de l’évangélisation auprès des mainteneurs des projets », observe Mikael Barbero. « C’est très difficile à mettre en place. L’initiative est née en 2011. Depuis, très peu de projets adhèrent ou arrivent à aller jusqu’au bout. Il faut éduquer les mainteneurs, fournir les bons outils et du support », note-t-il.

De son côté, OpenSSF a annoncé le projet Alpha-Omega au début du mois de février 2022. La phase Alpha vise à inspecter les postures de sécurité des projets libres les plus populaires au sein de la LF. Les membres des équipes Alpha devront examiner les manques en matière de cybersécurité et proposer les méthodes et les outils pour y remédier. Les équipes Omega, elles, chercheront les vulnérabilités critiques dans « au moins » 10 000 projets open source, à l’aide de systèmes d’analyse automatisés. Microsoft Azure est l’un des partenaires de ce programme.

Cependant, cette filiale de la LF reste jeune, comme en témoigne la réaction de Massimiliano Gori. « OpenSSF propose plusieurs initiatives qui s’attaquent aux problèmes de sécurité de la chaîne logistique logicielle, mais nous devons encore voir où les discussions mèneront ».

L’approche demeure tout de même intéressante. « Ce sont les débuts, mais les promoteurs d’OpenSSF appuient sur les bons boutons », affirme Massimiliano Gori. 

Pour sa part, la Fondation Eclipse compte donner plus systématiquement accès aux outils de scans de vulnérabilités dont elles disposent et favoriser les intégrations avec les logiciels du marché. Aussi, « nous ne faisons pas de recherche active de failles, c’est quelque chose que nous aimerions explorer plus sérieusement », annonce Mikael Barbero.

Cependant, toutes ces démarches sont conditionnées par la participation des entreprises et des grandes organisations contribuant aux projets open source, qui doivent elles-mêmes s’assurer que leur chaîne d’approvisionnement logicielle est sûre. Tout cela réclame des investissements conséquents.