Fonctionnement
D’un lien vers un dépôt à des vulnérabilités confirmées
Le processus reprend celui décrit par Anthropic pour son Anthropic OSS Scanner — modèle de menace, audit, double vérification, cause racine, correctif — et s’appuie sur les modèles Claude de pointe accessibles via une API publique.
- 1
Clonage sécurisé
Nous récupérons la branche demandée avec un clonage git superficiel, avec filtrage des blobs, via HTTPS. Les hooks Git sont désactivés, les liens symboliques sont extraits sous forme de fichiers ordinaires et tout transport autre que HTTPS est refusé. Les adresses de réseaux privés sont bloquées : le scanner ne peut donc pas être dirigé vers des hôtes internes.
Le contenu du dépôt n’est jamais exécuté : aucune compilation, aucune installation de paquets, aucun test. La copie extraite est supprimée à la fin de l’analyse.
- 2
Inventaire et classement des risques
Chaque fichier source texte est répertorié avec son langage et sa taille. Le code tiers intégré, les fichiers générés, les bundles minifiés et les fichiers de verrouillage sont ignorés. Chaque fichier reçoit un score de risque fondé sur les opérations dangereuses — copies mémoire, exécution de commandes shell, désérialisation, construction de requêtes SQL, rendu de templates, concaténation de chemins, code cryptographique et d’authentification — ainsi que sur les chemins critiques comme les parseurs, les gestionnaires de protocoles et le routage des requêtes.
- 3
Modèle de menace
Si le dépôt contient .oss-scanner/threat_model.md (le même fichier que lit le scanner d’Anthropic), SECURITY.md ou un modèle de menace fourni lors de l’inscription, le scanner le suit. Sinon, un modèle lit le README, l’arborescence des répertoires et les fichiers les plus risqués, puis en rédige un : ce qu’est le projet, où les données non fiables entrent et ce qui est hors périmètre.
Le modèle de menace sélectionne aussi les fichiers à examiner en priorité, afin que l’audit concentre ses ressources sur le code réellement accessible à un attaquant.
- 4
Audit
Les fichiers les plus risqués sont regroupés en lots volumineux avec leurs numéros de ligne, puis transmis à un modèle de raisonnement auquel le modèle de menace est joint. Il recherche les problèmes qu’un auditeur humain consciencieux signalerait :
- sécurité mémoire : débordements, utilisation après libération, troncature d’entiers
- injections : SQL, commandes, modèles, traversée de chemins, SSRF
- logique d’authentification, d’autorisation et de gestion des sessions
- désérialisation non sécurisée et confusion de l’analyseur syntaxique
- mauvaise utilisation de la cryptographie et gestion des secrets
Les analyses rapides utilisent Claude Haiku avec un budget modéré. Les analyses approfondies des projets inscrits utilisent Claude Sonnet et lisent jusqu’à quatre fois plus de code.
- 5
Vérification indépendante
Chaque vulnérabilité potentielle est soumise à un agent de vérification distinct, avec un contexte vierge. Son rôle est de réfuter la vulnérabilité : retracer le flux de données, rechercher d’éventuelles validations ailleurs et vérifier si l’entrée est réellement contrôlée par un attaquant au regard du modèle de menace. Seules les vulnérabilités qu’il confirme ou juge probables sont retenues ; les autres sont comptabilisées comme rejetées.
Pour les vulnérabilités retenues, l’agent de vérification rédige la cause racine, un test de reproduction et un correctif minimal proposé sous forme de diff unifié.
- 6
Commit à l’origine et rapport
Les doublons ayant une même cause racine sont regroupés. La commande git blame appliquée aux lignes vulnérables repère le commit le plus récent qui les a modifiées — généralement celui qui a introduit le bug — afin que vous puissiez ajouter une balise Fixes: et déterminer quelles versions sont concernées.
Le rapport est stocké sous un ID aléatoire impossible à deviner. Vous pouvez l’exporter en Markdown pour un avis de sécurité, en JSON pour des outils ou en SARIF 2.1.0 pour l’analyse de code de GitHub.
Ce que le scanner ne fait pas
- Il n’exécute pas votre code, ne le compile pas et ne récupère pas ses dépendances.
- Il ne publie pas les vulnérabilités détectées, ne crée pas de problèmes et ne contacte personne, à l’exception des mainteneurs inscrits.
- Il ne conserve aucune copie de votre code source après l’analyse. Les rapports contiennent de courts extraits des lignes concernées.
- Il ne garantit aucun résultat : les modèles passent parfois à côté de bugs et en signalent parfois à tort. Un rapport sans vulnérabilité détectée ne constitue pas une certification de sécurité.
Pourquoi les tests de reproduction sont verrouillés
N’importe qui peut coller un lien vers un dépôt public, y compris une personne qui n’en est pas mainteneuse. La cause racine et le correctif aident les défenseurs ; un PoC fonctionnel aide surtout les attaquants. Les tests de reproduction restent donc masqués jusqu’à ce qu’une personne ajoute un fichier de jeton au dépôt — preuve qu’elle peut y publier un correctif. Cela suit les recommandations du noyau Linux : les tests de reproduction des bugs trouvés par IA doivent être communiqués à la demande des mainteneurs.
En quoi cela diffère de l’Anthropic OSS Scanner d’Anthropic
Anthropic exécute son scanner dans des environnements isolés hors ligne, où le projet est compilé à partir d’un Dockerfile. Les agents peuvent ainsi compiler et exécuter le code pour confirmer dynamiquement les bugs. Le scanner utilise les modèles les plus puissants d’Anthropic, notamment Claude Mythos, qui n’est pas accessible au public. Nous analysons le code de façon statique à l’aide de modèles Claude accessibles au public. En contrepartie, tout le monde peut utiliser ossscanner.org en quelques minutes, sans candidature ni Dockerfile.