L’essentiel
- Anthropic a lancé OSS Scanner : des analyses périodiques gratuites de vulnérabilités pour les projets open source critiques, menées avec ses modèles les plus performants.
- Chaque découverte arrive avec une preuve de concept, et avec un correctif lorsque c’est possible.
- Les premiers scans ont remonté 77 découvertes critiques et 803 de niveau élevé, leur gravité étant évaluée par le modèle ; l’analyse se poursuit sur d’autres projets.
Imaginez la boîte de réception d’un mainteneur (la personne qui entretient un projet open source et valide les modifications) un matin d’octobre : des rapports de failles, chacun accompagné d’un exploit qui fonctionne, et personne n’en a fait la demande. C’est le scénario que dessine le service OSS Scanner, lancé par Anthropic le 8 octobre et dont le compte ClaudeDevs a dressé un premier bilan le 19 octobre.
Le programme offre aux projets open source critiques des analyses de vulnérabilités régulières et gratuites, confiées aux modèles les plus performants de l’éditeur. Chaque découverte inclut une preuve de concept (un code qui démontre que la faille est exploitable) et un correctif quand c’est possible. Les premiers scans ont produit 77 découvertes critiques et 803 de niveau élevé.
880 signalements, une gravité notée par la machine
Additionnons : 880 découvertes au total, dont un peu moins de 9 % classées critiques (77 sur 880). Pour une première série de scans, la proportion de cas graves est loin d’être anodine. Reste que ces niveaux de gravité sont, selon l’annonce, évalués par le modèle. Aucune instance tierce n’a encore départagé ce qui est critique de ce qui est simplement élevé.
Anthropic l’assume : sa page de présentation précise que les rapports envoyés par la voie rapide n’ont pas été relus par un humain. Google a fait l’autre choix avec Big Sleep, son agent développé par DeepMind et Project Zero : ses 20 premières failles open source, annoncées à l’été 2025, passaient par un expert avant d’être signalées.
Trois données manquent pour juger ce total : le nombre de projets scannés, la part de découvertes confirmées par les mainteneurs, la part déjà corrigée. Sans elles, ces 880 découvertes décrivent un volume de sortie, pas un résultat de sécurité.
Un ordre de grandeur donne la mesure de la charge. Si l’on suppose, par hypothèse de calcul, une heure de tri par découverte pour lire le rapport, rejouer la preuve de concept et décider d’une priorité, 880 découvertes représentent 880 heures, soit environ 110 journées de huit heures. Ce travail se répartit entre les équipes concernées, mais celles-ci ne l’ont pas planifié.
Un exploit joint ne fait pas un correctif
Joindre un exploit à chaque rapport écarte la première question que pose tout mainteneur : la faille existe-t-elle ? Un rapport sans démonstration oblige à deviner ; un rapport avec démonstration se vérifie en quelques minutes. La différence sépare un soupçon d’un dossier.
La preuve de concept ne tranche pas pour autant le reste. Elle ne dit pas si la faille est atteignable dans les configurations réellement déployées, ni si elle mérite de passer avant les autres, ni quels effets de bord aurait le correctif. Et ce correctif n’est fourni que « lorsque c’est possible » : une partie des 880 découvertes arrive donc sans solution. Quand il existe, un patch écrit par un modèle sur un code critique se relit avec la même exigence qu’une contribution venue de l’extérieur.
curl, premier projet cité
Un second message d’Anthropic renvoie vers une mise à jour partagée par @thepunit, qui inclut une correction pour curl, l’outil et la bibliothèque de transfert de données présents dans un nombre considérable de logiciels. Le message ne dit pas combien de découvertes concernaient curl, ni combien ont été retenues.
Un chiffre global gagnerait pourtant à ce genre de retour : sur un projet nommé, combien de signalements ont débouché sur un merge ? Un projet aussi exposé que curl est un bon test, car sa surface d’attaque et sa vigilance sont déjà élevées. Un scanner qui y trouve encore quelque chose dit plus qu’un scanner qui trouve beaucoup dans un dépôt négligé.
Une analyse gratuite pour le projet, un coût de tri pour ceux qui l’absorbent
L’analyse est offerte aux projets. Le coût, lui, ne disparaît pas : il se déplace de la découverte vers l’absorption. Chercher des failles demandait des chercheurs, du temps de calcul et de la patience ; avec un modèle, la recherche devient un flux, et ce flux arrive chez des équipes dont la capacité de correction n’a pas bougé.
Les entreprises qui dépendent de bibliothèques open source en subiront la conséquence concrète. On peut s’attendre à des correctifs publiés par rafales, au gré des scans périodiques : mieux vaut disposer d’un moyen de suivre les avis de sécurité des composants critiques de sa pile et d’un délai réaliste pour les mises à jour. Financer du temps de tri ou de revue de correctifs devient un levier aussi utile que le scanner lui-même.
Au fil des prochains mois, le chiffre qui comptera sera la part de ces découvertes ayant abouti à un correctif intégré, et le délai qu’il aura fallu pour y parvenir.
Mon avis
Trouver une faille ne coûte presque plus rien à un modèle ; la lire, la reproduire et la corriger coûte toujours du temps humain. Tant qu’Anthropic ne publie pas la part de découvertes confirmées puis corrigées, les 880 signalements disent la puissance du scanner et rien de la sécurité gagnée. Je voudrais voir ce programme financer l’attention des mainteneurs avec autant de sérieux que ses propres calculs.
Sources
Ils m’ont fait confiance
« Il ne se contente pas de corriger les symptômes, il cherche à comprendre l'origine des problèmes et à sécuriser les modifications effectuées. J'ai réellement le sentiment d'avoir trouvé un développeur qui comprend à la fois la technique et les enjeux globaux du projet. »
Évaluation client · projet WordPress · septembre 2026
5,0/5 sur 17 évaluations
Faire appel à mes services →
