Analyse approfondie · Environ 8 min de lecture
L’étude de preuves de Claude sur 123 bibliothèques précise les garanties du logiciel sans les rendre universelles
Anthropic et Theorem présentent des preuves pour 239 points d’entrée de fuzzing dans 123 bibliothèques, avec des hypothèses explicites sur la machine et des limites sur la portée des résultats.
- Publié ici
- Date de la source
- Source vérifiée
Dans un article de recherche daté du 22 octobre, Anthropic décrit son travail avec Theorem qui utilise Claude pour générer des preuves logicielles vérifiées par machine. Le résultat utile est une garantie concernant certains programmes exécutables dans un modèle défini, plutôt qu’un certificat de sécurité pour une bibliothèque entière ou tous ses déploiements.
Écouter les actualités
Écoutez cet article ou poursuivez la lecture des actualités.
Préparation de la lecture…
Voix de l’appareil
La voix est traitée par votre navigateur ou appareil. AISubHub n’envoie pas le texte à une API audio. Les voix et la lecture écran verrouillé dépendent de l’appareil.
La reprise peut répéter une courte phrase.
En bref
- Les chercheurs annoncent des preuves d’absence de plantage pour 239 points d’entrée dans 123 bibliothèques OSS-Fuzz, après correction des bogues découverts lorsque cela était nécessaire, pour des entrées inférieures à 64 MB et sous les hypothèses énoncées.
- L’expérience principale porte sur des programmes RISC-V à un seul fil d’exécution, liés statiquement avec musl, ainsi que sur le comportement modélisé de Linux. Elle ne couvre pas automatiquement les déploiements courants sur x86 ou ARM.
- Des expériences distinctes sur de petites tâches comparent les besoins en tokens des modèles et le partage de preuves. Les économies annoncées sont propres à ces expériences et ne constituent pas une garantie générale de prix ou de performances.
Une preuve couvre un point d’entrée dans une machine définie
L’unité de couverture compte. Un point d’entrée OSS-Fuzz est un moyen fourni par le développeur pour introduire des données dans un programme et signaler les défaillances. Anthropic indique avoir achevé en plusieurs semaines des preuves pour 239 de ces points d’entrée dans 123 bibliothèques. Il ne s’agit ni de 239 bibliothèques entièrement vérifiées ni de tous les chemins possibles dans les 123 bibliothèques. Le projet a produit environ 180 millions de lignes de code de preuve Rocq ; une preuve typique comptait environ 600 000 lignes, tandis que les binaires avaient une médiane de 18 000 instructions RISC-V.
L’affirmation est bornée par l’exécution modélisée : des entrées de moins de 64 MB, un budget mémoire fixe, un seul fil d’exécution, un exécutable RISC-V statique lié avec musl, ainsi que des réponses de Linux et des dispositions mémoire spécifiées. Ces conditions définissent l’énoncé mathématique. Selon la lecture d’AISubHub, le dénominateur de la couverture et la configuration de compilation sont plus utiles pour évaluer ce résultat que le seul total impressionnant de lignes de preuve.
Le fuzzing devient une affirmation vérifiée par un petit noyau
Le fuzzing essaie de nombreuses entrées générées et peut découvrir un contre-exemple, mais réussir ces essais n’épuise pas l’espace des entrées. Ici, les chercheurs transforment un test de fuzzing existant et son exécutable compilé en une spécification formelle. Claude construit un raisonnement montrant que le test sélectionné ne peut planter pour aucune entrée autorisée. Les assertions déjà présentes dans un test peuvent également encoder des propriétés significatives, comme retrouver les données initiales après compression puis décompression.
Le modèle ne peut pas déclarer lui-même sa preuve correcte. Rocq vérifie la preuve par rapport à l’énoncé. La confiance se déplace donc vers l’énoncé exact, la sémantique de RISC-V et de Linux, et le vérificateur, y compris son matériel et ses logiciels sous-jacents. C’est un périmètre de revue plus restreint que la lecture de millions de lignes générées, mais cela reste une dépendance réelle. Une preuve valide ne peut établir qu’un modèle de machine inexact décrit fidèlement un système en production.
Pourquoi un échec de preuve peut tout de même produire un correctif utile
Selon les chercheurs, les tentatives de preuve ont révélé des bogues, notamment un problème de décompresseur exigeant une entrée d’environ 20 MB organisée de manière inhabituelle et une défaillance de décodeur d’images nécessitant une entrée de 64 MB et plus de 2 GB de mémoire. Ces exemples expliquent pourquoi une recherche dominée par de petites entrées peut manquer certains comportements pertinents. Il s’agit de découvertes rapportées par la source, et non de vulnérabilités reproduites indépendamment par AISubHub.
Le processus pouvait corriger un programme, régénérer sa spécification, puis prouver des propriétés de l’artefact corrigé. La preuve de ce nouvel artefact ne doit pas être présentée comme celle de la version initiale non modifiée. Il existe aussi un risque de raccourci : un agent pourrait supprimer un comportement utile pour rendre facile l’énoncé d’absence de plantage. Les auteurs décrivent des pénalités sur les correctifs, des incitations à caractériser les entrées dont le comportement change, ainsi que des audits des correctifs. Ces garde-fous traitent un mode de défaillance ; ils ne dispensent pas de vérifier qu’une correction préserve le comportement attendu.
Les économies de tokens viennent de deux expériences différentes
Pour un ensemble distinct de 36 petites tâches de vérification, l’article indique qu’Opus 5.5 prouve la moitié des tâches avec environ 40% de tokens en moins qu’Opus 5. Chaque tâche faisait l’objet de trois tentatives indépendantes à agent unique, chacune disposant d’un budget de cinq millions de tokens, et le graphique comptait la tâche dès qu’une première tentative aboutissait. Il s’agit d’une comparaison propre à un ensemble de tâches et à des budgets. L’article n’identifie pas tous les modèles utilisés pour le travail plus vaste sur les 123 bibliothèques : ce travail ne doit donc pas être intégralement réattribué à Opus 5.5.
Une expérience avec espace de travail partagé permettait aux agents de réutiliser les preuves des autres et annonçait 17% de tokens en moins que le travail isolé. Son graphique de 36 preuves montre une consommation de tokens inférieure dans 30 des 34 comparaisons avec des tentatives individuelles achevées ; les agents isolés n’ont pas terminé deux tâches. La réutilisation des preuves d’initialisation de l’environnement d’exécution et du détecteur d’erreurs mémoire offre un mécanisme concret d’économie. Aucun des pourcentages ne fournit un coût universel en dollars, une réduction du temps écoulé ou un avantage de déploiement mesuré indépendamment.
Les autres cas mesurent des formes différentes de correction
L’article décrit aussi une expérience zlib fondée sur une spécification dérivée d’un RFC et utilisant une sémantique x86. C’est une étude de cas distincte, et non la preuve que les résultats principaux sur RISC-V s’appliquent déjà à tous les logiciels x86. Un interpréteur en Rust d’un vaste sous-ensemble de Python a été vérifié avec Verus par rapport à une sémantique modélisée de CPython, puis comparé empiriquement à CPython sur plus de 1,7 million de programmes générés aléatoirement.
Le taux annoncé de 99,95% de comportements identiques relève de cette comparaison empirique. Ce n’est pas une preuve de compatibilité avec tous les programmes Python. La distinction importe : une preuve établit un énoncé formel particulier, tandis qu’un pourcentage de tests décrit une expérience sur un échantillon. Fusionner ces résultats en un score général de précision du modèle effacerait les différences entre les spécifications, les outils et les cas limites restants.
Le gain d’ingénierie tient à une frontière plus claire
Les auteurs reconnaissent explicitement des lacunes. AddressSanitizer manque certaines erreurs mémoire ; le projet n’a pas couvert tous les points d’entrée ; même l’ensemble des points d’entrée de fuzzing ne couvrirait pas tous les comportements d’une bibliothèque ni son code mort. Un programme appelant peut également mal utiliser la bibliothèque en dehors des hypothèses vérifiées. Les déploiements courants utilisent la liaison dynamique, glibc, x86 ou ARM, qui diffèrent de l’expérience principale. Certaines preuves ne sont pas publiées pour éviter de révéler des bogues non corrigés, et la feuille de route vers un écosystème plus large reste une proposition.
Analyse d’AISubHub : une prochaine étape pratique consiste à relier chaque garantie annoncée à une compilation exacte, à un point d’entrée de test, à une borne d’entrée et à un modèle de machine de confiance, puis à la réévaluer lorsque ces éléments changent. Cette approche peut compléter les tests et la revue, plutôt que justifier leur suppression dans tout un projet. Nous avons lu l’article et ses figures nécessaires, mais nous n’avons ni réexécuté les preuves, ni audité l’annexe externe ou les dépôts publiés, ni validé la sécurité des correctifs, ni reproduit les économies de tokens. Les résultats et les attentes futures restent attribués aux chercheurs.
Pourquoi cela compte
Analyse d’AISubHub : les preuves générées pourraient réduire le coût nécessaire pour établir et réutiliser une propriété logicielle étroite et susceptible d’être revue. Le résultat exploitable est l’artefact vérifié et l’énoncé exacts, avec leurs hypothèses, et non l’affirmation générale que l’IA aurait éliminé tous les bogues du logiciel.
Limites et disponibilité
Il s’agit d’une analyse du récit publié par les chercheurs, et non d’un audit de sécurité indépendant ou d’une reproduction. Les limites d’entrée, d’architecture, de liaison, de mémoire et de points d’entrée de l’expérience principale restent essentielles ; l’annexe externe et le contenu des dépôts n’ont pas été audités.
Sources et preuves
Date de la source: · Source vérifiée:
Articles assistés par IA, vérifiés avec les sources primaires citées. Les affirmations des fournisseurs sont attribuées ; la présence ne vaut pas recommandation.