Mythos a mis le logiciel libre à l'épreuve — il a tenu | BeLibre - Plateforme indépendante Belge d'expertise et de propositions politiques

TL;DR : En avril, Anthropic a annoncé un modèle d’IA nommé Mythos qui aurait identifié des milliers de failles de sécurité critiques dans tous les principaux systèmes d’exploitation et navigateurs web. La réaction a été bruyante : la Bank of England a averti les régulateurs que le modèle pourrait « crack the whole cyber risk world open », la trésorerie américaine a convoqué les grandes banques, et le NHS England a fermé tous ses dépôts de code publics en moins de deux semaines. Cinq semaines plus tard, la poussière est retombée et le tableau est différent. Des analystes indépendants ont passé les chiffres au crible. Le créateur de curl, l’un des outils open source les plus utilisés au monde, a fait passer Mythos sur sa propre base de code et n’a trouvé qu’une faille mineure, qualifiant la frénésie médiatique de « primarily marketing ». 99 % des découvertes revendiquées par Mythos restent non publiées et non vérifiées indépendamment. Ce qui s’est passé pendant ces cinq semaines, c’est que le monde open source a corrigé et publié sa part des failles, dans des journaux de commits que tout le monde peut consulter. C’est l’open source qui fonctionne comme il est censé fonctionner. Ne le présentons donc pas comme un risque. La leçon pour nos administrations est l’inverse de celle qu’a tirée le NHS England. Fermer son code ne rend pas plus sûr. Financer l’écosystème open source dont on dépend déjà, et utiliser les mêmes outils d’IA défensivement sur son propre code, oui.

# Le tableau s’est rééquilibré

Le 7 avril 2026, Anthropic a annoncé Project Glasswing et Claude Mythos Preview. L’affirmation : des milliers de vulnérabilités zero-day de gravité élevée et critique, dans tous les principaux systèmes d’exploitation et navigateurs web. En une semaine, la réaction institutionnelle a été sans précédent. Andrew Bailey, gouverneur de la Bank of England, a nommé Mythos explicitement dans un discours à Columbia University le 15 avril, déclarant aux régulateurs qu’Anthropic « may have found a way to crack the whole cyber risk world open ». Scott Bessent, secrétaire au Trésor américain, et Jerome Powell, président de la Fed, ont convoqué les PDG des plus grandes banques américaines à une réunion non annoncée. UK Finance, la FCA, HM Treasury et le National Cyber Security Centre ont réuni les huit plus grandes banques britanniques. Le 29 avril, le NHS England a émis la directive interne SDLC-8 ordonnant la fermeture de tous les dépôts de code publics, avec une date limite de conformité fixée au 11 mai, soit moins de deux semaines plus tard.

Cinq semaines plus tard, les données sont là. Le tableau est plus nuancé que la réaction d’avril ne le laissait penser.

VulnCheck a analysé le Patch Tuesday de Microsoft du 14 avril, qui adressait 164 CVE et constituait le deuxième plus important jamais enregistré. Une seule CVE de cette divulgation est directement attribuable à Project Glasswing. La conclusion de VulnCheck était simple : « Mythos and Project Glasswing were only made public earlier this month, far too recently to have had much impact on the Patch Tuesday update. » Sur l’ensemble de la base CVE, le chercheur Patrick Garrity de VulnCheck a identifié 75 entrées mentionnant Anthropic, dont 40 effectivement créditées à des chercheurs d’Anthropic. Une seule, CVE-2026-4747 (une faille d’exécution de code à distance dans le NFS de FreeBSD), est explicitement attribuée à Project Glasswing lui-même.

Le 11 mai, Daniel Stenberg, développeur principal de curl, a publié sa revue d’une analyse Mythos de la base de code de curl. L’analyse avait été conduite sous Project Glasswing, via l’initiative Alpha-Omega de la Linux Foundation. Le rapport revendiquait cinq « confirmed security vulnerabilities » sur 176 000 lignes de code C. Après examen par Stenberg et l’équipe de sécurité de curl, la liste s’est réduite à une seule faille de faible gravité, prévue pour la version 8.21.0 fin juin. Trois des quatre éléments écartés étaient des faux positifs décrivant des comportements documentés dans l’API de curl. Le quatrième était un bug ordinaire, sans dimension de sécurité. Conclusion de Stenberg : la frénésie médiatique était « primarily marketing ». Pour mettre en contexte : des analyses précédentes assistées par IA sur la même base de code, avec Zeropath, AISLE et OpenAI Codex Security, avaient produit 200 à 300 corrections de bugs sur les huit à dix mois précédents, dont plus d’une douzaine de CVE confirmées.

Anthropic elle-même indique que plus de 99 % des découvertes de Mythos ne sont pas encore corrigées, les détails restant sous embargo de divulgation coordonnée.

Les attributions publiques à ce jour sont fortement orientées vers des cibles FOSS : le bug TCP SACK vieux de 27 ans d’OpenBSD, la faille H.264 de FFmpeg vieille de 16 ans, des chaînes d’élévation de privilèges dans le noyau Linux, CVE-2026-4747 dans FreeBSD. Les découvertes côté closed source restent sous embargo, avec des hashes de commitment cryptographiques publiés en lieu et place des détails.

Au vu des données actuelles, l’épisode Mythos est une démonstration de la vitesse de l’écosystème FOSS sous pression. Le triage, les correctifs et l’attribution publique se sont faits côté ouvert en quelques semaines après la divulgation. La bonne lecture pour les administrations belges est d’investir dans cet écosystème, pas de s’en retirer.

# Pourquoi le FOSS a pu réagir si vite

L’avantage de vitesse visible n’est pas de la chance. C’est le résultat d’une infrastructure communautaire accumulée.

Les journaux de commits publics permettent à n’importe quel opérateur de suivre un correctif au moment où il est intégré. L’attribution ouverte des CVE permet à n’importe quel chercheur de demander un identifiant pour un bug FOSS. Une pratique mature de divulgation coordonnée des vulnérabilités (CVD) signifie que les mainteneurs savent comment trier, coordonner et publier. Plusieurs parties peuvent vérifier et contribuer aux correctifs. Des décennies d’expérience communautaire des calendriers de divulgation donnent une mémoire musculaire institutionnelle.

La comparaison pertinente est la propre politique CVD d’Anthropic, énoncée avec précision : une date limite de divulgation par défaut à 90 jours (ou à la publication du correctif, selon ce qui arrive en premier) ; une extension de 14 jours lorsque le mainteneur est engagé et progresse ; un calendrier compressé de 7 jours pour les vulnérabilités critiques activement exploitées ; et une attente séparée de 45 jours après le correctif pour les détails techniques complets. Le FOSS bat couramment ces chiffres d’un ordre de grandeur. Le correctif TCP SACK d’OpenBSD est arrivé dans les jours suivant la divulgation Mythos. La CVE NFS de FreeBSD a été publiée avec ses correctifs dans la même cadence.

Cette infrastructure n’est pas gratuite, et les implications de financement reviennent en section 5.

# Le NHS England a lu le moment à l’envers

La directive SDLC-8 du NHS England a été émise le 29 avril avec une date de conformité au 11 mai. La fermeture a précédé l’analyse de VulnCheck, la revue de curl par Stenberg, et même un cycle complet de Patch Tuesday qui aurait pu permettre au tableau public de se rééquilibrer.

La directive a traité la visibilité du FOSS (journaux de commits, attributions publiques de CVE, divulgations nommément attribuées à des mainteneurs) comme une vulnérabilité du FOSS. C’est une lecture compréhensible depuis une institution qui ne travaille pas nativement dans l’écosystème FOSS. C’est la mauvaise lecture.

La fermeture ne traite ni la surface d’attaque réelle (que l’IA a accélérée des deux côtés de la ligne de divulgation), ni l’asymétrie de visibilité (qui est structurelle dans la mécanique de divulgation ouverte versus fermée, et non une preuve d’asymétrie dans le nombre de bugs). Le bon mouvement est de corriger la perspective, pas de s’en éloigner davantage.

# Résonance

La réponse institutionnelle au sein du Royaume-Uni est contestée. La lettre ouverte sur Keep Things Open appelle le NHS England à retirer SDLC-8 et à réaffirmer son engagement envers le NHS Service Standard, dont le Principe 12 prévoit déjà que le nouveau code source doit être ouvert par défaut. À la mi-mai, la lettre a recueilli 2 098 signatures depuis le 1er mai 2026, beaucoup provenant de personnes ayant contribué à des logiciels du secteur public britannique. Une pétition séparée a été déposée sur le site du Parlement britannique. La Free Software Foundation Europe a publié sa propre déclaration le 4 mai, arrivant à la même conclusion à partir d’un point de départ différent : « Public Money? Public Code! », la lettre Keep Things Open s’appuie sur les directives existantes du NHS England lui-même, tandis que nous nous concentrons sur les cinq semaines de données. Trois récits qui convergent vers la même conclusion.

# Le FOSS bien fait : ce que montrent les exemples qui fonctionnent

Le schéma qui consiste à investir dans l’infrastructure FOSS plutôt qu’à s’en retirer est visible depuis longtemps, et les exemples qui fonctionnent sont concrets.

En Wallonie, iMio est une coopérative intercommunale d’informatique qui sert environ 90 % des communes wallonnes sur une pile FOSS partagée (Plone, Django, Odoo). Quarante techniciens, autonomie financière vis-à-vis des subsides régionaux depuis 2021. Un correctif écrit pour l’une des quelque 250 communes est disponible pour les 249 autres. La mutualisation des correctifs entre opérateurs est une pratique opérationnelle.

En France, la DINUM gère code.gouv.fr comme catalogue d’État des FOSS du secteur public, avec un Conseil Logiciels Libres qui conseille sur les pratiques. Une migration pilotée des postes de travail de l’État hors de Windows est en cours. Rien de cela n’est de l’infrastructure hypothétique.

En Allemagne, la Sovereign Tech Agency a investi environ 23,5 millions d’euros dans plus de 60 technologies FOSS critiques, notamment Log4j, GNOME, Samba, FFmpeg et curl. L’agence elle-même est une descendante institutionnelle directe de la leçon de Heartbleed (2014), lorsque OpenSSL était maintenu par deux développeurs surchargés sur des dons annuels inférieurs à 2 000 USD. La réponse structurelle à cet incident a été la Core Infrastructure Initiative de la Linux Foundation, devenue OpenSSF. La solution au sous-financement du FOSS critique a été l’argent, pas la fermeture.

Au niveau européen, l’Article 25 du Cyber Resilience Act crée un régime spécifique et plus léger pour les open-source software stewards, reconnaissant qu’un organisme public ou une organisation à but non lucratif qui soutient un projet FOSS est différent d’un éditeur commercial qui le commercialise.

Discourse fournit le modèle opérationnel d’usage défensif de l’IA sur un seul projet. Leur version d’avril 2026 a corrigé 50 problèmes identifiés via des scans IA défensifs sur leur propre base de code. Le coût est négligeable face à n’importe quel budget de sécurité sérieux. Mêmes modèles, mêmes techniques que côté attaquant, mais exécutés d’abord par le défenseur sur du code que le défenseur contrôle déjà.

L’épisode Mythos est le point de données le plus récent dans un schéma. L’engagement communautaire financé produit le type de vitesse de divulgation visible dans les attributions publiques côté FOSS au cours des cinq dernières semaines.

# Comment les administrations belges s’y engagent

Six points en découlent pour le SPF BOSA, les agences numériques régionales (Digitaal Vlaanderen, paradigm.brussels, SPW Digital), iMio, Smals et le CCB.

Traiter les dépendances comme partie intégrante de la base de code. Les bibliothèques sous toute application non triviale du secteur public sont du code du secteur public, à tout point de vue sauf comptable. Inventoriez les composants FOSS dont dépend un service, et acceptez la responsabilité institutionnelle qui va avec. Le schéma Heartbleed reste l’avertissement canonique ici.

Financer l’amont. Argent, code, rapports de bugs, temps. Rendez cette dépense visible comme ligne budgétaire publiée plutôt que cachée comme contribution en nature. Le CCB, le SPF BOSA et chaque administration régionale devraient pouvoir pointer un budget de contribution à l’amont. La Sovereign Tech Agency est le modèle qui fonctionne.

Constituer des équipes internes qui s’engagent avec les communautés FOSS. C’est en partie une question de recrutement. Les développeurs veulent livrer du code qui sera lu, et une institution qui publie son code a un avantage de recrutement sur une institution qui ne le fait pas. C’est aussi une question de culture. L’engagement amont prend du temps que le modèle d’appel d’offres n’a historiquement pas chiffré.

Utiliser l’IA défensivement. Faites tourner les mêmes modèles sur votre propre code de façon planifiée, avec des correctifs qui atterrissent dans le journal de commits public. La revue humaine sur le code généré par IA reste non négociable. Les 50 problèmes capturés par Discourse dans une seule version mensuelle, à coût négligeable, sont le modèle.

Mettre en place une infrastructure de divulgation coordonnée. Un fichier security.txt publié, une politique de divulgation coordonnée, un canal d’avis public. La politique CVD d’Anthropic, énoncée avec précision comme en section 2, est un modèle raisonnable, tout comme la structure utilisée par Google Project Zero et CERT/CC. Les organismes publics belges produisant des volumes significatifs de logiciels devraient envisager de demander le statut de CVE Numbering Authority.

Utiliser activement le stewardship prévu à l’Article 25 du CRA. Les organismes publics belges devraient être des stewards visibles de projets FOSS critiques pour l’infrastructure publique belge. L’instrument juridique existe ; il s’agit de l’utiliser.

Un mot sur la coordination. La question Mythos est posée actuellement dans tout le secteur public belge. Le SPF BOSA, iMio, Digitaal Vlaanderen, paradigm.brussels, SPW Digital et Smals seront tous probablement confrontés à des décisions d’achat et de divulgation au cours du même exercice budgétaire. Les lignes directrices publiées de l’ENISA sur l’IA en cybersécurité et l’EU Open Source Observatory (OSOR) sont des forums de coordination utiles. Une réflexion coordonnée produit de meilleures réponses et offre une couverture politique à toute administration prenant individuellement la bonne décision.

# Pourquoi la fermeture est la mauvaise réponse, en bref

Chacun des points ci-dessous a été argumenté longuement ailleurs. Ils figurent dans cet article comme matériel de soutien, pas comme titre.

La sécurité par l’obscurité est la forme de sécurité la plus faible depuis Kerckhoffs (1883). L’argument selon lequel fermer le code réduit ce qu’un attaquant équipé d’IA peut voir suppose un niveau de confinement du code qui n’existe pas en pratique.

Le closed source n’est pas réellement fermé. Le Government Security Program de Microsoft a, depuis 2003, fourni un accès contrôlé au code source à plus de 40 gouvernements et plus de 100 agences. La Tianfu Cup en Chine a démontré à plusieurs reprises des chaînes d’exécution de code à distance fonctionnelles contre des cibles closed source entièrement à jour, incluant Windows, iOS, Microsoft Exchange, Chrome et Safari, sans accès au code source. La famille de modèles LLM4Decompile (EMNLP 2024) atteint 87 % de recompilabilité du C décompilé, ce qui revient à dire que l’analyse binaire est désormais à portée de tout acteur disposant d’un modèle actuel et d’un binaire cible.

L’éditeur contrôle le registre de divulgation. Microsoft, Apple, Oracle et Cisco sont CNA pour leurs propres produits. Les programmes de bug bounty des grands éditeurs closed source comportent des clauses de confidentialité empêchant la publication indépendante. Le client qui fait tourner une version plus ancienne est la seule partie qui n’apprend rien.

L’IA fonctionne aussi pour les défenseurs, sur la même base de code que les défenseurs contrôlent déjà. Les données de Discourse et les orientations opérationnelles du blog du NCSC du 30 mars 2026 vont dans la même direction.

Les quatre points sont individuellement courts ici parce que le rééquilibrage en section 1 fait déjà l’essentiel du travail de réfutation. L’argument selon lequel l’écosystème FOSS serait significativement plus exposé sous l’effet de la découverte accélérée par IA ne survit pas à cinq semaines de contact avec les données réelles.

# Regard prospectif

Les divulgations closed source restantes de Mythos arriveront dans les mois à venir, à la cadence propre à chaque éditeur. Le tableau public continuera de se compléter. Mythos et ses successeurs continueront à trouver de vrais bugs dans du vrai code, des deux côtés de l’écosystème, et l’infrastructure défensive doit être en place pour les absorber. La capacité est réelle, même si le marketing d’avril a dépassé ce que les premières semaines de données ont soutenu.

La décision qui se présente maintenant aux administrations belges, c’est ce qu’elles font du temps de réponse institutionnel que le rééquilibrage leur a offert.

Les administrations qui ont réagi à l’emballement d’avril en fermant leurs dépôts seront enfermées dans des dépendances aux éditeurs et des déficits de visibilité, à un moment où les données commencent à atténuer la lecture initiale. Les administrations qui ont réagi en investissant dans l’engagement communautaire FOSS, dans l’infrastructure de divulgation et dans la capacité défensive d’IA, seront en meilleure position quel que soit l’atterrissage final des divulgations closed source.

Le choix est entre s’appuyer sur un écosystème qui fonctionne (iMio, SPF BOSA, ENISA, OSOR, OpenSSF, Sovereign Tech Agency, stewardship de l’Article 25 du CRA) et s’appuyer sur des silos d’éditeurs. L’analyse de Stenberg, les données de VulnCheck, le chiffre de 99 % non corrigé, et les attributions publiques fortement orientées vers le FOSS sont des signaux précoces sur le choix que les données soutiennent réellement.

BeLibre

Autonomie Numérique

Mythos a mis le logiciel libre à l'épreuve — il a tenu