OSS Scanner : 29 000 failles trouvées, 516 corrigées

Le 8 octobre 2026, Anthropic a lancé OSS Scanner, un service gratuit de recherche de vulnérabilités réservé aux projets open source qui le demandent. La nouvelle aurait pu passer pour une opération de communication de plus. Le chiffre qui l'accompagne a rendu ça impossible : en six mois de scans internes, les modèles de l'entreprise ont sorti plus de 29 000 vulnérabilités candidates. Et 516 ont été corrigées en amont.

Un ratio de 1,8 %. Tout l'intérêt du dossier est là.

Ce qu'OSS Scanner fait concrètement

Le principe est volontairement calqué sur OSS-Fuzz, le service de fuzzing que Google offre depuis dix ans aux briques critiques du logiciel libre. Même philosophie, autre moteur : au lieu de bombarder un programme d'entrées aléatoires en espérant un crash, OSS Scanner fait lire le code par les modèles les plus puissants d'Anthropic, Claude Mythos compris, pour y repérer des défauts de logique exploitables.

Les règles du jeu :

• opt-in : un projet doit candidater, rien n'est scanné sans accord ;
• critères d'éligibilité alignés sur OSS-Fuzz : impact critique sur l'infrastructure ou la sécurité des utilisateurs, avec décision au cas par cas ;
• scans périodiques et approfondis, gratuits ;
• rapports générés par les modèles sans relecture humaine préalable — c'est assumé, c'est ce qui permet d'aller vite et souvent ;
• deux voies de sortie : la divulgation coordonnée classique pour les projets sans capacité de triage, et une voie rapide pour ceux qui acceptent de recevoir des rapports non vérifiés.

Le service est l'industrialisation de Project Glasswing, l'opération interne pendant laquelle Anthropic a fait éplucher à Claude les projets les plus structurants de l'écosystème. C'est de là que viennent les 29 000.

Les chiffres clés, et celui qui compte vraiment

• 29 000+ vulnérabilités candidates en six mois ;
• ~6 000 examinées et triées manuellement, soit un gros cinquième ;
• 516 corrigées en amont par les mainteneurs ;
• ~5 000 rapports non vérifiés transmis directement aux projets qui ont demandé à les recevoir ;
• sur 97 failles critiques ou de gravité haute repassées par des pentesteurs experts : 85 (88 %) conformes au standard de divulgation coordonnée, 11 doublons de problèmes déjà connus, 1 seule invalide.

Ce dernier bloc mérite qu'on s'y arrête. Un taux de validité de 88 % sur les failles graves, avec un unique faux positif sur 97, ce n'est pas le bruit statistique qu'on reproche d'habitude aux outils automatiques. Le scanner n'hallucine pas des bugs. Il en trouve.

D'où l'inversion du problème. Pendant vingt ans, la question de la sécurité du libre a été : comment détecter davantage ? Elle devient : qui relit, qui corrige, qui publie le correctif. Anthropic ne cache pas que son propre service de recherche en sécurité sature — Claude produit des candidats plus vite que des humains ne peuvent les valider.

Pourquoi 516 seulement

Trois raisons, et aucune n'est de la paresse.

La charge retombe sur des bénévoles. Une bibliothèque de compression utilisée par un milliard d'appareils peut tenir sur deux ou trois mainteneurs, le soir, sans rémunération. Recevoir 200 rapports de sécurité plausibles n'est pas un cadeau, c'est un second emploi. Le mainteneur de curl a passé une bonne partie de 2025 à expliquer publiquement combien les signalements générés par IA lui coûtaient de temps — il parlait alors surtout de déchets, mais même avec un taux de validité élevé, le temps de lecture reste le même.

Un correctif n'est pas une ligne de code. Il faut reproduire, comprendre l'impact réel, écrire un test de non-régression, vérifier qu'on ne casse pas la compatibilité, coordonner un embargo, obtenir un CVE, publier. Compter en jours-homme, pas en minutes.

Beaucoup de candidats ne valent pas la dépense. Un dépassement de tampon atteignable seulement par un fichier de configuration que seul l'administrateur contrôle, c'est un vrai bug et une menace nulle. Les 6 000 triées manuellement ne sont pas 6 000 urgences.

L'angle mort : le même outil sert à attaquer

Personne, chez Anthropic, ne prétend que la capacité est exclusive. Un modèle capable de lire 100 000 lignes de C et d'y pointer un use-after-free fait exactement le même travail pour un attaquant. La seule différence est le délai : celui qui scanne en premier publie un correctif, celui qui scanne en second trouve une porte fermée.

C'est l'argument défensif, et il se tient. Il implique une course, pas une victoire. Et il a une conséquence que l'écosystème n'a pas encore digérée : plus la détection devient bon marché, plus le délai entre « la faille existe » et « la faille est exploitée » dépend de la vitesse de correction, c'est-à-dire du maillon le moins financé de la chaîne.

Autre point sensible, les rapports sans relecture humaine. Anthropic a raison sur le fond — la relecture est le goulot, la supprimer multiplie la cadence — mais cela transfère le coût de vérification au mainteneur. Pour un projet avec une équipe sécurité, parfait. Pour un développeur isolé, c'est une inondation à laquelle il n'a pas de réponse.

Ce que les 29 000 disent de l'état du logiciel libre

Un scan intensif de six mois sur les briques critiques accouche de dizaines de milliers de défauts candidats, dont des centaines de graves confirmées. Autrement dit : la dette de sécurité accumulée dans l'infrastructure logicielle mondiale n'avait jamais été mesurée, parce qu'on n'avait pas l'instrument pour la mesurer.

Ce n'est pas un procès du libre. Du code propriétaire de la même ancienneté donnerait vraisemblablement des résultats comparables ou pires — simplement personne ne peut le scanner et encore moins le publier. L'open source est le seul endroit où l'on voit le problème.

Restent les questions que la gratuité pose toujours. Qui décide qu'un projet est « critique » ? Que se passe-t-il si le service devient payant une fois les équipes dépendantes ? Les critères OSS-Fuzz fournissent un garde-fou connu, pas une garantie contractuelle.

À suivre

Trois indicateurs à surveiller dans les mois qui viennent : le nombre de projets acceptés, le délai médian entre rapport et correctif publié, et l'apparition éventuelle d'un financement pour le triage. C'est ce dernier point qui compte. Trouver 29 000 failles est désormais un problème résolu et peu coûteux. En corriger 29 000 reste un problème de personnes payées pour le faire — et aucun modèle ne l'a réglé.