Tech Teardown 024｜oss-scanner : Dépôt officiel de scan de vulnérabilités d'Anthropic, 960 étoiles en 5 jours, sans aucune ligne de code de scanner à l'intérieur

Le 8 octobre, l’account officiel d’Anthropic, anthropics, a créé un nouveau dépôt sur GitHub nommé oss-scanner. En cinq jours, il a reçu plus de 960 étoiles (snapshot du 10-14, avec 5 jours de dépôt). Le numéro du Pull Request est déjà #598. Sa popularité ne vient pas des discussions communautaires, mais de trois facteurs : les publications officielles, le fait que 76 projets open-source importants se sont enregistrés volontairement, et les témoignages des mainteneurs de PostgreSQL, OpenSSL, wolfSSL, curl, et HotCRP dans leurs publications. Plus intéressant encore, le dépôt lui-même : après avoir examiné 184 fichiers, on n’a trouvé aucune ligne contenant du code pour effectuer une vérification des vulnérabilités. Il s’agit d’un registre de services de scan, où le scanner reste sur le serveur d’Anthropic. Hier, anatomy a analysé la couche produit de l’écosystème agent ; aujourd’hui, cela concerne la couche sécuritaire. Deux articles consécutifs montrent comment les entreprises AI interviennent dans les infrastructures open-source. Ce texte se divise en six parties, comme d’habitude.

1. Qu’est-ce que c’est ?

Définissons d’abord le point clé : le dépôt oss-scanner n’est pas le code du scanner, mais un ensemble de trois éléments : registre, protocole de configuration et outil de vérification interne. Le corps du scanner fonctionne sur le côté du service et n’est pas open-source. La partie open-source répond à une autre question : comment un projet open-source se soumet à ce scanner et s’auto-verifie avant l’utilisation.

Le service est en réalité une vérification des vulnérabilités gratuite d’Anthropic pour les projets open-source clés, avec un système de consentement volontaire. Seuls les projets qui se déclarent volontairement sont vérifiés, et leur utilisation est soumise aux conditions de service publiées sur red.anthropic.com/oss-scanner. Les publications officielles sont très claires : l’inspiration vient de Google’s OSS-Fuzz, avec le fuzzer remplacé par le modèle linguistique le plus puissant (y compris Claude Mythos). Son prédécesseur était Project Glasswing, où Anthropic utilisait Claude pour trouver des vulnérabilités, ainsi que le processus CVD qui a déjà vérifié plus de 6000 rapports manuellement. La division entre les produits payants Claude Security et OSS Scanner est claire : OSS Scanner est gratuit pour les projets open-source, tandis que les clients professionnels utilisent une autre voie.

C’est pourquoi la forme du dépôt mérite une mention particulière : les entreprises AI construisent des infrastructures de sécurité open-source, mais ce qu’elles publient n’est pas des modèles ou des scanners, mais un protocole d’accès. Cela diffère complètement de la manière open-source traditionnelle des outils de sécurité où « le code est l’produit ». La transparence du registre signifie que celui qui est vérifié est visible, tandis que la confidentialité du scanner signifie que la manière de vérifier est secrète, la transparence étant divisée en deux parties.

2. Structure du dépôt

Le dépôt contient au total 184 fichiers (sans .git), dont 80 en YAML, 51 en MD et 4 en Python, sous licence Apache-2.0.

Le corps principal contient 76 dossiers de projets sous le répertoire projects/. Chaque dossier représente un fichier de registration. La liste est très complète : openssl, cpython, spidermonkey (le moteur JS de Firefox), nss (la bibliothèque de chiffrement de Mozilla), homebrew, drupal, grafana, rabbitmq, jupyterlab, nestjs, valkey (une branche de Redis), uutils-coreutils, lvm2, cryptsetup ; les outils de sécurité incluent nuclei, grype, syft, zmap, radare2, ossec-hids, go-tuf, tinyssh, botan ; plusieurs projets AI sont également présents, comme unsloth, autogpt, goose, y compris le modèle claude-code-templates de Anthropic. Notez que curl n’est pas sur la liste, mais il y a une déclaration du mainteneur de curl, Daniel Stenberg, dans les textes publiés.

Le noyau de chaque fichier est project.yaml, avec deux champs obligatoires : repo (adresse du dépôt git, possiblement verrouillée par #branch) et primary_contact (l’adresse e-mail pour recevoir les rapports). Les champs optionnels incluent dockerfile, threat_model, auto_ccs, pgp, disabled, homepage. Le exemple de openssl est représentatif : repo pointant vers openssl/openssl et verrouillant master, primary_contact utilisant le groupe de messagerie openssl-security@ plutôt qu’une adresse personnelle, ce qui illustre bien la règle soulignée dans le README : « L’adresse e-mail sera publique, veuillez utiliser l’alias security ».

Le code des outils est concentré dans tools/, avec environ 1287 lignes de Python et 142 lignes de shell : validate.py avec 261 lignes pour vérifier les règles de configuration, check_build.py et check_qemu.py pour le contrôle de la construction locale. templates/ contient les modèles de configuration. L’attitude des dépôts envers les contributions est également indiquée à la fin du README : seules les modifications dans projects/ sont acceptées, pas celles dans tools ou templates. 598 PR numérotés en cinq jours, presque tous en attente d’être traités.

III. Analyse du mécanisme

Le processus global du service se déroule en quatre étapes : construction, coupure réseau, scan et envoi de courrier électronique. Les projets fournissent un Dockerfile (placer dans leur propre dépôt ou dans le dossier de registration, choisir l’un ou l’autre, la première option étant préférable car elle évite les PR pour la modification de la construction), le scanneur construit le projet dans une VM isolée. Pendant la phase initiale de construction, le réseau est disponible, mais après entrée dans la phase d’audit de sécurité, le réseau est complètement coupé. Les résultats du scan sont envoyés par courrier électronique à primary_contact. Chaque rapport contient trois éléments : un reproducer auto-contained, une explication des vulnérabilités (y compris le moment où les vulnérabilités ont été introduites via bisection), ainsi qu’un patch candidat.

Le rapport est divisé en deux canaux. Le premier est le canal CVD, qui nécessite une vérification manuelle ; le second est le fast track, où le rapport est généré pour l’ensemble du modèle sans vérification manuelle et est envoyé immédiatement après l’analyse. Selon des informations publiées, près de 5000 rapports de fast track non vérifiés ont été directement envoyés aux contributeurs qui ont demandé le rapport complet (selon les déclarations d’Anthropic). Le design à deux canaux considère la « capacité de vérification » comme une ressource rare à distribuer : ceux qui nécessitent une vérification manuelle doivent faire la queue, tandis que ceux qui peuvent attendre reçoivent d’abord le rapport.

La phase d’audit en cas de coupure de réseau est également importante. La mise en place du réseau pendant la phase de construction permet de créer des dépendances, tandis que l’audit en cas de coupure de réseau empêche les modèles de se connecter à l’extérieur pendant l’analyse : cela évite non seulement que le code du projet ou les détails des vulnérabilités ne soient divulgués lors du scan de l’environnement, mais aussi que les modèles ne téléchargent eux-mêmes des éléments pour perturber l’analyse. tools/check reproduit fidèlement cet environnement, ce qui est la valeur de cet outil de contrôle interne : ce que vous voyez localement correspond aux services fournis.

Le contrôle interne local avant l’enregistrement est la partie la plus pratique du repository. tools/validate.py transforme les règles d’enregistrement mentionnées dans le README en code : liste blanche des champs, vérification HTTPS, format de l’adresse e-mail, format de la clé PGP, limite de taille des fichiers, et il bloque également des champs tels que workflow, budget et cadence, qui ne peuvent être configurés que par le service d’exploitation. tools/check <nom> construit le projet selon la même méthode que le scanneur, ouvre un shell dans l’image de l’image finie coupée du réseau, et teste si le scanneur peut fonctionner dans ce conteneur ; la variante —qemu reproduit la disposition de l’VM du scanneur avec QEMU sur x86-64 Linux. Le document string de validate.py contient également une confession honnête : il ne partage pas de code avec le scanneur côté service, et les modifications des règles doivent être synchronisées des deux côtés.

Quatrièmement, chiffres et vérification

Regardons d’abord les chiffres clés rapportés par Anthropic, qui sont tous basés sur ses propres déclarations. Au cours des 6 derniers mois, avec le modèle le plus récent, des vulnérabilités ont été détectées dans les principaux projets logiciels mondiaux, pour plus de 29 000 cas, dont environ 6 000 ont été vérifiés manuellement. Anthropic reconnaît que le problème réside dans la capacité à vérifier plutôt que dans les modèles eux-mêmes. Sur le benchmark académique CyberGym, le taux de détection des vulnérabilités des LLM est passé de moins de 20% au début de l’année dernière à plus de 85% cette année.

L’expérimentation de vérification est la partie la plus difficile des chiffres : Anthropic a engagé des experts en tests d’intrusion familiarisés avec le processus CVD pour vérifier les 97 vulnérabilités critiques/hautes signalées par le scanneur dans 48 projets, dont 85 (88%) ont réussi à respecter les normes CVD ; parmi les 12 restants, 11 étaient réellement présentes mais constituaient des rapports répétitifs, et seulement 1 était un faux positif réel (selon les déclarations d’Anthropic).

L’administration n’a pas non plus évité les faiblesses : certains contributeurs ont signalé que les scores de gravité pourraient être exagérés, et que le scanneur pourrait mal interpréter la vulnérabilité du projet.

Les témoignages des maintaineurs proviennent d’une publication d’Anthropic, présentés comme suit. Noah Misch de PostgreSQL a déclaré que le taux élevé d’anomalies constatées était en réalité des failles réelles, et que les corrections apportées dans de nombreux rapports pouvaient être utilisées directement. Anton Arapov de l’OpenSSL Corporation a comparé que les rapports de vulnérabilités liées à l’IA datant de 18 mois étaient déplorables, tandis que ceux-ci étaient à la hauteur ou même supérieurs aux rapports humains. Les rapports contenant des exploit réels rendaient les ingénieurs soulagés. Todd Ouska de wolfSSL a indiqué que sur 74 rapports, seulement 2 étaient invalides et 5 constituaient des CVE. Daniel Stenberg de curl a mentionné que l’une des plus graves vulnérabilités de curl récemment découvertes était d’ordre cette catégorie. Eddie Kohler de HotCRP figure également sur la liste des témoins. Tous ces témoignages proviennent de la publication d’Anthropic et sont des récits unilatéraux ; il convient donc de les considérer avec prudence.

V. Analyse

Trois points méritent attention.

Premièrement, une double violation de la politique de divulgation. Le README indique clairement que les rapports sont générés par le modèle et non vérifiés manuellement, donc aucun délai de 90 jours pour leur divulgation n’est prévu, et ils ne sont pas publics. Les deux piliers de la tradition de divulgation des vulnérabilités ont été brisés. Il y a une raison technique à cela : les rapports ne sont pas vérifiés, et respecter un délai de 90 jours oblige les maintaineurs à compter le temps sur des faux positifs ; en ne les publiant pas, on évite que des informations non vérifiées tombent entre les mains des attaquants. Mais le prix à payer est que le monde extérieur ne peut jamais vérifier ce que le système rapporte et ce qu’il omet, et que seulement Anthropic peut calculer son propre taux de réussite à 88 %.

Deuxièmement, le coût du triage est transféré aux maintaineurs. Le fait que les services soient gratuits est vrai, mais le README indique clairement que les rapports ne sont pas vérifiés manuellement, et que les services s’adressent à des projets capables de gérer des rapports de vulnérabilités graves. Pour des géants comme OpenSSL et PostgreSQL, qui disposent de teams de sécurité spécialisés, c’est un bénéfice net ; pour les projets manquant de personnel, près de 5000 rapports non vérifiés directement envoyés pourrait être une charge nette. Les 76 projets enregistrés sont tous des projets lourds, et cette liste constitue la preuve de la portée du service. Ce n’est pas une accusation, c’est une limite de service : il s’agit de sélectionner les projets capables de répondre à des problèmes de sécurité, ce qui exclut ceux qui ont le plus besoin d’aide extérieure en matière de sécurité.

Troisièmement, une divergence dans la mise en œuvre de la vérification des configurations. validate.py ne partage pas le code avec le scanner côté service, et les règles doivent être synchronisées manuellement des deux côtés. Cela est un signe clair de problèmes techniques dans la gestion des projets ; plus le projet est grand, plus il y a de risques de tomber dans une situation où « la vérification locale réussit mais l’importation côté service échoue ». Avec 76 projets et 598 PRs, chaque modification de cette règle nécessite deux synchronisations manuelles des codes.

En général, ce repository représente une nouvelle forme : les entreprises de IA font de la capacité de sécurité un service, et ce qu’elles open-sourcent, c’est seulement les protocoles d’accès et les registres. Le protocole est ouvert, mais les capacités sont fermées. Comparé au modèle précédent où « toute l’infrastructure était open-source », avec OSS-Fuzz, la transparence cède la place à la vitesse d’iteration. Pour les maintaineurs, la valeur de cet échange dépend de leur croyance dans le taux de réussite de 88 %, ainsi que du nombre de ressources disponibles dans leur file de sécurité.

VI. Comment utiliser

Les barrières de qualification sont élevées : il est nécessaire d’avoir le statut de mainteneur principal, ainsi que d’effectuer une vérification de qualité à la manière de OSS-Fuzz, pour déterminer si le projet traite des entrées peu fiables et si le nombre de utilisateurs en aval est suffisant. Le processus est simple : ouvrir un PR, ajouter un dossier projects/<nom>/, y placer le project.yaml et Dockerfile (ou une référence au chemin dans votre propre répertoire), puis après la fusion, l’analyseur importe automatiquement les fichiers.

Deux suggestions pratiques. Premièrement, bien que threat_model.md ne soit pas obligatoire, il est fortement recommandé de le rédiger. La bonne pratique indiquée dans le README consiste à préciser clairement le niveau de gravité : déterminer si une injection SQL après l’authentification est considérée comme « haute » ou « critique », si les fuites de buffer sans démonstration d’exploit ne sont pas classées comme « haute », et dans quelles conditions un XSS de type stockage doit être mis à jour. Ces points correspondent aux faiblesses reconnues officiellement du niveau de gravité exagéré. Deuxièmement, avant de vous enregistrer, exécutez les scripts tools/validate.py et tools/check. Notez que check exécute le Dockerfile du projet en ligne réseau. Il est conseillé de prévenir soi-même dans le README uniquement les projets que vous confiez, ou utiliser un ordinateur sans perte significative. Pour éviter la divulgation des rapports, vous pouvez les chiffrer avec PGP, mais après chiffrage, ne communiquez les rapports qu’à primary_contact, et ne les utilisez pas avec auto_ccs. Si vous souhaitez suspendre le projet sans effacer les données, définissez disabled sur true.

Pour les développeurs ordinaires, ce répertoire est avant tout un manuel : 76 exemples de configuration de contacts de sécurité en project.yaml, et les 261 lignes de validate.py sont des exemples parfaits de « écrire les règles du document en formateurs de vérification ».

Sources d’information

• Répertoire et documentation : README de github.com/anthropics/oss-scanner, tools/validate.py, liste des dossiers projects et configuration d’exemple avec openssl (snapshots locaux 10-14, nombre de fichiers et lignes de code calculé par find+wc)
• Nombre de stars, numéros de PR, nombre de projets : page GitHub et API, snapshots 10-14 (création du répertoire le 2026-10-08)
• Chiffres clés (29 000/6 000/près de 5 000/88% de 97, 1 faux positif/CyberGym taux de détection) : article publié sur anthropic.com « Launching an opt-in vulnerability-finding service for open-source software » (2026-10-08), tous données rapportées par Anthropic, avec des annotations dans le texte
• Testimonial des mainteneurs (PostgreSQL/OpenSSL/wolfSSL/curl/HotCRP) : testimonial des mainteneurs publié par Anthropic, texte transmis tel quel
• Politique de divulgation, règles d’enregistrement, utilisation des outils de vérification : texte original du README