The Usual Suspects

"The greatest trick the devil ever pulled was convincing the world he didn't exist." Les bases publiques de vulnérabilités sont fausses à grande échelle. En avril 2026, la machine le vérifie.

Deux publications parues à deux semaines d'intervalle en mars et avril 2026. Aucun rapport apparent entre elles. Lues ensemble, elles décrivent la fin d'un équilibre qui tenait depuis vingt ans.

La première, le 27 mars, vient de six chercheurs de Zhejiang University. Ils ont pris 259 exploits Java connus, les ont exécutés sans modification sur 28 150 versions de 128 bibliothèques, et ont comparé le résultat à ce que disent les grandes bases de vulnérabilités du marché. Un exploit brut identifie correctement 83% des versions vulnérables, avec une précision de 99,3%. Mieux que NVD, mieux que GitHub Advisory, mieux que GitLab et Veracode. Seul Snyk fait un peu mieux en volume, au prix d'une précision inférieure de neuf points¹.

La seconde, le 13 avril, vient de l'AI Security Institute britannique. C'est l'évaluation des capacités cyber de Claude Mythos Preview, dont les articles précédents de cette série documentent les implications pour le code IA, les frameworks défensifs et le CRA. Le chiffre qui compte ici : 73% de réussite sur les épreuves Capture the Flag de niveau expert, et premier modèle à compléter intégralement une chaîne d'attaque à 32 étapes contre un réseau d'entreprise simulé².

En clair

Le premier papier dit que les bases de données officielles sur lesquelles toute la défense de la supply chain logicielle repose sont fausses à grande échelle. Elles oublient des branches entières, se trompent de bibliothèque, ignorent des versions que des centaines de projets utilisent en production. Un exploit qu'on fait tourner en aveugle retrouve mieux la vérité qu'elles.

Le second papier dit qu'une machine peut désormais, sans supervision humaine, faire tourner ces exploits à l'échelle, les adapter quand ils ne marchent pas, et découvrir de nouvelles vulnérabilités par-dessus le marché.

Ces deux faits ont une conséquence commune. Pendant vingt ans, la sécurité des dépendances logicielles a reposé sur une fiction tolérable : les bases publiques étaient imparfaites, mais vérifier empiriquement coûtait trop cher pour tout le monde, défenseurs comme attaquants. La fiction tenait parce que personne ne pouvait se payer la vérification à l'échelle. Les machines que l'AI Security Institute a évaluées en avril 2026 le peuvent.

Le registre contre la réalité

Quand un développeur veut savoir si une bibliothèque qu'il utilise est vulnérable, il consulte une base publique. NVD est la base fédérale américaine hébergée par le NIST, registre de référence mondial. GitHub Advisory, GitLab Advisory, Snyk et Veracode sont les quatre autres sources majeures. Tous les outils commerciaux de supply chain security, notamment les scanners SCA qui tournent dans les chaînes d'intégration continue, lisent ces bases et raisonnent sur leurs déclarations.

L'étude Chen et al. mesure ce que ces cinq bases affirment, et compare leurs affirmations à une vérité établie manuellement. Pour chaque vulnérabilité, les chercheurs ont tracé le commit qui l'a introduite, vérifié le code source de chaque version publiée, et déterminé si le défaut était présent ou non. Deux annotateurs expérimentés, accord inter-annotateurs à 0,911 sur l'échelle Cohen, méthode standard en ingénierie logicielle. Le résultat est une base de vérité contre laquelle tester les autres¹.

Les écarts sont lourds. Sur les 259 vulnérabilités étudiées, un exploit brut identifie 796 versions vulnérables absentes de NVD. Les chercheurs les ont signalées à l'équipe CPE qui maintient NVD, qui a confirmé avoir procédé aux corrections, tout en signalant une file d'attente importante sur les autres signalements en cours¹.

Cinq types d'omissions reviennent. Des bibliothèques mal identifiées, Snyk pointant le module parent au lieu du module vulnérable. Des branches entières ignorées, comme les versions 2.10 et 2.11 de jackson-databind pour CVE-2020-24616, passées sous silence. Des plages d'introduction tronquées, certains CVE remontant bien plus loin qu'annoncé. Des plages de correctif fausses, avec des versions postérieures au patch officiel restant vulnérables. Des versions instables (RC, beta, alpha) systématiquement exclues alors que Maven Central les sert à des centaines de projets¹.

La conclusion est directe. La couche informationnelle sur laquelle repose toute la gestion des vulnérabilités Java est incomplète et fausse à grande échelle. Personne ne l'avait vérifiée empiriquement avant cette étude. Le 15 avril 2026, le NIST a formalisé ce que les données montrent depuis des mois : l'enrichissement universel des CVE est abandonné, environ 80% des soumissions seront classées « Not Scheduled » faute de capacité⁵.

Dix stratégies, désormais automatisables

Dans 17% des cas, l'exploit brut échoue à cause de différences entre versions : un nom de méthode qui a changé, un type d'argument qui a évolué, une chaîne d'objets qui a été réorganisée. Ce détail change tout quand on le relit à la lumière de l'évaluation AISI. Les chercheurs ont migré manuellement ces exploits vers les versions cibles et récupéré 77% des échecs. Le recall final passe à 96,1%¹.

Ils documentent dix stratégies de migration. Ce sont des opérations précises. Tracer les renommages dans les diffs du code source. Adapter les types d'arguments. Reconstruire des chaînes de gadgets alternatives. Ajuster les assertions de vérification. Ce travail demande 15 à 55 minutes par cas à un ingénieur senior en sécurité logicielle¹. Pour un humain, cela reste long et coûteux.

Un modèle qui complète une chaîne d'attaque 32 étapes de bout en bout peut exécuter ces opérations. Les dix stratégies documentées par Chen décrivent exactement le type de transformation que ce type d'agent traite bien : lecture de diff, adaptation d'API, réécriture ciblée. Ce que le papier Chen traite comme une limite humaine coûteuse s'effondre, désormais, en coût marginal machine.

La même bascule vaut hors des modèles fermés. L'équipe qui a remporté le concours cyber de la DARPA en 2025 a mesuré, sur du Java, les deux temps d'une découverte : localiser la faille, puis construire la charge qui la déclenche et la prouve. Avec un modèle de pointe, leur système exploite 41 vulnérabilités sur 54 ; avec GLM-5, un modèle à poids ouverts sous licence MIT qu'on héberge où l'on veut, 35, pour 392 dollars au total contre 2 400 à 3 100 pour les modèles de pointe⁷. Un modèle qu'on télécharge et qu'on fait tourner en local n'a pas de guichet à fermer.

La vérification change de camp

Le défenseur s'appuie sur des déclarations. Quand son scanner lui dit qu'une version est saine, il fait confiance au registre. Ce registre est faux dans des proportions mesurables. Le problème ne se limite pas aux versions. Une étude de l'Université du Tennessee publiée en avril 2026 mesure la fiabilité d'un autre signal défensif : la signature de commit sur GitHub⁶. Le taux de signature apparent est de 89%. Retiré la signature automatique que GitHub appose via son interface web, le taux réel tombe à 5,94%. Sur les 94% de « signataires apparents », aucun n'a jamais signé en dehors du navigateur. Le badge « Verified » que les développeurs et les frameworks de provenance (SLSA, in-toto) traitent comme une attestation cryptographique d'identité est, dans la quasi-totalité des cas, une attestation que la plateforme a signée elle-même. Un attaquant qui compromet un compte GitHub hérite du badge vert sans effort supplémentaire.

L'attaquant procède par l'exécution. Il prend un exploit public, il le lance. Si ça marche, la version est vulnérable. Si ça ne marche pas, il adapte.

Cette vérification empirique par l'attaquant coûtait jusqu'ici du temps d'expert humain. Un attaquant opportuniste ne la faisait pas. Un attaquant ciblé la faisait sur une cible précise, jamais à l'échelle de tout un dépôt. C'est ce coût, et rien d'autre, qui tenait en équilibre l'avantage défenseur/attaquant depuis vingt ans. La qualité des bases et l'ingéniosité des scanners n'y sont pour rien. Ce qui comptait, c'est le coût humain de la vérification empirique.

Un agent autonome de niveau Mythos supprime ce coût. Il peut prendre chaque exploit public disponible, l'appliquer à chaque version d'une bibliothèque, migrer les cas récalcitrants via les stratégies décrites, et produire une cartographie réelle des versions exploitables, sans supervision humaine, à l'échelle d'un dépôt entier, pour le prix du compute.

Côté défensif, rien ne bouge. Les bases restent incomplètes. Les scanners continuent de lire les mêmes métadonnées. Le rapport conjoint Cloud Security Alliance / SANS / OWASP publié le 12 avril, coordonné par Gadi Evron, Robert T. Lee et Rich Mogull avec les contributions de Jen Easterly, Chris Inglis, Rob Joyce et Bruce Schneier, résume la situation en une phrase : le coût d'exploitation s'effondre, le délai entre divulgation d'une vulnérabilité et sa weaponisation se comprime vers zéro, des capacités qui exigeaient des ressources d'État deviennent largement accessibles³.

Livrer du code en 2026

Un développeur qui publie un service Java aujourd'hui fait tourner un scanner SCA sur son pipeline d'intégration. Le scanner interroge une base publique, compare les versions de ses dépendances aux versions déclarées affectées, et rend un verdict. Si le verdict dit "pas de vulnérabilité connue", le développeur livre. Tout le processus repose sur une hypothèse implicite : la base publique sait quelles versions sont affectées.

Les données détruisent cette hypothèse. Le verdict "pas de vulnérabilité connue" signifie en réalité "aucune des bases publiques que j'ai consultées ne liste cette version comme affectée". Ces deux énoncés n'ont plus rien à voir. Entre les deux, il y a les 796 versions manquantes dans NVD, les branches ignorées de jackson-databind, les versions RC que Snyk exclut par principe alors que Maven Central les distribue.

L'exploitabilité réelle dépend aussi du contexte d'exécution. Version du JDK, système d'exploitation, dépendances transitives chargées en mémoire. Sur les 2 447 cas d'échec d'exploit documentés par Chen, 544 proviennent d'une incompatibilité JDK entre l'environnement de référence et l'environnement cible¹. Un correctif déployé en JDK 11 ne dit rien sur l'exploitabilité en JDK 17. Aucun scanner SCA n'intègre ce contexte aujourd'hui.

Le Cyber Resilience Act entre en pleine application le 11 décembre 2027⁴. Il impose aux éditeurs de logiciels un suivi des vulnérabilités connues sur toute la durée de vie du produit. L'obligation repose implicitement sur la fiabilité des bases publiques. Aucun article du règlement ne traite le cas où ces bases sont fausses par construction. Un éditeur pourra être parfaitement conforme au CRA et livrer à ses clients des produits exploitables sans le savoir.

Ce que je ne sais pas

Java et Maven uniquement. La transférabilité des conclusions à npm, PyPI, Go ou aux binaires C/C++ n'est pas démontrée. Je suppose que l'écart serait plus large dans les environnements dynamiquement typés et plus variable dans les compilations natives, mais cette supposition reste à valider.

Le taux de 96,1% post-migration décrit des conditions de laboratoire : experts seniors, temps illimité, accès au code source complet, droit à l'erreur. Ni le papier ni les évaluations AISI ne mesurent le rendement réel d'un agent autonome appliquant ces stratégies en aveugle sur un parc inconnu. Je fais l'hypothèse qu'un agent de niveau Mythos Preview atteint un rendement substantiel, pas le rendement maximal humain.

Les évaluations AISI précisent que leurs environnements de test ne comportent ni défenseurs actifs, ni EDR, ni supervision temps réel. La capacité démontrée s'applique à des systèmes faiblement défendus. Extrapoler à des environnements durcis serait prématuré.

Sur les modèles à poids ouverts, ce qui est mesuré, c'est la découverte d'une vulnérabilité et la construction de l'exploit qui la déclenche⁷. La migration d'un exploit d'une version à l'autre, l'opération précise décrite plus haut, je ne l'ai vue quantifiée nulle part sur ces modèles. L'exploitation autonome d'une chaîne entière reste, à ma connaissance, au-dessus de ce qu'ils atteignent aujourd'hui, et je ne sais pas dans quelle mesure ces résultats de laboratoire se transposent à des cibles réelles.

Conclusion

Avril 2026 fait coïncider deux faits qui n'avaient rien à voir. Une étude empirique mesure que les bases publiques de vulnérabilités sont fausses à grande échelle. Une évaluation officielle démontre qu'un agent autonome peut désormais exécuter, adapter et chaîner des exploits à l'échelle d'un dépôt entier. Les deux phénomènes décrivent la même réalité vue des deux côtés. Le défenseur consulte des registres. L'attaquant exécute des tests. Ce qui tenait cette différence en équilibre depuis vingt ans, c'est le coût humain de la vérification empirique. Ce coût vient de tomber.

La gestion de vulnérabilités fondée sur la confiance accordée aux registres publics n'est plus défendable. Les éditeurs qui veulent sérieusement savoir quelles versions de leurs dépendances sont exploitables devront valider empiriquement, sur leur propre parc, avec leurs propres outils. Cela exige du compute, de l'expertise, et une capacité d'interprétation qui n'existe aujourd'hui dans aucune offre commerciale. Construire cette capacité prendra des années. Le délai pour le faire se mesure désormais en mois.

Dix-neuvième article d'une série sur les failles structurelles de la cybersécurité occidentale :

• Article 1 : La vulnérabilité de la gestion des vulnérabilités
• Article 2 : La dépendance européenne aux standards américains
• Article 3 : Les États, architectes cachés du marché noir des vulnérabilités
• Article 4 : L'IA ou l'effondrement du modèle défensif occidental
• Article 5 : Desert Power — survivre sans l'Empire
• Article 6 : I Am Altering the Deal
• Article 7 : Le dernier canal
• Article 8 : Lord of Cyber War
• Article 9 : Les faucons du numérique
• Article 10 : They Live... we sleep
• Article 11 : Soylent Green
• Article 12 : Ghost in the Binary
• Article 13 : Now You See Me
• Article 14 : The Prestige
• Article 15 : Pitch Black
• Article 16 : The Thing That Should Not Be
• Article 17 : Status: clean
• Article 18 : Le Guépard

Sources

¹ Chen Z., Zhan Q., Zhou J., Hu X., Xia X., Yang X. « A Large-scale Empirical Study on the Generalizability of Disclosed Java Library Vulnerability Exploits. » arXiv:2603.25997v1 [cs.SE], 27 mars 2026. https://arxiv.org/abs/2603.25997

² AI Security Institute (UK). « Our evaluation of Claude Mythos Preview's cyber capabilities. » Blog AISI, 13 avril 2026. https://www.aisi.gov.uk/blog/our-evaluation-of-claude-mythos-previews-cyber-capabilities

³ Evron G., Lee R.T., Mogull R. (et al.) « The "AI Vulnerability Storm": Building a "Mythos-ready" Security Program. Expedited Strategy Briefing. » Cloud Security Alliance / SANS Institute / [un]prompted / OWASP Gen AI Security Project, 12 avril 2026. Contributing authors : Jen Easterly (CEO RSAC, ex-CISA), Bruce Schneier (Inrupt, Harvard Kennedy School), Chris Inglis (ex-National Cyber Director, The White House), Phil Venables (Ballistic Ventures, ex-CISO Google Cloud), Heather Adkins (CISO Google), Rob Joyce (ex-Cybersecurity Director, NSA), Sounil Yu (CTO Knostic), Jim Reavis (CEO CSA), Katie Moussouris (CEO Luta Security), James Lyne (SANS), Dave Lewis (CISO 1Password), Joshua Saxe (Security Superintelligence Labs), Ramy Houssaini (CCSO Cloudflare), et autres. https://labs.cloudsecurityalliance.org/wp-content/uploads/2026/04/mythosready-20260413.pdf

Couverture journalistique associée : Brumfield C. « Anthropic's Mythos signals a structural cybersecurity shift. » CSO Online, 13 avril 2026. https://www.csoonline.com/article/4158117/anthropics-mythos-signals-a-structural-cybersecurity-shift.html

⁴ Règlement (UE) 2024/2847 du Parlement européen et du Conseil du 23 octobre 2024 concernant des exigences horizontales de cybersécurité pour les produits comportant des éléments numériques et modifiant les règlements (UE) n° 168/2013 et (UE) 2019/1020 et la directive (UE) 2020/1828 (règlement sur la cyber-résilience). Publié au JO L du 20 novembre 2024, entré en vigueur le 10 décembre 2024, applicable à partir du 11 décembre 2027. Obligations de reporting des fabricants applicables à partir du 11 septembre 2026. https://eur-lex.europa.eu/eli/reg/2024/2847/oj

⁵ NIST. « NIST Updates NVD Operations to Address Record CVE Growth. » 15 avril 2026. Seules trois catégories de CVE seront enrichies en priorité : KEV CISA, logiciels fédéraux, logiciels critiques (EO 14028). Le reste classé « Lowest Priority, not scheduled for immediate enrichment ». Backlog antérieur au 1ᵉʳ mars 2026 basculé en « Not Scheduled ». Voir « Pitch Black » dans cette série pour l'analyse des huit vecteurs de dégradation NIST. https://www.nist.gov/news-events/news/2026/04/nist-updates-nvd-operations-address-record-cve-growth

⁶ Shittu A., Herbold S., Morrison P. « Analysis of Commit Signing on GitHub. » University of Tennessee, avril 2026. 71 694 utilisateurs, 874 198 dépôts, 16 millions de commits. Taux de signature apparent 89%, taux de signature locale réelle 5,94%. 94,29% des signataires apparents n'ont jamais signé hors de l'interface web GitHub. https://arxiv.org/abs/2604.14014

⁷ Fleischer F., Zhang C., Jang J., Cho J., Xu M., Kim T. « Contextualizing Sink Knowledge for Java Vulnerability Discovery. » IEEE Symposium on Security and Privacy 2026 (à paraître). Benchmark de 54 vulnérabilités Java sur 22 projets open source. Avec un modèle de pointe, le système GONDAR exploite 41 vulnérabilités sur 54 (preuves vérifiées par sanitizer) ; avec GLM-5 (poids ouverts, licence MIT), 35, pour 392 dollars au total contre 2 400 à 3 100 dollars pour les configurations de pointe. Système développé par Team Atlanta, vainqueur du DARPA AI Cyber Challenge 2025 (Georgia Tech, Samsung Research, KAIST, POSTECH). https://arxiv.org/abs/2604.01645