Vulnérabilités : l’écosystème open source face aux dilemmes du tout IA

En 2025, les modèles d’IA ont généré des rapports de vulnérabilité de piètre qualité

L’IA générative a amplifié le phénomène. « Nous avons des rendez-vous réguliers pour relire les rapports de vulnérabilité et, pendant un temps, l’expression qui revenait le plus souvent, c’était “world salad” », témoigne-t-il.

« Nous avons des rendez-vous réguliers pour relire les rapports de vulnérabilité et, pendant un temps, l’expression qui revenait le plus souvent, c’était “world salad” ».

Les quatre à six pages d’un rapport généré par IA évoquaient souvent une vulnérabilité « vaguement plausible », sans véritables éléments pour la justifier.

Mickaël Barbero, directeur de la cybersécurité pour l’Eclipse Foundation, mentionne un phénomène similaire à l’échelle des projets soutenus par l’ONG. Lui et son équipe jouent le rôle d’intermédiaire entre les chercheurs en sécurité et les mainteneurs. Cette équipe forme également les mainteneurs aux bonnes pratiques de cyberprotection et leur fournit l’accès à des outils appropriés.

« Jusqu’à la fin de l’année 2025, nous avons observé une augmentation du nombre de rapports de vulnérabilités de chercheurs utilisant l’IA. Ces rapports étaient généralement de basse qualité », confirme-t-il.

En réponse à ce problème, les mainteneurs de Rails ont pris une décision radicale. « Nous avons été obligés de supprimer le bug bounty », rapporte Jean Boussier. « Désormais, les rapports sont soumis par des personnes qui soutiennent le projet ou qui souhaitent accroître leur réputation », indique-t-il. Cela ne supprime pas les « rapports IA », mais il n’y a plus de récompense à la clé.

La fondation Eclipse, elle, entend favoriser l’usage de l’IA pour la recherche de failles et de vulnérabilités. « La qualité des rapports coécrits par l’IA a nettement augmenté. Nous n’avons quasiment plus de faux positifs », considère Mickaël Barbero.

Jean Boussier remarque de son côté que les rapports générés par des LLM sont plus concis. « Je pense qu’au bout d’un an, les failles de sécurité que les LLM trouvaient assez facilement ont été colmatées. Je suppose qu’ils trouvent moins de choses », déclare-t-il.

Ce gain de qualité n’est pas synonyme d’une baisse de la charge de travail. Au contraire. « La contrepartie, c’est la multiplication des rapports : il y a beaucoup de duplicata », note pour sa part Mickaël Barbero. « Nous avons décidé de nous occuper de cette tâche : avant de les partager avec les responsables des projets, nous faisons de recherches de rapports existants afin de ne pas leur soumettre deux fois le même problème ».

Il y a forcément un écart flagrant de moyens entre la Rails Foundation et ceux d’Eclipse, qui accueille de multiples projets open source. D’autant que l’Eclipse Foundation est membre du projet Glasswing d’Anthropic. Elle a accès aux modèles d’IA de classe Fable et Mythos, des modèles spécialisés en cybersécurité développés par Anthropic. Ceux-là ont justement servi et aidé à trier les rapports de vulnérabilités.

Vers un scan plus systématique des projets open source

Plus particulièrement, ces cinq derniers mois, Mythos a été utilisé pour scanner plusieurs fois les dépôts GitLab et GitHub utilisés par les mainteneurs des projets.

Là, il s’agit de lutter contre les comportements malicieux, mais aussi les vulnérabilités et les backdoors introduites par inadvertance par les contributions générées par IA. « Nous mettrons sûrement en place un scan plus régulier à l’aide de modèles frontières comme Mythos pour détecter les vulnérabilités dans le code du projet », relate Mickaël Barbero.

Des moyens qui ne sont pas illimités. « Nous n’en sommes pas encore à proposer aux mainteneurs de scanner toutes les contributions avec ces LLM. Ce sera la prochaine étape », indique le directeur de la cybersécurité.

En outre, il faut déjà traiter le backlog des précédentes découvertes. « Rapporter, vérifier, valider, corriger prend bien plus de temps que la seule recherche de failles », signale-t-il.

Les scans plus réguliers seront probablement menés en fonction de la vélocité du développement des projets et de leur importance pour les communautés. La majorité des projets au sein de l’Eclipse Foundation sont soutenus par des éditeurs et de grandes entreprises.

« Nous offrons déjà des recommandations et des outils, mais ils ne font pas nécessairement appel à l’IA », précise Mickaël Barbero.

Valkey, alternative à Redis, intégré à la Linux Foundation, profite déjà de scans IA de vulnérabilités. « Nous recevons beaucoup plus de signalements aujourd’hui, car tout le monde utilise l’IA pour détecter les vulnérabilités, nous inclus », affirme Jacob Murphy, mainteneur du projet Valkey et ingénieur logiciel chez Google. « Cela nécessite toujours beaucoup de travail de notre part pour examiner et évaluer chaque vulnérabilité ».

« Cela nécessite toujours beaucoup de travail de notre part pour examiner et évaluer chaque vulnérabilité ».

Selon lui, un agent IA peut considérer qu’un problème est plus grave qu’il ne l’est en réalité. À l’inverse, il peut confondre un bug avec une vulnérabilité.

« Les LLM sont très bons pour les tâches de pattern matching (filtrage par motif) et donc pour trouver des bugs », estime Madelyn Olson, membre du comité technique du projet Valkey et ingénieure logiciel principale chez AWS. « Il y a deux mois [en juillet 2026, N.D.L.R], le modèle que j’utilise a trouvé un soi-disant bug dans notre implémentation du protocole TLS. C’était en réalité une vulnérabilité. Si elle n’avait pas été corrigée, des acteurs malveillants s’en seraient donné à cœur joie », illustre-t-elle.

Éliminer les « vulnérabilités de surface »

Néanmoins, comme Jean Boussier, Jacob Murphy espère que la correction proactive des « vulnérabilités de surface » permettra d’abaisser le nombre de rapports. « Pour aller au-delà de ce genre de vulnérabilités superficielles, il faut des connaissances plus approfondies. En la matière, nous espérons avoir un avantage et pouvoir aller plus loin dans nos recherches pour les identifier », ajoute-t-il. « Mais c’est vraiment un terrain inexploré. On assiste à une augmentation massive des capacités tant des attaquants que des mainteneurs ».

 En de rares occasions, les mainteneurs de Valkey tombent sur la reproduction d’exploitation de failles pas encore corrigées. « Il nous faut généralement quelques semaines pour corriger les failles que nous avons trouvées », indique Jacob Murphy. En attendant, Madelyn Olson s’aide d’un LLM pour trier les rapports de ces mails liés aux problèmes de sécurité identifiés par des contributeurs (et leurs IDE agentiques).

Pour Mickaël Barbero, l’accès généralisé aux LLM permet de rééquilibrer la balance entre les hackers éthiques et ceux du mauvais côté de la barrière. « Avant l’IA, la balance était nettement en faveur des cyberattaquants », estime-t-il. « Nous ne naviguons plus à l’aveugle. En revanche, il ne faut pas ralentir l’adoption des outils IA, sinon les attaquants vont reprendre de l’avance ».

Modéliser les menaces qui pèsent sur les projets open source

Dans un même temps, le directeur de la cybersécurité de l’Eclipse Foundation suggère fortement aux mainteneurs de définir un modèle de menace et des frontières de confiance.

« Le fait d’avoir un modèle de menace et de risque était une pratique qui n’était pas forcément bien comprise ou bien promue avant au sein des projets open source », explique Mickaël Barbero. « Cela devient essentiel avec les outils d’IA. S’ils “détectent” un modèle de menace dans une base de code, ils vont pouvoir le prendre en compte et justement se limiter à la recherche de vulnérabilités à l’intérieur des frontières de confiance. Ils ne pollueront pas les rapports avec des éléments qui pourraient provenir d’environnements sans lien avec un projet », illustre-t-il.

Cyber Resilience Act oblige, la définition de ce modèle de menace devient une obligation pour les industriels et les fournisseurs qui utilisent les projets open source au sein de produits commercialisés dans l’Union européenne. « Ce modèle de menace sera nécessaire pour leur conformité. Il définit les mesures à prendre pour s’assurer de la qualification de leurs produits vis-à-vis du marquage CE après le mois de décembre 2027 », souligne Mickaël Barbero. Bien que les projets open source ne seront pas soumis à cette obligation, c’est une autre bonne raison d’intégrer ce « threat model ».

L’autre sujet en cours de discussion au sein de l’Eclipse Foundation n’est autre que le renforcement de la posture de sécurité en matière de dépendances. « La posture de sécurité de nos projets dépend aussi de celle de leurs dépendances. Nous voulons donc aider les mainteneurs concernés à corriger leurs problèmes de sécurité », indique Mickaël Barbero. Cela implique des échanges avec ces mainteneurs en provenance d’autres horizons.

« La posture de sécurité de nos projets dépend aussi de celle de leurs dépendances. Nous voulons donc aider les mainteneurs concernés à corriger leurs problèmes de sécurité ».

L’Eclipse Foundation souhaite ainsi s’inspirer de l’initiative « Beach Cleaning ». Menée pour Apache Airflow en partenariat avec la Fondation Apache et la Python Software Foundation, elle est financée par le fonds de la mission Alpha Omega, un projet au sein de la Linux Foundation. Beach Cleaning vise à chasser les vulnérabilités au sein d’Apache Airflow et ses plus de 700 dépendances Python. « C’est ce genre de mécanisme qu’on veut mettre en place avec l’aide de nos projets », indique le directeur de la cybersécurité.

Pour mieux sécuriser les projets open source, faut-il interdire d’interdire l’IA ?

Pour le moment, l’Eclipse Foundation a un guide d’utilisation consacré à l’IA générative, pas un code (« policy »). Selon Mickaël Barbero, deux sujets plus propices au débat sont sur la table. Deux sujets qui n’ont pas été évoqués par les autres responsables interrogés par LeMagIT.

Premièrement, les responsables de l’Eclipse Foundation se demandent s’il ne faut pas « interdire d’interdire l’IA » aux responsables des projets, notamment pour la chasse aux vulnérabilités. « Cette question sera soumise aux communautés. C’est évidemment un sujet plus sensible », indique le responsable.

De fait, l’IA générative et agentique, bien que largement adoptée par les développeurs, est bannie en bloc de certains projets open source, tel l’OpenJDK. L’évolution du paysage des menaces pourrait changer la donne. Tout comme cela affecte des préceptes chers à l’open source.

Distinguer les humains des machines

Deuxièmement, et c’est plus évident, pour des besoins de transparence, les contributeurs devront indiquer s’ils utilisent un outil d’IA pour générer du code. « Nous estimons qu’une contribution uniquement agentique n’est pas souhaitable. Je ne veux pas m’avancer sur la décision finale, mais nous espérons qu’un humain soit toujours dans la boucle. Le code sera signé de sa main. Si la contribution est principalement générée par une IA, nous y appliquerons la licence CC0, sans copyright », anticipe-t-il.

« Nous ne vérifions pas systématiquement l’identité des individus, mais ils peuvent le faire de manière volontaire à travers un tiers de confiance, en présentant un document officiel émis par le gouvernement ».

Comme pour beaucoup d’initiatives open source, un contributeur doit créer un compte Eclipse et signer un accord avant de pouvoir contribuer. Or, un attaquant peut se faire passer pour un contributeur légitime. « Nous ne vérifions pas systématiquement l’identité des individus, mais ils peuvent le faire de manière volontaire à travers un tiers de confiance, en présentant un document officiel émis par le gouvernement. Fausser une identité est un coût supplémentaire pour les attaquants », affirme Mickaël Barbero. De plus en plus de contributeurs accepteraient cette mesure dite de confiance.

« Nous essayons de rajouter des couches de confiance sans nécessairement en faire un prérequis parce que tous les projets ne le veulent pas, n’en ont pas besoin ou n’ont pas nécessairement la maturité pour mettre en place ces mécanismes », précise-t-il d’emblée.

Mais le directeur de la cybersécurité insiste sur la nécessaire distinction des humains des machines. « Aujourd’hui, nous avons la vérification de papiers d'identité. Demain, si nous avons un meilleur moyen, nous l’utiliserons. Le mécanisme actuel s’appuie sur la base du volontariat, mais si les responsables d’un projet veulent le mettre en place, nous sommes capables de le faire », suggère Mickaël Barbero.