IBM, Red Hat et Chainguard prônent un modèle de sécurité open source à huis clos

Les normes toutes relatives de divulgation des CVE (ou la tentation d’un retour au huis clos)

Les vulnérabilités apparaissent plus rapidement que jamais et les entreprises tardent à les corriger, ce qui ne fait qu’aggraver un retard déjà important.

« Log4j en est un excellent exemple », évoque Dan Lorenc, PDG de Chainguard. « La personne qui a signalé ce bug au départ ne savait même pas qu’il s’agissait d’un problème de sécurité. Elle l’a simplement découvert et l’a corrigé publiquement. Puis, tout à coup, tout le monde s’est rendu compte qu’il s’agissait d’un problème de sécurité et s’est empressé d’agir aussi vite que possible dès qu’il a pris la mesure de la gravité de la situation. Il n’y a eu aucune discussion à huis clos sur la manière de gérer ce problème ».

Certaines entreprises ne peuvent pas réagir aussi rapidement, en particulier les grandes entreprises. Gunnar Hellekson a estimé qu’il fallait en moyenne plus de 40 jours aux groupes du Fortune 500 pour corriger une vulnérabilité critique.

« Le nombre de vulnérabilités ne cesse de s’accumuler. Les entreprises peinent à résoudre les plus anciennes et les nouvelles s’empilent tellement vite qu’elles sont submergées. Tous les acteurs du secteur sont confrontés à cette dette de vulnérabilités qu’ils n’ont jamais corrigées », constate-t-il.

La capacité de l’IA à détecter des bugs là où les humains ne le peuvent pas est à double tranchant. D’un côté, elle permettrait de les signaler, puis d’aider à les corriger plus rapidement, mais elle rend d’abord ces retards encore plus risqués. Ce problème concerne également les éditeurs.

« Certains de vos fournisseurs IT, actifs de longue date, disposent de bases de code plus volumineuses, ont accumulé beaucoup plus de dettes techniques et présentent donc une surface d’attaque plus étendue », signale Todd Thiemman, analyste principal chez Omdia, une division d’Informa Techtarget [également propriétaire du MagIT]. « Et ils découvrent de nombreuses vulnérabilités qu’ils comprennent devoir corriger. Ils vont devoir y consacrer des ressources pour y remédier, car ils savent que ces modèles d’IA vont se généraliser ».

Les problèmes de l’open source, selon IBM/Red Hat et Chainguard

Lorsqu’une entreprise ou un individu détecte des bugs dans un logiciel géré par un éditeur, la marche à suivre paraît simple : il suffit de demander à ce dernier de résoudre le problème.

Certains signalements sont toutefois rejetés ou écartés. Les éditeurs ne veulent pas forcément payer les bounty hunters. Ils considèrent parfois à juste titre que l’exploitation des découvertes est très circonstanciée. La situation serait moins claire avec l’open source, avance Red Hat.

Selon Worldmetrics, plus de 90 % des entreprises du classement Fortune 500 utilisent des logiciels open source. Souvent, les communautés à ces projets ne sont pas en mesure de réagir à une vulnérabilité de la même manière qu’un éditeur. La qualité de la maintenance varie considérablement. Parfois, des projets open source critiques ne sont gérés que par une poignée de contributeurs bénévoles, voire par personne.

« Il n’y a personne à qui s’adresser », insiste Gunnar Hellekson. « Il n’y a pas de SLA. Il n’y a pas de contrat d’assistance. Ce ne sont que des éléments que l’on récupère sur Internet. »

« Actuellement, les entreprises doivent soit corriger elles-mêmes les vulnérabilités, soit les exposer publiquement en les signalant », résume le DG de RHEL.

Le modèle de chambre de compensation vise à offrir une troisième option.

Lorsque les entreprises découvrent des vulnérabilités dans leur propre code, elles peuvent les signaler à la plateforme centrale dédiée à Lightwell. Les ingénieurs corrigent ensuite la vulnérabilité et déploient le patch tout au long de la chaîne d’approvisionnement logicielle. Ce n’est pas gratuit. Project Lightwell est un service par abonnement permettant aux entreprises de réintégrer les correctifs dans leurs environnements. Chaque correctif est également renvoyé directement au projet OSS d’origine pour examen et validation.

« Personne n’a vraiment fait quelque chose de similaire auparavant », avance Gunnar Hellekson. « De nombreuses entreprises se chargent du rétroportage et des corrections. L’une des particularités du [projet Lightwell] – et c’est là tout l’intérêt de ces vingt mille [ingénieurs] –, c’est que non seulement nous corrigeons, mais nous nous engageons également à veiller à ce que ces contributions soient intégrées dans les projets en amont ».

« Ce n’est pas un travail de robot », ajoute-t-il. « Les communautés en amont reçoivent déjà les analyses, les pull requests et les correctifs de nombreux bots. Elles croulent sous ces demandes. Nous pensons qu’il y a une composante humaine essentielle dans ce processus, afin que de vraies personnes, entretenant des relations réelles avec les communautés en amont, puissent prendre en charge et parrainer ces correctifs pour les contribuer en retour ».

Mettre à contribution l’IA contre l’IA, ce ne sera pas gratuit

 Il n’en reste pas moins que, pour rester dans la course, le recours à l’IA est indispensable, jugent les parties prenantes.

« Le volume des données impose d’automatiser autant que possible [les correctifs] », souligne Gunnar Hellekson. « L’IA est nécessaire pour trier, corriger et tester, tout en conservant un jugement humain dans le processus ».

Le projet Lightwell fait actuellement appel à une sélection de partenaires de conception, parmi lesquels Bank of America, BNY, Citi, Goldman Sachs, JPMorgan Chase, Mastercard, Morgan Stanley, la Banque Royale du Canada, State Street, Visa et Wells Fargo.

« Ce que nous faisons s’adresse à ceux qui souhaitent acheter un certain niveau de service. En même temps, ils comprennent l’intérêt de diffuser le correctif en amont », continue le directeur général de RHEL. Or, l’éditeur ne peut pas garantir qu’il sera accepté.

Si la communauté open source cible n’est pas intéressé, les responsables de Lightwell se chargeront de sa mise en œuvre du patch pour le compte des abonnés. « Nous proposerons la correction. Nous ne pouvons pas contrôler si les porteurs d’un projet OSS l’adoptent, mais nous la rendrons au moins disponible », confirme Gunnar Hellekson.

L’IA permettrait déjà de prendre en charge la maintenance de projet à l’abandon, selon Dan Lorenc de Chainguard. C’est tout l’objet du programme EmeritOSS. Il vise à automatiser l’application des correctifs CVE en collaboration avec une petite équipe.

« Être capable d’assurer la maintenance, de mettre à jour et d’agir en tant que mainteneurs de secours… n’aurait pas été possible sans une armée de personnes par le passé », avance-t-il. « L’IA pose de nombreux problèmes d’échelle au secteur, mais je pense qu’elle va également rendre beaucoup de choses possibles ».

Il y a urgence à agir, considèrent les parties prenantes de Lightwell et Athena

Malgré l’ampleur des investissements consacrés à ces offres commerciales, les acteurs en présence devront collaborer avec les écosystèmes open source. M. Lorenc et M. Hellekson citent tous deux Alpha-Omega et l’OpenSSF comme des organisations avec lesquelles il convient de collaborer d’une manière ou d’une autre pour relever les défis liés à la sécurité de l’open source. L’OpenSSF est également en train de mettre en place une équipe d’intervention en cas d’incident lié aux logiciels open source.

« Personne ne sera capable de trouver à lui seul tous les bugs dans tous les logiciels », martèle Dan Lorenc. Malgré l’incertitude, les deux organisations sont conscientes de l’urgence de développer un écosystème capable de gérer l’afflux de vulnérabilités.

« Le monde a besoin d’un espace où chacun puisse signaler ses découvertes lorsqu’il est impossible de contacter le responsable de maintenance », avance-t-il.

Le risque d’une sécurité open source à deux vitesses

Quelques fausses notes se glissent dans cette belle partition. Jeffrey Michael, responsable produit chez Perforce, ne remet pas en cause l’objectif final, mais soulève un problème majeur : le principe de l’open source n’est pas de réserver les patchs à quelques « happy fews ».

« Une initiative d’envergure et centralisée émanant de l’un des plus grands éditeurs de logiciels au monde ne manquera pas de susciter le scepticisme chez les utilisateurs de longue date de l’open source », écrit-il dans un billet de blog à propos de l’investissement de Red Hat.

« L’open source s’est historiquement appuyé sur une gestion décentralisée, des processus publics et un large accès aux correctifs dès leur développement », poursuit-il. « On comprend donc aisément qu’un modèle introduisant une couche intermédiaire formelle, des abonnements payants et des flux de correctifs coordonnés soulève des questions quant à savoir qui détient le contrôle, qui y a accès en premier et quelle influence une entreprise devrait avoir sur la manière dont l’open source est maintenu ».

Red Hat, IBM et Chainguard n’ont pas précisé en détail le périmètre sur lequel porteront Lightwell et Athena, ni les projets qui seront surveillés en priorité. Chainguard mentionne vaguement « plus de 500 projets ». L’on ne trouve pas non plus d’engagement formel et public concernant les délais de parution entre les correctifs « payants » et leur déclinaison open source.

En clair, cela pourrait généraliser un monde à deux vitesses où ceux qui paient les premiers seraient mieux protégés. Un renversement de modèle qui rappelle la fin de CentOS au profit de CentOS Stream, une variante de Linux non supportée à situer entre Fedora et RHEL.

En amont, « la divulgation coordonnée existe déjà sous de nombreuses formes », souligne Jeffrey Michael.

Contrairement à ce qu’avancent les porte-parole de Chainguard et Red Hat, un responsable de la Fondation Eclipse expliquait en 2022 que la divulgation de vulnérabilités ne fait pas immédiatement l’objet d’alertes sur des listes de diffusion publiques. Le signalement est partagé en privé, évalué puis fait l’objet d’un correctif. C’est également la pratique recommandée au sein de la Fondation Apache. Plusieurs parties prenantes peuvent interagir lors de ce processus. Y compris des éditeurs.

Par exemple, la faille affectant Log4J2 (Log4Shell) avait été signalée discrètement par un chercheur d’Alibaba à la fin du mois de novembre 2021 à la fondation Apache et aux quelques responsables du projet. Le 9 décembre, le chercheur indiquait à l’ASF que la faille était commentée sur WeChat, en lien avec le jeu vidéo Minecraft. La vulnérabilité a été présentée publiquement le 10 décembre 2021 avec son correctif. Dans un même temps, certains chercheurs et développeurs ont multiplié les preuves de concepts d’exploitation. Les attaquants n’ont pas tardé à s’y mettre. Un nouveau patch a été diffusé le 13 décembre pour pallier les limites mises en évidences par ces PoC. Cela a tout autant contribué à l’information sur la faille qu’à la panique qui s’en est suivie. Certains éditeurs ont tardé à signaler leur exposition à Log4shell à leurs clients.

Il y a quatre ans, les experts considéraient que les communautés open source réagissent rapidement, contrairement aux entreprises et aux éditeurs. Les contributeurs estiment que la majorité des organisations ont dû mal à comprendre leurs responsabilités en tant qu’usagers de projets open source.

À voir si donc les investissements d’IBM/Red Hat et de Chainguard ne se font pas au détriment de pratiques et de relations bien établies.

Jeffrey Michael revient par ailleurs sur la méthode. L’intervention d’ingénieurs (aidés de pipelines IA) qui ne sont pas forcément des contributeurs aux projets open source cibles pourrait poser un problème de maintien du code à long terme. « Un correctif peut se compiler, passer avec succès un analyseur, et pourtant ne pas constituer la bonne solution pour un projet », illustre-t-il. Les mainteneurs sont de plus en plus nombreux à pester contre les contributions générées à l’IA. Là, les parties prenantes devront tenir les engagements cités plus haut.

Pour que Lightwell soit pertinent, IBM et Red Hat doivent placer les communautés open source au centre du dispositif en faisant preuve d’une grande transparence, recommande Jeffrey Michael. Ces mêmes communautés n’ont cessé de réclamer des financements pour les aider à gérer ces problèmes qui se répercutent sur les entreprises.

Cet article est une adaptation d’un article publié initialement en anglais sur SearchAppArchitecture.