BLOG
Hot Tracking 041 | 37 966 rapports de failles, 217 corrigés
Quel s’est passé
Contexte. Le 7 avril 2026, Anthropic a lancé le projet Glasswing, avec pour déclaration officielle : « Nous avons identifié des milliers de vulnérabilités supplémentaires de niveau haut et grave, et nous les révélons responsable aux mainteneurs open-source ». Le lancement a été très médiatisé : le post HN 1541▲/836💬 a été publié, avec une mise à jour initiale le 22 mai pour 561▲ et une extension le 2 juin pour 180▲. En mai, Anthropic a lancé son propre ledger de révélations, mis à jour de manière irrégulière en masse. Le 8 octobre, ils ont également publié le service d’analyse automatique OSS Scanner, annonçant avoir découvert plus de 29 000 vulnérabilités candidates, mais n’ayant vérifié manuellement que environ 6 000 d’entre elles, « la limite réside dans la capacité de vérification manuelle » ; ils ont également envoyé près de 5 000 rapports non vérifiés aux mainteneurs qui avaient demandé l’accès complet. « Génération complète des modèles, sans vérification manuelle ou à trois étapes » sont les mots exacts utilisés par Anthropic dans sa déclaration officielle.
Audit. VulnCheck a commencé à suivre les incidents le 17 avril, avant même que le ledger d’Anthropic ne soit mis en ligne ; la méthode consiste à maintenir le dépôt open-source Anthropic Credited CVEs, à comparer les archives de CVE, GHSA, les commits du noyau Linux et le ledger d’Anthropic, et à auditer manuellement les annonces. Ce n’est pas la première fois que VulnCheck publie des résultats de suivi : depuis la première observation le 15 avril, il a publié des observations du ledger (le 9 juin), un rapport sur l’exploitation actuelle (le 28 juillet) et la dernière vérification de phase (le 8 septembre). Cette fois, c’est la cinquième mise à jour en sept mois. Les résultats des sept derniers mois (tous conformes aux déclarations de VulnCheck) : 442 CVE peuvent être attribués à Anthropic, soit environ 63 par mois, ce qui représente environ 0,5 % des 93 450 CVE de cette année ; parmi ces 442, seulement 2 ont été exploitées (0,45 %, CVE-2026-61500 et CVE-2026-26980, comparé à KEV de VulnCheck). Une autre comparaison : les 442 identifiés par VulnCheck dépassent le nombre de vulnérabilités corrigées signalées par le ledger d’Anthropic (217, selon Anthropic) par deux fois.
Vérification par les mainteneurs. Vers le 6 novembre, trois jours avant la publication sur le blog, Daniel Stenberg, mainteneur de curl, a annoncé avoir reçu 45 rapports de vulnérabilités d’Anthropic. Anthropic estime que seulement 1 rapport est de niveau moyen, et tous les autres sont de niveau bas ; Daniel a délibérément ralenti le transfert sur GitHub « pour réduire l’impact sur l’équipe », avec l’intention de rendre tous les rapports publics d’ici la semaine. Les résultats de vérification des 34 rapports publiés : 19 ont été déclarés « non comme vulnérabilités », 6 ont été confirmés comme basiques, et 9 sont restés à évaluation. Le taux de fausses positives était de 55,9 %, celui de confirmation de 17,6 % avec tous les rapports classés basiques. Ce n’est pas la première fois : en mai de cette année, Daniel avait déjà rapporté que 5 trouvailles Mythos n’ont finalement confirmé qu’une vulnérabilité. Jusqu’à présent, Anthropic n’a pas répondu positivement à cet audit (aucun message ni blog n’a été trouvé).
Audit du ledger : augmentation rapide des découvertes, stagnation des corrections
Si vous trierez les chiffres indiqués par Anthropic selon l’ordre chronologique, les problèmes se révéleront d’eux-mêmes. Au lancement en mai : 23 019 trouvailles, avec un taux de positivité déclaré à 90,8 %. Mise à jour du 2 novembre : 37 966 trouvailles, dont seulement 217 ont été corrigées, et 7 349 (19,4 %) ont été rendues publiques.
Regardez le tableau des changements pendant près de deux mois, du 09-08 au 11-02 (tous rapportés par Anthropic) : le nombre total de trouvailles est passé de 26 153 à 37 966 (+11 813) ; celles rendues publiques ont augmenté de 2 736 à 7 349 ; les corrections ont progressé de 202 à 217 (seulement +15) ; les retraits de rapports ont augmenté de 245 à 419 (+174) ; les duplications ont diminué de 2 à 1 670 (+1 668). En moyenne, il y a eu 1 654 duplications (4,4 %), soit environ 7,5 fois le nombre de corrections. Cette augmentation significative des duplications n’est pas fortuite : VulnCheck avait déjà averti dans sa dernière mise à jour en septembre que plus les rapports restent longtemps dans le système, plus il y a de chances qu’ils soient découverts et corrigés avant les autres. Deux mois plus tard, cette prévision s’est réalisée : la capacité de découverte était pleinement utilisée, mais la capacité de correction était bloquée, ce qui a entraîné des duplications et des retraits.
Le nombre de trouvailles a augmenté de près de moitié en deux mois, tandis que le nombre de corrections n’a augmenté que de 15 ; l’augmentation des retraits et des duplications était plus importante que celle des corrections. Les points d’interrogation détectés par VulnCheck se trouvent là : les retraits et les duplications sont plus nombreux que les corrections, tandis que le taux de positivité déclaré est passé de 90,8 % à 94,2 % (91,4 % en 09-08, +2,8 points). Le système de rapports manque peut-être un circuit de retour sur « trois échecs », car les rapports considérés comme « non comme vulnérabilités » ne sont pas pris en compte. De plus, VulnCheck a découvert une erreur dans le système qui fait grimper artificiellement le nombre de rapports rendus publics (« disclosed » filtre réutilisable).
Le niveau de gravité ne correspond pas non plus. Selon les découvertes de VulnCheck en septembre, Claude a classé 91,5 % des trouvailles comme graves/hautement risquées, tandis que les maintaineurs n’en ont reconnu que 51,3 %. Pour le même ensemble de rapports, il y a une différence de 40 points de pourcentage entre l’évaluation automatique et la détermination des maintaineurs.
Transférer la charge de vérification : de OSS Scanner à curl
La deuxième critique concerne non pas les chiffres, mais le processus. Anthropic a reconnu que chaque trouvaille jugée manifestement irrécupérable nécessitait une classification manuelle en trois catégories. C’est pourquoi, le 8 octobre, ils ont changé la méthode : OSS Scanner est passé en mode auto-évaluation, où les maintaineurs se chargent eux-mêmes de soumettre des scans et de classer les résultats. Après l’introduction d’OSS Scanner, seulement environ 6 000 des 29 000 vulnérabilités candidates ont été vérifiées manuellement, tandis que près de 5 000 rapports non vérifiés ont été directement envoyés aux maintaineurs qui demandaient une réception complète. Selon Anthropic, ces rapports étaient entièrement générés par le modèle, sans vérification ou classification manuelle. Comme la capacité de découverte était pleinement utilisée, mais que celle de vérification ne l’était pas, qui devait combler ce déficit ? L’exemple de curl a donné une réponse : les maintaineurs se chargent eux-mêmes de combler le déficit. Il y a ici une logique propre à Anthropic : la justification pour introduire le mode auto-évaluation est que « si le taux de positivité est vraiment aussi élevé qu’il le prétend, il ne devrait pas y avoir de problème pour les maintaineurs de les classer eux-mêmes ». Le taux de fausses positives de 55,9 % de curl montre que cette hypothèse n’est pas justifiée, et que le coût du mode auto-évaluation est en réalité imputé aux heures de travail des maintaineurs.
Les actions de Daniel après avoir reçu 45 rapports méritent une attention particulière : il a ralenti le rythme de publication sur GitHub afin « de réduire l’impact sur l’équipe ». Il a vérifié chaque rapport, publiant tous les problèmes de faible et moyenne gravité en tant qu’issues. Les commentaires de VulnCheck sont les suivants : les mainteneurs doivent « contrôler le rythme » pour protéger leur équipe, ce qui indique déjà une lourde charge ; quant à curl, il a décidé de publier tout en open source, comme une démonstration de transparence.
Il est important de clarifier les limites de la critique : ni cet article ni VulnCheck ne nient que « l’AI trouve efficacement des failles ». VulnCheck affirme constamment que l’AI est un outil efficace, et les 442 CVE sont bien réellement inclus dans les données. Ce qui est critiqué, c’est le fait que la quantité de détecteurs et la réparation des failles ne correspondent pas à la réalité, ainsi que le fait que les coûts de vérification soient systématiquement transférés aux mainteneurs du logiciel ouvert.
Audit des actions : le engagement initial ne correspond pas à la réalité des sept mois suivants
Le premier point est l’engagement quantitatif. Au début, on annonce « des milliers de failles hautement critiques et graves » ; sept mois plus tard, VulnCheck indique 442 CVE, soit environ 0,5% de l’année, avec seulement 2 failles exploitées de manière répandue. Entre les milliers et les 442, même si on considère tous les 7,349 rapports publiés comme des CVE, il y a encore une différence dans le calcul entre « rapport de recherche » et « CVE » – curl donne un taux de conversion de 17,6%, et tous ces rapports sont de faible gravité.
Le deuxième point est l’engagement qualitatif. L’autre aspect de la « divulgation responsable » est la qualité des informations divulguées : le taux de validité de VulnCheck est de 94,2% (données fournies par Anthropic), contre 55,9% de fausses positivités chez curl (données des mainteneurs) ; Claude a un taux de validité de 91,5% pour les failles graves/hautes, contre seulement 51,3% reconnu par les mainteneurs. Ces deux taux ne peuvent pas être identiques.
Le troisième point est la manière de répondre. Le rapport n’est mis à jour qu’en masse, sans rétroaction suffisante ; aucune réponse positive n’a été donnée après la publication du rapport. Entre l’effet de 1541▲ au début et le silence de 35▲ après l’audit, les autorités n’ont pas fait de remède. Le rythme lui-même mérite attention : trois publications officielles ont amplifié l’attention, mais face à la vérification par des tiers pendant sept mois, il y a eu du silence jusqu’à présent.
La description originale de VulnCheck est : les preuves ne correspondent pas à l’histoire initiale de lancement. Cet article respecte cette distinction : il ne condamne pas le « échec » ou la « falsification », mais se contente de dire que les données ne correspondent pas. Il est également important de limiter les cas : VulnCheck a des intérêts concurrentiels, et ses conclusions peuvent être suspectées de publicité (l’utilisateur HN jrflo l’a déjà souligné) ; quant à la qualité des 80,6% de rapports non publiés, personne ne peut en savoir plus, et on ne peut pas inférer que 19,4% publiés représentent tout. C’est une analyse de survivants, et l’avertissement de l’utilisateur HN dfee est valable. Cet article ne condamne pas un côté.
Que dit la section des commentaires
Il y a 35▲ de posts sur HN, avec seulement 6 commentaires, une petite quantité mais une direction intéressante à mentionner, résumée en quatre points.
Premièrement, la voie du « loup qui crie ». L’utilisateur fny dit que le signal le plus évident est qu’aucune exploitation de niveau catastrophique n’a eu lieu au cours de l’année écoulée : si des milliers de failles hautement critiques avaient été trouvées, les chiffres d’exploitation de manière répandue ne seraient pas ainsi.
II. Défaut du biais des survivants. Remarque de l’utilisateur dfee : seulement 19,4 % des découvertes sont publiées. Ce texte analyse les survivants, tandis que les 80 % restants sont peut-être faux ou non examinés. Il faut être prudent dans les conclusions. L’utilisateur hologramofham se demande : l’article tire des conclusions importantes sur la base de 19,4 % des données publiées, mais cette proportion pourrait aussi indiquer autre chose. La partie non publiée pourrait contenir des découvertes sensibles qui ne devraient pas être rendues publiques. Il n’est pas possible de distinguer ces deux possibilités en se basant uniquement sur les données dévoilées.
III. Conflit d’intérêts. L’utilisateur jrflo souligne que les conclusions de VulnCheck sont hautement cohérentes avec son modèle commercial : les fabricants de rapports sur les vulnérabilités critiquent la qualité des rapports des autres, ce qui pourrait être considéré comme de la publicité trompeuse.
IV. À ce moment de l’examen, Anthropic n’a pas répondu sur HN ou dans ses blogs.
Trois choses que les utilisateurs ordinaires peuvent faire
-
Lorsque vous recevez un rapport sur une vulnérabilité généré par l’IA, suivez votre propre processus de trois étapes. Si vous êtes un mainteneur ou responsable de la sécurité : ne croyez pas directement aux étiquettes de gravité dans le rapport. La auto-évaluation des machines indique 91,5 % de gravité/haut risque, tandis que les mainteneurs ne reconnaissent que 51,3 %. Il existe des cas concrets de inflation des étiquettes. Vous pouvez suivre la méthode de curl : recevoir en masse, contrôler le rythme, vérifier chaque rapport individuellement et publier les conclusions.
-
Avant de mettre à jour, vérifiez les exploitations réelles sur le terrain, sans vous laisser emporter par les catégories « haut risque ». Parmi les 442 CVE, seulement 2 ont été exploitées sur le terrain (0,45 %). Pour établir des priorités, comparez le catalogue KEV et les enregistrements de GHSA, et consacrez votre temps limité aux réparations des véritables vulnérabilités.
-
Regardez les deux prochaines étapes. La première est le taux de fausses positivités complet après que les 45 rapports de curl seront tous publiés cette semaine. La deuxième est si Anthropic répond ou si les comptes intègrent les feedback loops des trois étapes. Si quelque chose se passe à l’une de ces étapes, ce texte sera mis à jour en version 2.
Conclusion
Précision : ce texte ne mentionne pas « échec de Glasswing » ou « falsification des données ». Toutes les chiffres sont indiqués selon deux échelles. 442, 2, 0,5 %, 55,9 %, 17,6 %, 91,5 % contre 51,3 % sont les données suivies par VulnCheck ou vérifiées par les mainteneurs ; 23 019, 37 966, 217, 7 349, 94,2 % sont les données rapportées par Anthropic. L’objet de la critique n’est pas « l’IA cherchant des vulnérabilités », mais plutôt le décalage entre la narration des découvertes et la réalité des réparations, ainsi que le transfert de la charge de vérification aux mainteneurs open-source. Les intérêts de concurrence de VulnCheck et l’inconnu concernant les 80,6 % de découvertes non publiées sont mentionnés dans le texte, sans prédire un camp.
La vérification elle-même est plus précieuse que la qualité : pour convaincre, ce qui manque, ce n’est pas une plus grande probabilité de fausses positivités, mais un mécanisme permettant aux mainteneurs de retourner les résultats de la vérification. Si Anthropic répond dans les 48 heures (du lancement du blog le 11-09 au moment de la publication sur HN le 11-10), ou si les résultats complets de la vérification de curl sont disponibles, ils seront ajoutés à ce texte.
Sources de référence
- Blog VulnCheck : « Après 7 mois, Glasswing écrase les mainteneurs avec des résultats décevants » (publié par Patrick Garrity le 09-11-2026, texte complet vérifié 200 fois ; source directe, mais attention à la position de ses concurrents).
- Position officielle d’Anthropic : Annonce du lancement du projet Glasswing (07-04-2026), livre de comptes ledger mis en ligne en mai, mise à jour la plus récente le 02-11, description de l’OSS Scanner (08-10-2026 ; « génération complète des modèles, sans vérification manuelle ou à trois personnes » sont les termes officiels).
- Déclaration publique de Daniel Stenberg, mainteneur de curl (vers 06-11-2026 ; 45 rapports, 34 résultats vérifiés constituent la source directe pour les mainteneurs).
- Article sur Hacker News 50447074 (publié le 10-11-2026, 35▲/6💬 de commentaires lors de l’écriture, snapshot Algolia ; tous les commentaires ont été rapportés, le nom d’utilisateur est conservé).
- Données de popularité historique sur HN (post initial le 07-04 avec 1541▲/836💬, mise à jour le 22-05 avec 561▲, extension le 02-06 avec 180▲, toutes des données historiques snapshot).
Sous signature : Yongliang