OSS Scanner : une inspection de sécurité gratuite pour l'open source critique

Pensez à un bâtiment dont tout le quartier dépend : le vieux pont, le château d’eau, l’immeuble au-dessus de la boulangerie. Quelqu’un propose une inspection gratuite et régulière, avec une fiche par fissure : où elle se trouve, pourquoi elle est apparue, et un croquis de la réparation. Une seule condition : l’inspecteur est une machine, et personne ne relit ses notes avant vous.

C’est, en gros, ce qu’Anthropic a ouvert le 8 octobre 2026 sous le nom d’OSS Scanner. Voici ce que c’est, à qui cela s’adresse, et comment s’en servir sans se noyer sous les rapports.

L’idée en une phrase

OSS Scanner est un service gratuit, sur inscription volontaire, dans lequel Anthropic analyse régulièrement des projets open source critiques avec ses modèles les plus puissants et envoie par e-mail aux mainteneurs ce qu’il trouve, chaque rapport accompagné d’un reproducteur et, si possible, d’un correctif proposé, sans relecture humaine avant l’envoi.

Ce que fait le programme

Le scanner compile le projet à partir de votre Dockerfile dans une machine virtuelle isolée, puis coupe Internet et lance l’analyse dans un bac à sable renforcé. D’après la page du service, des agents revérifient les bugs, proposent des correctifs et analysent les causes profondes, avec plusieurs harnais, parfois coûteux ou expérimentaux, pour atteindre des bugs plus enfouis. Les analyses se répètent dans le temps pour attraper les failles nouvellement introduites et celles qui avaient échappé ; la fréquence n’est pas fixe et dépend de la charge et de l’usage du projet.

La page parle de « nos modèles les plus puissants » sans en nommer un pour ce service. Une partie de la presse cite Claude Mythos, mais je n’ai pas pu le confirmer sur les pages d’Anthropic, donc je ne l’affirme pas.

Ce que contient un rapport

Les rapports arrivent par e-mail sous forme de lot (le format peut évoluer), chacun avec un identifiant du type ANT-2026-ABCD1234 pour l’attribution. Selon les cas, un rapport peut comporter :

• Une preuve de concept (PoC). Un reproducteur : une entrée ou un petit script qui déclenche réellement le bug. C’est la différence entre « ça a l’air risqué » et « regardez, ça plante ».
• Une analyse de la cause profonde. Pourquoi le bug existe : un contrôle de bornes manquant, une hypothèse fausse sur la longueur d’une entrée. Corriger la cause plutôt que le symptôme ferme aussi la variante d’à côté.
• Un correctif suggéré. Une proposition de patch, minimale ou presque prête à fusionner selon ce que demande votre modèle de menace.
• Une note de gravité, selon la grille de votre projet si vous en fournissez une.

Qui peut participer

La barre ressemble à celle d’OSS-Fuzz de Google, le service gratuit de fuzzing lancé en 2016 après Heartbleed, qui accepte les projets ayant une base d’utilisateurs importante ou essentiels à l’infrastructure informatique mondiale. Anthropic parle de projets établis ayant un impact critique sur l’infrastructure et la sécurité des utilisateurs, examinés au cas par cas. Les critères cités, en clair :

• L’exposition aux attaques à distance. Le code qui traite des données venues du réseau ou d’inconnus (analyseurs, serveurs, bibliothèques de formats de fichiers) est la porte d’entrée d’un attaquant.
• Le nombre d’utilisateurs et de projets dépendants. Un bug dans une bibliothèque utilisée par des milliers de projets, c’est en pratique des milliers de bugs.
• L’âge et la fréquence des mises à jour. Un projet établi et actif peut agir sur un rapport ; un projet abandonné, non.
• Le score de criticité OpenSSF. Une note de 0 à 1 qui estime l’influence d’un projet, à partir de signaux comme l’âge, les contributeurs, la fréquence des commits, les versions publiées et les dépendants.
• Une licence open source couramment acceptée. Le service vise l’open source au sens habituel.
• Étoiles, forks et statistiques d’usage. Des signaux imparfaits, mais qui montrent la portée.
• La criticité du projet pour la sécurité, et pour quels secteurs. Une bibliothèque TLS pèse plus lourd qu’un thème de diaporama.
• La complétude des champs requis. Un dossier incomplet reste simplement en attente.

La liste n’est pas exhaustive ; si l’importance de votre projet ne saute pas aux yeux, expliquez brièvement pourquoi il compte pour la sécurité.

Qui en est généralement exclu

Les projets tout juste créés, et les forks, sauf s’ils se distinguent nettement de l’original. Le service vise aussi des équipes déjà capables de suivre des rapports vérifiés de gravité haute ou critique : si un flot de découvertes sérieuses vous paralyserait, c’est trop tôt. Enfin, la personne qui inscrit le projet doit en être le mainteneur principal ou être autorisée par lui, et par son employeur lorsqu’une organisation maintient le projet.

S’inscrire, étape par étape

1. Forkez anthropics/oss-scanner et créez, sous projects/, un dossier au nom de votre projet.

2. Ajoutez un project.yaml à partir du modèle. Seuls repo et primary_contact sont toujours obligatoires :

   repo: https://github.com/example/project
   primary_contact: security@example.org
   auto_ccs:
     - maintainer@example.org
   homepage: https://example.org
   disabled: false
   dockerfile: .oss-scanner/Dockerfile
   threat_model: .oss-scanner/threat_model.md
   output_format:
     email:
       min_severity: low
     github_security_advisory:
       min_severity: none

   Les adresses de ce fichier sont publiques : utilisez un alias sécurité plutôt qu’une boîte personnelle.

3. Fournissez un Dockerfile qui installe toutes les dépendances et compile le projet. La compilation a accès au réseau, l’audit non : récupérez d’avance tout ce dont la compilation et les tests ont besoin. Le garder dans votre propre dépôt est préférable, car vous pourrez le modifier sans nouvelle pull request.

4. Rédigez un threat_model.md (facultatif, vivement recommandé) : ce que fait le projet, où entrent les données non fiables, ce qui est hors périmètre, et comment vous notez la gravité.

5. Vérifiez en local avec tools/validate.py, puis tools/check suivi du nom du projet, qui construit l’image comme le scanner et ouvre un shell sans réseau. Si vos tests passent là-dedans, le scanner fonctionnera très probablement.

6. Ouvrez la pull request et acceptez les conditions. Une personne l’examine et vérifie que le contact est un vrai contact sécurité, par exemple celui indiqué dans votre SECURITY.md. L’éligibilité est revérifiée avant chaque envoi.

Pour faire une pause, passez disabled à true ; pour partir, supprimez votre dossier.

Ce que cela change pour les mainteneurs

L’avantage est évident : un audit de sécurité régulier que la plupart des projets bénévoles n’auraient jamais pu se payer, avec reproducteurs et correctifs, orienté par votre modèle de menace.

La charge de travail est tout aussi réelle, et les conditions la détaillent. Les rapports sont générés par IA et peuvent être « incomplets et inexacts » ; c’est à vous de relire chaque rapport et son correctif avant de modifier quoi que ce soit. Les rapports sont confidentiels jusqu’à la correction ou la divulgation publique du bug. Les découvertes non validées n’ont pas de délai public de 90 jours, et Anthropic dit qu’elle ne les publiera pas. Si une personne valide plus tard une découverte via le programme de divulgation d’Anthropic, elle pourra être rendue publique 90 jours après que vous en avez été notifié. Anthropic ajoute qu’elle pourrait, à l’avenir, fixer une période de divulgation pour certains rapports de haute gravité, avec préavis et possibilité de refus. Le service est fourni « en l’état », et la responsabilité d’Anthropic est plafonnée à 1 000 dollars.

Quelques réflexes de tri :

• Reproduire avant tout, dans un environnement jetable.
• Réévaluer la gravité selon votre propre grille, pas celle du modèle.
• Regrouper par cause profonde : cinq rapports peuvent décrire un seul bug.
• Relire le correctif comme la pull request d’un inconnu, et signaler les faux positifs.

Ce que cela change pour tous les autres

Si vous utilisez des logiciels, vous utilisez de l’open source : une inspection gratuite des fondations est donc une bonne nouvelle. Mais trouver n’est pas corriger. The New Stack l’a résumé dans un titre : Claude a trouvé 29 000 bugs possibles dans l’open source, et seuls 516 ont été corrigés. Le goulot d’étranglement se déplace de la découverte vers le temps des mainteneurs.

D’où la divulgation coordonnée : le mainteneur est prévenu en privé, corrige, et les détails ne deviennent publics qu’ensuite, pour que les attaquants n’apprennent pas la faille avant que les utilisateurs puissent la combler. Pour nous autres : tenir ses dépendances à jour, suivre les avis de sécurité, et soutenir les mainteneurs, en argent ou en temps de relecture.

Conclusion

OSS Scanner offre aux projets critiques ce qui était réservé aux équipes bien financées : un regard de sécurité régulier et approfondi, livré avec un reproducteur et une ébauche de correctif. Le prix ne se paie pas en argent mais en attention. Le modèle écrit le rapport ; il faut encore un humain pour le reproduire, le juger et publier le correctif.

Résumé indépendant, sans lien avec Anthropic. Les faits proviennent des sources listées ci-dessous.