Claude et les preuves formelles de sécurité logicielle

CCapucine

Anthropic indique que Claude, en collaboration avec Theorem, a produit des preuves formelles vérifiées par machine pour 239 points d’entrée de tests de fuzzing répartis dans 123 bibliothèques open source. Le travail porte sur le code assembleur RISC-V, d’après Unite.AI. Il ne s’agit pas d’une preuve générale de sécurité de chaque bibliothèque. La propriété vérifiée concerne les programmes associés à ces points d’entrée. Pour toute entrée de moins de 64 mégaoctets, et dans les conditions Linux modélisées, Claude a corrigé les bogues détectés puis prouvé que les programmes terminent normalement, sans erreur de sûreté mémoire ni assertion échouée. La portée de cette garantie dépend donc des entrées et de l’environnement retenus par les chercheurs.

CCapucine

Pour comprendre ce que mesure ce résultat, il faut distinguer 2 méthodes. Le fuzzing exécute un programme avec des entrées variées et permet de repérer des échecs lorsqu’ils se produisent. Une preuve formelle établit une propriété précise pour toutes les entrées couvertes par le théorème et le modèle d’exécution. Ici, les chercheurs ont repris des points d’entrée de tests de fuzzing pour définir ces propriétés. Le périmètre est donc ciblé : il ne s’agit pas de démontrer que chaque fonction de chaque bibliothèque est correcte dans toutes les situations. Les points d’entrée des tests servent de périmètre à la preuve, plutôt que l’ensemble des fonctions de chaque bibliothèque.

CCapucine

L’expérience menée avec Claude a produit environ 180 millions de lignes de preuves dans le langage Rocq en quelques semaines, sans rédaction manuelle des preuves, selon AlphaSignal. Le volume donne une idée de l’échelle du travail automatisé, mais les chercheurs ont fourni les modèles, les outils, les bancs de test et la conception de la vérification. La méthode a aussi révélé puis permis de corriger des défauts qui avaient échappé à des campagnes de fuzzing répétées, dont un bogue logique ancien et la vulnérabilité CVE-2026-56132. Cela montre l’intérêt de compléter les tests par des preuves portant sur des entrées définies par un modèle. Les résultats ne signifient pas que le fuzzing devient inutile : les deux approches ne couvrent pas les mêmes garanties.

CCapucine

Les garanties annoncées restent limitées aux entrées de moins de 64 mégaoctets et aux conditions Linux modélisées. Les chercheurs ont également fourni les modèles, les outils, les bancs de test et la conception de la vérification : le travail de Claude s’appuie donc sur cette infrastructure. Anthropic et Theorem ont publié en accès libre les preuves, les sémantiques et un outil Claude associé au projet. Ces éléments permettent de consulter ce qui a été vérifié et les moyens employés. Ce qu’il faut retenir, c’est une preuve formelle à grande échelle sur des propriétés précises, et non une certification générale de la sécurité des 123 bibliothèques.