Anthropic rapporte que Claude a repéré 493 problèmes de surface d’attaque dans 25 projets open source. La surface d’attaque désigne les parties d’un logiciel qu’un attaquant pourrait atteindre, notamment du code accessible avant l’authentification ou des réglages qui affaiblissent des protections.

Ces 493 résultats ne sont pas un décompte de vulnérabilités démontrées et exploitées. Pour les 11 projets classés « Gated », Anthropic précise que les problèmes relevés n’étaient pas immédiatement exploitables à eux seuls : ils signalaient surtout du code accessible ou des contrôles insuffisants.

Ce que Claude a analysé

Les 25 projets représentaient plus de cinq millions de lignes de code, notamment en C, C++, Java, PHP et Python. Anthropic indique que Claude a recensé plus de 17 000 options de configuration, dont 3 842 liées à la sécurité. Les projets étaient répartis en trois catégories : 10 « Public », 11 « Gated » et 4 « Private ».

L’analyse portait sur les chemins de code accessibles avec les réglages par défaut, les interactions entre options de configuration et le code sensible exécuté avant des contrôles comme l’authentification. Ces vérifications visent à repérer des fonctions accessibles sans nécessité, même lorsqu’aucune exploitation n’est démontrée.

Trois mesures distinctes dans les projets « Gated »

Dans les 11 projets « Gated », Anthropic a relevé 93 surfaces de préauthentification accessibles avec la configuration par défaut, 37 endroits où du code s’exécutait ou où un état était enregistré avant l’authentification, et 61 combinaisons de paramètres qui affaiblissaient un contrôle de préauthentification. Ces chiffres décrivent des types de résultats différents.

Sur l’ensemble des projets, Anthropic a également recensé 162 combinaisons de configuration sensibles acceptées sans avertissement ni documentation de leur comportement attendu. Parmi elles, 94 désactivaient silencieusement un contrôle de sécurité et 68 produisaient d’autres incohérences.

OpenSSH : du code ML-DSA-44 accessible avant le contrôle

Dans OpenSSH 10.4, Claude a repéré environ 4 500 lignes de code expérimental liées à ML-DSA-44, un algorithme de signature post-quantique, accessibles à un client non authentifié avant le contrôle de configuration concerné. L’algorithme n’était pas activé par défaut. Selon Anthropic, ces lignes représentaient environ 16 % du code de préauthentification d’OpenSSH.

Anthropic indique qu’OpenSSH 10.5 a d’abord déplacé un contrôle avant l’analyse syntaxique. Une analyse ultérieure a cependant révélé des lacunes dans la vérification du type de clé encodé et de l’algorithme de signature de l’autorité de certification d’un certificat. Les changements finaux, intégrés à OpenSSH 10.6 selon Anthropic, vérifient ces éléments par rapport aux listes d’autorisation configurées avant la désérialisation ou la vérification de signature.

La réduction d’environ un cinquième rapportée par Anthropic concerne le code auquel un client non authentifié pouvait accéder dans une compilation par défaut avant ces changements. Elle ne mesure pas la part de l’ensemble du code d’OpenSSH.

Comment Anthropic vérifie les changements proposés

Anthropic indique que son outil confirme les résultats à l’aide de traces dynamiques du programme. Pour les contrôles liés à la configuration par défaut, il compare la version modifiée à la version de référence en utilisant la suite de tests du projet et une suite de régression en boîte noire. Les changements qui touchent des configurations non par défaut sont soumis à une revue humaine.

Anthropic a aussi indiqué travailler à l’intégration de cette méthode dans OSS-Scanner, son service d’analyse de projets open source sur inscription volontaire.