Anthropic OSS Scanner propose des audits open source gratuits, mais les mainteneurs doivent trier les résultats de l’IA

Anthropic a lancé Anthropic OSS Scanner le 8 octobre, en proposant aux projets open source éligibles des audits récurrents de vulnérabilités sans frais. Ce service représente une expansion importante de la recherche en sécurité assistée par l’IA. Il transfère également une responsabilité majeure aux mainteneurs, car ses rapports sont transmis sans validation humaine.

Ce compromis définit le lancement. Anthropic affirme que ses modèles peuvent examiner davantage de code que ses chercheurs en sécurité ne peuvent en auditer manuellement. OSS Scanner élimine ce goulet d’étranglement en envoyant directement des résultats bruts aux projets participants.

Le calendrier est délicat pour les mainteneurs open source. Google a récemment suspendu certaines parties de son programme de récompenses pour les vulnérabilités open source après avoir reçu un volume croissant de signalements automatisés non valides. Le projet curl a lui aussi mis fin à son programme de bug bounty après que ses mainteneurs ont rencontré des difficultés avec des soumissions de faible qualité.

Anthropic estime que ses rapports offrent désormais des preuves bien plus solides que les résultats générés par l’IA qui avaient auparavant frustré les mainteneurs. Les retours des premiers projets étayent cette affirmation dans certains cas. Toutefois, le service public n’a pas encore démontré comment sa précision se maintiendra sur un éventail plus large de dépôts.

Anthropic OSS Scanner échange la validation humaine contre la rapidité

Anthropic OSS Scanner donne aux mainteneurs un accès plus précoce à des vulnérabilités potentielles, mais chaque projet participant devient responsable de la validation des conclusions du modèle.

Selon le lancement d’OSS Scanner, les projets participants reçoivent des analyses périodiques effectuées par les modèles les plus puissants d’Anthropic. Parmi eux figure Claude Mythos, développé par Anthropic pour des travaux avancés en cybersécurité.

Les rapports sont entièrement générés par le modèle. Anthropic ne promet pas qu’un chercheur en sécurité vérifiera un signalement avant qu’il ne parvienne au projet. L’entreprise avertit explicitement que les rapports peuvent être erronés ou non valides.

Chaque rapport est conçu pour inclure plus qu’un emplacement de code suspect. Anthropic indique fournir une explication, des instructions de reproduction et un correctif candidat lorsqu’il est disponible. Un rapport peut également inclure une analyse de l’historique du code indiquant quand le défaut présumé est apparu.

Ces éléments sont importants, car les mainteneurs ont besoin d’une méthode reproductible pour distinguer une vulnérabilité réelle d’un résultat de modèle apparemment plausible. Un scénario de reproduction concret permet à un ingénieur d’exécuter le code concerné et d’observer si le comportement signalé se produit réellement.

Un correctif candidat peut raccourcir l’étape suivante. Il ne supprime pas la nécessité d’une revue, de tests, de vérifications de compatibilité et d’une coordination avec les acteurs en aval. Les correctifs de sécurité modifient parfois des comportements sur lesquels les utilisateurs ou les logiciels dépendants s’appuient discrètement.

Anthropic a testé le pipeline avec des dizaines de projets open source avant d’élargir l’accès à l’inscription. Selon l’entreprise, ces premières analyses ont produit des centaines de rapports. Anthropic affirme que plusieurs résultats pouvaient être combinés pour former des exploits d’exécution de code à distance non authentifiée.

Il s’agit d’une catégorie grave de vulnérabilité, car un attaquant peut potentiellement exécuter du code sans avoir à se connecter d’abord au système affecté. Toutefois, Anthropic n’a pas publié d’évaluation indépendante complète de ces premiers résultats.

Le lancement étend un travail qu’Anthropic réalisait auparavant dans le cadre d’un programme coordonné de divulgation de vulnérabilités. Dans ce processus, des chercheurs en sécurité examinaient les résultats avant d’en informer les mainteneurs. La divulgation publique suivait généralement un calendrier défini.

OSS Scanner crée une voie rapide distincte. Ses résultats automatisés sont envoyés par e-mail, de manière privée, aux mainteneurs, et Anthropic indique qu’elle ne les publiera pas automatiquement selon son délai de divulgation habituel.

Si Anthropic valide ultérieurement un résultat par l’intermédiaire de son programme avec revue humaine, ce rapport peut intégrer le processus de divulgation existant de l’entreprise. D’ici là, le rapport automatisé reste une soumission privée non vérifiée.

Cette distinction est essentielle. Anthropic ne propose pas une certification attestant que le logiciel inscrit est sécurisé. Elle propose une source supplémentaire d’hypothèses de vulnérabilités, étayées par des preuves reproductibles lorsque le système y parvient.

Les chiffres expliquent pourquoi Anthropic a changé son processus

Le service existe parce que les modèles d’Anthropic peuvent générer des résultats candidats bien plus vite que ses chercheurs ne peuvent les valider.

Anthropic indique avoir découvert plus de 29 000 vulnérabilités candidates en analysant des projets logiciels importants au cours des six mois précédents. Ses chercheurs ont examiné manuellement environ 6 000 rapports durant cette période.

Cela laisse plus de 23 000 résultats candidats en dehors du processus de revue humaine achevé. Certains représenteront de véritables problèmes de sécurité. D’autres seront des doublons, des malentendus, des défauts à faible impact ou des conclusions de modèle incorrectes.

Anthropic indique également que les mainteneurs demandaient de plus en plus un accès en masse à ses résultats non vérifiés. L’entreprise affirme avoir envoyé près de 5 000 résultats non validés aux projets ayant demandé à recevoir tout ce qui était disponible.

Ces chiffres expliquent la logique opérationnelle d’Anthropic OSS Scanner. Continuer à exiger une revue manuelle limiterait le nombre de dépôts qu’Anthropic pourrait couvrir. Supprimer cette exigence accroît simultanément la couverture, la fréquence et l’incertitude.

L’entreprise relie ce changement à l’amélioration des performances des modèles. Anthropic affirme que les modèles de langage détectaient moins de 20 % des vulnérabilités dans le benchmark CyberGym au début de 2025. Elle indique que ce résultat a dépassé 85 % en 2026.

Un benchmark est un jeu de tests standardisé, et non une garantie de performance en conditions réelles. Les dépôts réels comportent des systèmes de compilation inhabituels, des hypothèses non documentées, du code généré et des frontières de sécurité propres à chaque projet.

Un modèle peut également identifier un véritable défaut logiciel sans évaluer correctement son impact sur la sécurité. Une lecture hors limites dans un utilitaire de test inaccessible présente un risque différent de celui d’une lecture exposée via un service réseau.

Les propres chiffres d’Anthropic révèlent une seconde contrainte. Identifier des problèmes candidats n’est plus la seule ressource rare. La vérification, la priorisation, la correction et la divulgation deviennent les parties les plus difficiles du flux de travail.

Cette transition exerce une pression sur les projets dépourvus d’équipes de sécurité dédiées. Une importante bibliothèque d’infrastructure peut dépendre d’un petit groupe de mainteneurs qui gèrent déjà les demandes de fonctionnalités, les régressions, les problèmes de packaging et le soutien à la communauté.

Même un rapport bien structuré mobilise de l’attention. Quelqu’un doit reproduire le comportement, confirmer les versions affectées, évaluer l’exploitabilité, concevoir un correctif sûr et coordonner les publications.

Les équipes de sécurité utilisent depuis longtemps l’analyse statique, le fuzzing et l’analyse des dépendances afin d’identifier des comportements suspects. Le fuzzing injecte des entrées inattendues dans un logiciel pour révéler des plantages ou d’autres défaillances.

L’analyse des vulnérabilités par l’IA ajoute une couche de raisonnement. Un modèle peut examiner les relations entre les fonctions, déduire le comportement prévu, inspecter l’historique des versions et construire un test ciblé.

Anthropic affirme que ses modèles ont parfois suivi de nouvelles pistes d’investigation après que les techniques conventionnelles n’avaient rien trouvé. Des recherches antérieures incluaient l’examen de l’historique du contrôle de source et l’écriture de programmes de preuve de concept pour des vulnérabilités présumées.

Ce raisonnement plus large peut révéler des défauts que les outils fondés sur des motifs ne détectent pas. Il peut aussi produire un récit convaincant mais erroné. La qualité des preuves associées importe donc davantage que la fluidité de l’explication.

Les mainteneurs open source deviennent la dernière couche de vérification

Le service gratuit d’Anthropic éloigne des mainteneurs le coût élevé du calcul des modèles, mais il ne supprime pas le coût humain du triage de sécurité.

Les mainteneurs principaux doivent s’inscrire via le dépôt d’inscription du projet. Ils soumettent une pull request contenant des détails de configuration et des instructions pour compiler le logiciel.

Chaque projet fournit une adresse de dépôt, un contact principal pour la sécurité et un Dockerfile. Un Dockerfile décrit l’environnement et les commandes nécessaires pour compiler le projet dans un conteneur.

Les projets peuvent aussi fournir un modèle de menace. Ce document explique quels actifs sont importants, où les données non fiables entrent et comment les mainteneurs classent la gravité.

Ce contexte peut éviter des malentendus évidents. Un scanner pourrait autrement considérer un comportement délibéré comme une vulnérabilité ou exagérer l’importance d’un code qui ne traite jamais d’entrées non fiables.

Anthropic compile les projets participants dans des machines virtuelles isolées. La configuration peut utiliser l’accès réseau pour récupérer les dépendances requises. L’analyse de sécurité proprement dite s’exécute sans accès à Internet dans des environnements isolés renforcés.

Les résultats sont ensuite envoyés par e-mail aux contacts désignés du projet. Les mainteneurs peuvent demander une livraison chiffrée en publiant une clé OpenPGP avec leur configuration d’inscription.

Le service est limité aux projets open source admissibles. Anthropic indique que les critères d’éligibilité ressemblent à ceux employés par le programme OSS-Fuzz de Google. Les projets doivent avoir un impact critique sur l’infrastructure ou la sécurité des utilisateurs.

Cette norme différencie OSS Scanner d’un outil public que n’importe qui pourrait diriger vers n’importe quel dépôt. Anthropic contrôle les inscriptions et prend en charge le coût de calcul des modèles pour les projets acceptés.

L’entreprise applique également des méthodes d’analyse plus expérimentales et plus intensives en tokens que celles qu’elle utilise dans son produit commercial de sécurité général. Ce choix positionne le service open source comme un terrain d’essai pour des audits plus approfondis.

Les mainteneurs gardent le contrôle après l’inscription. Ils peuvent modifier leur configuration, mettre à jour les instructions de compilation, suspendre l’analyse ou retirer le projet par le biais d’une autre pull request.

Ils décident également quoi faire de chaque résultat. Anthropic ne crée pas automatiquement de ticket public, n’attribue pas d’identifiant de vulnérabilité et n’impose pas de calendrier de divulgation aux résultats automatisés bruts.

Cette approche réduit le risque qu’un rapport incorrect accuse publiquement un projet de livrer une faille exploitable. Elle évite aussi d’exposer des détails techniques avant que les mainteneurs aient évalué un correctif.

Toutefois, la livraison privée ne résout pas les contraintes de capacité. Un petit projet peut toujours recevoir davantage de rapports crédibles que ses bénévoles ne peuvent en traiter. Anthropic n’a pas annoncé de plafond universel pour le volume de rapports.

Les projets auront besoin de leurs propres règles de traitement. Un flux de travail pratique devrait distinguer les problèmes reproductibles et accessibles de l’extérieur des plantages nécessitant des conditions irréalistes.

Les équipes ont aussi besoin de dossiers techniques pérennes. Une base de connaissances d’ingénierie consultable peut préserver les étapes de reproduction, les versions affectées, les décisions relatives aux correctifs et les tâches de suivi.

Cette documentation devient importante lorsque plusieurs rapports partagent une cause racine. Sans elle, différents mainteneurs peuvent répéter la même enquête ou appliquer des correctifs incohérents selon les branches.

L’analyse des vulnérabilités par l’IA est désormais confrontée à un test de précision

La question centrale n’est plus de savoir si un modèle d’IA peut trouver des vulnérabilités, mais s’il peut fournir suffisamment de signaux vérifiés pour justifier l’attention des mainteneurs.

Les preuves initiales les plus solides d’Anthropic proviennent des projets qui ont testé le système. Noah Misch, contributeur à PostgreSQL, a déclaré que plusieurs rapports avaient identifié des défauts et inclus des correctifs presque exploitables tels quels.

OpenSSL Corporation’s Anton Arapov a comparé favorablement les résultats bruts aux rapports humains. Il a souligné l’intérêt de recevoir un exploit fonctionnel, car les ingénieurs peuvent le tester directement.

Le résultat rapporté le plus précis provenait de wolfSSL. Le projet a reçu 74 signalements et en a considéré tous sauf deux comme valides, selon des retours publiés par Anthropic. Cinq signalements sont devenus des entrées Common Vulnerabilities and Exposures, communément appelées CVE.

Ce résultat suggère une grande précision dans le cadre d’un premier déploiement. Il n’établit pas le même taux pour tous les langages de programmation, types de projets, configurations de compilation et modèles de menace.

L’échantillon provient également des propres documents de lancement d’Anthropic. L’entreprise n’a pas publié de jeu de données complet présentant tous les rapports acceptés, rejetés, dupliqués et contestés de son pilote.

Une mesure indépendante exigera davantage que le simple comptage des rapports. Les chercheurs devront examiner la validité, la gravité, les doublons, le temps nécessaire à la reproduction, le délai de correction et le nombre de régressions provoquées par les correctifs suggérés.

L’effort demandé aux mainteneurs constitue une autre mesure importante. Un scanner qui détecte davantage de défauts réels peut tout de même représenter une charge nette si chaque rapport valide est noyé parmi de nombreux faux positifs convaincants.

Ce risque n’est pas théorique. D’autres communautés open source ont connu une hausse de soumissions automatisées de vulnérabilités ne fournissant pas de preuves suffisantes.

Google a indiqué avoir suspendu une partie de son Open Source Software Vulnerability Rewards Program après une forte augmentation des rapports automatisés. Selon l’explication de l’entreprise, la plupart de ces soumissions étaient invalides.

Le projet curl a mis fin à son programme de bug bounty en janvier 2026. Ses mainteneurs avaient averti à plusieurs reprises que les rapports générés par IA consommaient du temps sans apporter de valeur de sécurité équivalente.

Les mainteneurs de Linux ont également décrit les rapports automatisés en double comme difficiles à gérer. Plusieurs personnes peuvent exécuter des outils similaires, détecter le même motif douteux et envoyer indépendamment des soumissions presque identiques.

La conception sur inscription volontaire d’Anthropic traite une partie de ce problème. Seuls les mainteneurs autorisés inscrivent un projet, et les rapports sont directement envoyés aux contacts désignés. Aucune récompense financière n’encourage des tiers à maximiser le volume de soumissions.

L’exigence d’un reproducer relève également le niveau de preuve attendu. Un rapport qui montre un comportement observable est plus utile qu’un rapport qui se contente d’étiqueter un motif de code comme dangereux.

Toutefois, un reproducer peut démontrer un plantage sans prouver l’existence d’un chemin d’attaque significatif. Il peut aussi dépendre d’une option de compilation artificielle ou d’une configuration que les utilisateurs réels ne déploient jamais.

Les correctifs proposés constituent une autre source d’incertitude. Un correctif peut faire taire un test tout en laissant la vulnérabilité sous-jacente intacte. Il peut aussi introduire un autre bug ou rompre la compatibilité en aval.

Les premiers résultats justifient une attention prudente, pas une confiance automatique. Anthropic OSS Scanner doit prouver que ses résultats restent utiles une fois l’inscription étendue au-delà de projets pilotes coopératifs.

OSS Scanner complète les outils de sécurité existants

Anthropic positionne son scanner comme un système de découverte supplémentaire, et non comme un remplacement des fuzzers, des bases de données de dépendances, de la revue de code ou de la divulgation coordonnée.

La comparaison historique la plus évidente est le service OSS-Fuzz de Google, qui teste en continu d’importants projets open source au moyen d’une infrastructure de fuzzing.

OSS-Fuzz est efficace lorsque les outils peuvent générer des entrées qui sollicitent un comportement significatif du programme. Il est particulièrement utile pour les logiciels qui analysent des fichiers, des messages réseau ou d’autres données non fiables.

Cependant, le fuzzing dépend de harnais de test et de défaillances observables. Certaines erreurs d’autorisation, failles de logique métier et chaînes d’attaque en plusieurs étapes ne provoquent pas de plantage immédiat.

Les grands modèles de langage peuvent raisonner sur ces relations. Ils peuvent suivre les données à travers différents composants, prendre en compte le modèle de sécurité déclaré d’un projet et générer des expériences ciblées.

L’analyse statique traditionnelle offre un autre point de comparaison. Elle examine le code source sans exécuter le programme complet et applique des règles qui identifient des flux ou des motifs à risque.

Les analyseurs statiques sont reproductibles et peuvent s’exécuter à chaque modification logicielle. Leur utilité dépend de la qualité des règles, de la prise en charge des langages et de la capacité d’une équipe à gérer des avertissements récurrents.

L’analyse de composition logicielle se concentre sur les paquets inclus et les vulnérabilités connues. Elle peut indiquer à une équipe qu’une dépendance correspond à une version affectée, mais elle ne découvre généralement pas un défaut jusque-là inconnu.

Le service d’Anthropic cible des vulnérabilités inconnues présentes dans le code source. Ses modèles ne se limitent pas à comparer un dépôt avec un catalogue de vulnérabilités existant.

La revue humaine reste nécessaire dans toutes ces approches. Les ingénieurs en sécurité comprennent le contexte de déploiement, les motivations des attaquants, les exigences de compatibilité et les conséquences qui dépassent l’environnement de test immédiat d’un scanner.

Les outils peuvent aussi se renforcer mutuellement. Une hypothèse générée par IA peut devenir une cible de fuzzing. Le plantage détecté par un fuzzer peut fournir à un modèle des preuves concrètes pour l’analyse de la cause racine.

Un modèle peut proposer un correctif, tandis que l’analyse statique et les tests de régression examinent cette modification à la recherche de nouveaux problèmes. L’analyse des dépendances peut ensuite identifier les produits en aval nécessitant une version mise à jour.

La politique de divulgation standard d’Anthropic reste pertinente lorsque ses chercheurs valident un problème. Cette politique vise généralement une notification suivie d’une divulgation après 90 jours ou dès la publication d’un correctif.

La politique prévoit des délais plus courts pour les vulnérabilités critiques activement exploitées. Elle décrit également des prolongations pour les mainteneurs qui progressent vers une correction.

Les rapports bruts d’OSS Scanner ne relèvent pas de ce calendrier automatique. Anthropic indique qu’il ne les publiera pas, sauf s’ils intègrent ultérieurement un processus de revue humaine.

Cette séparation laisse aux mainteneurs le temps d’enquêter. Elle soulève aussi une question de gouvernance sans réponse concernant les résultats qui restent non résolus pendant de longues périodes.

Anthropic indique qu’il pourrait éventuellement introduire des périodes de divulgation pour certains résultats automatisés de haute gravité. L’entreprise promet un préavis et la possibilité pour les projets de quitter le service si cette politique évolue.

Pour l’instant, l’offre privilégie un accès défensif privé plutôt qu’une responsabilité publique. C’est une position de lancement raisonnable, mais elle repose largement sur la réaction responsable des mainteneurs participants.

Ce qui déterminera l’efficacité du service

Trois signaux montreront si Anthropic OSS Scanner devient une infrastructure de sécurité utile ou une autre source exigeante de rapports automatisés.

Le premier signal sera l’expérience des projets nouvellement inscrits. Les retours du pilote d’Anthropic provenaient d’équipes établies, disposant d’une solide expertise technique et de processus de sécurité matures.

Une inscription plus large mettra le scanner à l’épreuve face à différents langages, architectures et modèles de maintenance. Les résultats devraient montrer si sa précision initiale se transpose au-delà d’un groupe sélectionné.

Les correctifs documentés publiquement apporteront des preuves utiles. Les références de commits, les entrées CVE et les rétrospectives de mainteneurs peuvent montrer quels rapports ont produit des améliorations significatives de la sécurité.

L’attribution est facultative, mais Anthropic encourage les projets à inclure un identifiant de rapport du scanner dans les commits concernés. Ces identifiants peuvent aider l’entreprise à mesurer quels résultats ont conduit à des correctifs.

Le deuxième signal sera la qualité des rapports au fil du temps. Anthropic devrait à terme publier des données agrégées sur la précision, les doublons, la gravité et la remédiation, sans exposer les vulnérabilités non résolues.

La mesure la plus informative ne sera pas le nombre total de résultats candidats. Ce sera la proportion que les mainteneurs reproduisent, acceptent et corrigent sans enquête excessive.

Une baisse du taux de faux positifs renforcerait l’argument d’Anthropic selon lequel les modèles de langage ont franchi un seuil important d’utilité. Une hausse des coûts de triage l’affaiblirait.

Le troisième signal sera la réaction des autres programmes de sécurité. Google prévoit de réexaminer son processus suspendu de récompenses open source après avoir traité les soumissions automatisées invalides.

Un déploiement réussi d’Anthropic pourrait influencer les normes de preuve utilisées par les programmes de bug bounty et de divulgation. Les reproducers et correctifs testables pourraient devenir attendus pour tout rapport généré par machine.

Un mauvais déploiement pourrait encourager des filtres plus stricts. Les mainteneurs pourraient rejeter par défaut les résultats automatisés, à moins qu’une organisation reconnue n’effectue une validation humaine.

Anthropic doit également surveiller l’adaptation des attaquants. Les mêmes capacités de modèle qui détectent des résultats défensifs peuvent aider des chercheurs malveillants à examiner des logiciels largement déployés.

L’entreprise affirme appliquer des contrôles d’accès et une surveillance autour des capacités cyber avancées. OSS Scanner limite davantage l’exposition en s’exécutant dans des environnements isolés et en transmettant les résultats de manière privée.

Ces mesures ne peuvent pas éliminer la course plus large. Les modèles continueront de s’améliorer, et des capacités similaires se répandront parmi les fournisseurs, les entreprises de sécurité et les systèmes locaux.

La vitesse de remédiation devient donc de plus en plus importante. Détecter une vulnérabilité en premier offre peu de protection si un projet ne peut pas reproduire, corriger, tester et diffuser le correctif avant que des attaquants ne l’exploitent.

Les mainteneurs open source devraient évaluer le service comme une source supplémentaire d’informations de sécurité, et non comme un verdict sur leur code. Les projets éligibles peuvent examiner les exigences d’inscription et décider s’ils disposent d’une capacité de triage suffisante.

La meilleure question n’est pas de savoir si un scanner IA commet parfois des erreurs. Chaque technique de sécurité a ses limites. La question est de savoir si les rapports d’Anthropic font gagner plus de temps d’ingénierie qu’ils n’en consomment.

Anthropic OSS Scanner doit désormais établir cet équilibre publiquement. Les résultats obtenus par les mainteneurs au cours des prochains mois compteront davantage que le volume de vulnérabilités que ses modèles prétendent détecter.