- La détection de vulnérabilités par l’IA dépassant désormais la vitesse de réaction des mainteneurs, Akrites a été lancé comme une coopération industrielle visant à renforcer collectivement les logiciels open source critiques
- La découverte de vulnérabilités graves prenait autrefois plusieurs semaines à des experts, mais désormais des modèles d’IA peuvent trouver plusieurs vulnérabilités en quelques minutes, ce qui accroît brutalement la charge de réponse
- AWS, Anthropic, Chainguard, Cisco, Citi, Ericsson, Google, IBM, Microsoft et GitHub, NVIDIA, OpenAI, Red Hat, la Rust Foundation et d’autres ont convenu de coordonner les correctifs upstream et la divulgation responsable
- Akrites fournit un point de coordination confidentiel et une Security Incident Response Team dédiée afin de réduire les signalements en doublon et les patchs conflictuels, et assume aussi un rôle de mainteneur de dernier recours pour les paquets critiques sans mainteneur
- Comme des attaquants peuvent rétroconcevoir des vulnérabilités avec l’IA après la publication d’un patch, le critère de réussite n’est pas la divulgation en elle-même, mais le déploiement effectif des correctifs sur les systèmes réels
La vitesse de la sécurité open source transformée par l’IA
- L’open source est devenu la base des infrastructures et services critiques dont les gens dépendent chaque jour, comme la banque, les télécoms ou les services publics
- Les mêmes composants open source étant largement utilisés dans l’ensemble des stacks techniques, de nombreux systèmes partagent les mêmes défauts potentiels
- L’IA modifie l’équilibre entre attaquants et défenseurs, et réduit le coût de la découverte et de la réutilisation des vulnérabilités
- Découvrir une vulnérabilité grave prenait autrefois plusieurs semaines à un expert, mais une machine peut désormais le faire en quelques minutes
- Il arrive aussi qu’un modèle d’IA retourne plusieurs vulnérabilités en une seule exécution
- Les mêmes capacités peuvent servir à la défense, mais si elles sont détournées, la découverte de vulnérabilités peut être industrialisée
Une structure où les signalements en doublon mettent les mainteneurs sous pression
- Les procédures existantes de réponse et de divulgation en matière de sécurité reposaient sur des organisations et des équipes agissant de manière lâchement coordonnée, ce qui pouvait conduire à traiter le même problème en parallèle ou à produire des patchs conflictuels et plusieurs rapports
- Si des dizaines d’entreprises scannent indépendamment la même bibliothèque et soumettent chacune leur rapport, les mainteneurs se retrouvent noyés dans le bruit
- Plus le nombre d’acteurs au courant d’une vulnérabilité non corrigée augmente, plus le risque de fuite avant correction augmente aussi, et ce risque se propage à tout l’écosystème
- Même des réponses de bonne foi, sans coordination, peuvent aggraver le problème et faire perdre du temps
La méthode de réponse collective d’Akrites
- Akrites a été lancé comme un effort visant à déployer un système et des outils communs pour trouver, corriger et divulguer de manière responsable les vulnérabilités des logiciels open source critiques
- Parmi les participants figurent Amazon Web Services, Anthropic, Chainguard, Cisco, Citi, Endor Labs, Ericsson, Google, IBM, JPMorganChase, Microsoft et GitHub, NVIDIA, OpenAI, RapidFort, Red Hat, la Rust Foundation, Sonatype, Vodafone, Zscaler et d’autres
- Le cœur de la réponse est l’upstream lorsqu’un mainteneur existe
- Il fournit un lieu unique, confidentiel et fondé sur la confiance pour coordonner la découverte, la correction et la divulgation des vulnérabilités
- Une Security Incident Response Team dédiée devient pour les mainteneurs un partenaire unique et prévisible, plutôt qu’une multitude de signalements non coordonnés
- Les correctifs doivent revenir vers le dépôt d’origine de chaque projet et suivre le flux habituel des mainteneurs
- Lorsqu’un paquet critique n’a pas de mainteneur, Akrites indique qu’il assumera un rôle de mainteneur de dernier recours afin que les correctifs soient livrés à temps
Pourquoi le déploiement compte plus que la publication d’un patch
- Une fois un patch publié, des attaquants peuvent utiliser l’IA pour rétroconcevoir rapidement la vulnérabilité réelle, développer un exploit et lancer des attaques
- Le succès d’Akrites doit donc être mesuré non par la publication d’un patch, mais par son déploiement effectif sur les systèmes réels
- Akrites veut collaborer avec les propriétaires et opérateurs d’infrastructures critiques, les efforts de la société civile et les gouvernements afin d’élever le niveau de coordination
- La confidentialité n’est pas négociable, car une faille non divulguée dans un paquet largement déployé est de fait comparable à une arme, ce qui fait de la prévention des fuites une priorité
La charge et les engagements soulignés par les organisations participantes
- Endor Labs indique que, parmi les milliers de vulnérabilités open source confirmées ces derniers mois, la part effectivement corrigée est inférieure à 5 %
- OpenInfra indique que la communauté OpenStack a publié 20 avis de sécurité sur ce seul trimestre, contre 2 sur l’ensemble de l’année 2025
- JPMorganChase estime que l’IA a comprimé le temps entre la découverte d’une vulnérabilité et son exploitation jusqu’à quelque chose de presque temps réel, ce qui impose aussi de réduire le délai entre la correction et le déploiement
- Chainguard, Sonatype, RapidFort, Red Hat et d’autres soutiennent que la correction des vulnérabilités doit se faire via une coordination upstream, dans le logiciel d’origine et le flux habituel des mainteneurs, plutôt que d’être fragmentée dans des forks ou derrière des murs privatisés
- Les organisations participantes promettent d’apporter des ressources d’ingénierie, de l’expertise en sécurité, des financements et des technologies d’IA pour renforcer les logiciels partagés
1 commentaires
Avis sur Hacker News
Beaucoup d'acteurs de l'open source ne peuvent qu'être sceptiques en voyant la liste des entreprises participantes, et c'est compréhensible.
La question centrale est de savoir comment mettre en œuvre le principe consistant à « trouver, corriger et divulguer de manière responsable les vulnérabilités des logiciels open source critiques ». En contribuant via les canaux existants et des pull requests, on peut avancer avec la communauté, mais forker au nom de la « sécurité » risque de marginaliser la communauté, de diviser les ressources et, à long terme, de tuer de nombreux projets. Les bug bounties ont du potentiel, mais pour les failles critiques, la rapidité et le calendrier de divulgation ne sont pas toujours adaptés, et même le soutien financier reste d'effet limité s'il n'est pas combiné à un soutien aux mainteneurs
PQCA donne accès au matériel via des crédits AWS pour exécuter des preuves et de la CI, et propose aussi du mentorat rémunéré. OWF fournit également des crédits AWS et l'hébergement de services de test. LFDT a mis en place du mentorat rémunéré, le financement de revues par Trail of Bits, l'organisation d'événements, un sommet des mainteneurs à New York, le support de grands runners GitHub CI, etc. Notre équipe ne compte que 3 employés à temps plein, 1 prestataire et 1 manager côté relations développeurs pour OWF/PQCA/LFDT, mais nous faisons de gros efforts pour aider les développeurs.
LFDT: https://www.lfdecentralizedtrust.org/
OWF: https://openwallet.foundation/
PQCA: https://pqca.org/
Exemple de benchmark PQCA : https://pq-code-package.github.io/mldsa-native/dev/bench/
Quelle que soit la forme retenue, il faut que ce soit distribué de manière à ce qu'aucun point central ni aucune entité unique ne puisse exercer le contrôle
On parle de contribution financière, mais la manière de le faire et son objectif comptent tout autant. La plupart des projets ne sont pas prêts à recevoir des dons ni à en faire usage. En revanche, ce serait bien que tous les projets open source puissent disposer d'un accès significatif à l'IA pour examiner leur codebase et leurs pull requests, afin de réduire la charge de maintenance, et il existe déjà quelques tentatives dans ce sens
Ce n'est que de la mise en scène d'entreprise.
Microsoft dit vouloir « apporter son expertise, ses ressources et ses technologies d'IA pour identifier et corriger de manière responsable les vulnérabilités », mais Microsoft exploite NPM et GitHub, et a accès aux meilleurs modèles d'IA ainsi qu'à d'immenses datacenters. Pourtant, la sécurité de ses propres produits se dégrade rapidement, et ses services deviennent des hubs centraux où se propagent de multiples exploits.
Si vous voulez voir comment Microsoft gère les problèmes de sécurité dans ses propres projets open source, je recommande ce fil GitHub : https://github.com/dotnet/efcore/issues/38257
EF Core distribue actuellement une version de SQLite contenant une vulnérabilité grave. Le problème a été découvert il y a plus d'un an, SQLite l'a corrigé en une semaine, mais EF Core n'a pas marqué le pilote comme vulnérable jusqu'à ce que des utilisateurs le signalent à nouveau récemment et se disputent avec les développeurs. Le correctif pour la version stable actuelle de .NET Core n'est attendu que dans environ deux mois
Après le rachat, au lieu de prolonger cette dynamique avec VSCode, Microsoft a installé une ambiance de dénigrement d'Electron, et maintenant beaucoup de gens détestent Electron sans même savoir expliquer pourquoi. VSCode n'a même pas forké Atom, il a été recréé de zéro dans le même esprit, puis il est devenu plus gros, plus lent, et maintenant on lui a encore ajouté Copilot. J'ai fini par revenir à Pulsar, un bon fork d'Atom.
Microsoft voit toujours les acquisitions sous l'angle de l'opportunité et de la concurrence, mais utilise rarement correctement ce qu'il achète. L'entreprise fait disparaître de bons employés et du bon code, puis abîme les produits. Et malgré ça, tout le monde continue d'utiliser les produits Microsoft, ce que je ne comprends pas. Il faut quitter LinkedIn et migrer ensemble vers un autre système de gestion de versions. Tant que les développeurs open source ne joindront pas les actes à la parole, Microsoft continuera à empirer
Nous ne ferons pas ça. Nous n’allons pas nous contenter de grandes déclarations, laisser les entreprises commerciales tout saccager, puis nous plaindre bruyamment de l’état des choses alors qu’en réalité nous n’aurons rien fait
À l’avenir, je pense qu’on verra apparaître un mouvement que j’appelle undo fork. C’est un fork qui revient au moment d’avant le début de la folie pour repenser les choses, et c’est quelque chose que seules des personnes non liées à des exigences commerciales peuvent faire
Je conseille toujours aux personnes intéressées par l’open source de rester loin de la Linux Foundation. De nos jours, elle est devenue un obstacle qui entrave la liberté logicielle au lieu de la rendre possible
Pour défendre l’open source, il faut commencer non par des paroles, mais par un soutien concret aux projets et aux développeurs
Du point de vue d’un développeur OpenBSD, fournir du nouveau matériel aux développeurs est vraiment important. Beaucoup travaillent sur des ThinkPad vieux de 5 à 10 ans qui devraient être remplacés
https://www.openbsd.org/want.html
Il manque encore environ 50 % à l’OpenBSD Foundation pour atteindre son objectif de collecte de fonds 2026
https://www.openbsdfoundation.org/campaign2026.html
https://brynet.ca/wallofpizza.html
Au moment où on lit « Amazon Web Services participe », toute la crédibilité de ce texte disparaît
Cela se lit comme une tentative de centralisation et de contrôle. Qui qu’Akrites soit, cela ne fera que donner aux grandes entreprises technologiques, Google compris, le pouvoir de contrôler l’open source
Merci, mais non merci. Je n’ai pas oublié que Google cherche à bloquer dès ce mois de septembre, sur Android, les installations tierces via des
.apkÀ ce sujet, la plupart des gens intelligents que je connais pensent que l’IA open source rend Anthropic et OpenAI financièrement intenables. Beaucoup des entreprises qui ont signé ici sont fortement liées à ces deux sociétés, et elles ont tout intérêt à déstabiliser l’IA open source avant que leurs clients ne subissent un choc tarifaire. J’attendais de voir quel serait leur prochain coup, et cela pourrait en faire partie
L’information la plus importante est que « les participants apportent des ressources d’ingénierie »
Il faut voir si cela se concrétisera comme prévu. À part ça, je ne suis pas particulièrement impressionné par les promesses de ce projet. La structure favorise la centralisation et les réseaux centrés sur les entreprises, soit exactement l’inverse de la direction que l’éthique hacker a encouragée pour de bonnes raisons
Cela pourrait aussi devenir une autre source de pression. Ils réussiront peut-être à bien filtrer les vraies vulnérabilités, mais le résultat arrivera ensuite chez les mainteneurs avec une priorité élevée. Beaucoup de mainteneurs sont déjà épuisés même sans le bruit de l’IA, et même si un correctif est fourni, il faut encore le relire
Dans le meilleur des cas, cela peut réduire le bruit, mais le travail, lui, reste. Le secteur devrait financer de manière générale les projets open source pour qu’ils aient eux-mêmes les moyens de gérer cela. C’est probablement aussi ce qu’il y a de mieux pour la qualité. S’il faut filtrer le bruit de l’IA, on peut ajouter cette fonction, mais cela ne doit pas prendre la forme d’une structure secrète et opaque qui contrôle tout
J’attends le jour où je verrai des titres du genre « Nous dépendons tous de l’open source. Nous allons le financer ensemble »
J’aime bien le nom « Akrites »
Cela peut être moins frappant pour quelqu’un qui n’est pas grec, mais pour un Grec, cela donne une image assez forte
akron signifie bord ou frontière, donc quelque chose comme « gens des confins » ou « hommes de la frontière ». L’essentiel ici est qu’on ne peut pas projeter tel quel des conflits ou préjugés modernes sur une histoire vieille de mille ans. Dans son contexte historique, c’était comparable à bien d’autres frontières entre civilisations différentes, et le point important est qu’il s’agissait d’une organisation collective réunie pour défendre son territoire
[1] https://en.wikipedia.org/wiki/Mark_Carney%27s_Davos_speech
Je pense qu’il ne sert pas à grand-chose de publier ce genre de message sur Hacker News. La majorité des gens ici adhèrent profondément à la dynamique de l’IA et ne s’en soucient pas vraiment.
En plus, beaucoup d’entreprises de la liste font partie des principaux suspects quant à l’état actuel de l’open source.
En revanche, je suis d’accord sur le fait que beaucoup d’entreprises de la liste font partie des principaux suspects concernant l’état de l’open source. Cela ressemble à une publicité de relations publiques destinée à les blanchir, et j’ai du mal à croire qu’elles se soucient réellement de l’éthique de l’open source.