Vertiefende Analyse · Etwa 7 Min. Lesezeit
Claudes Beweisstudie zu 123 Bibliotheken grenzt Softwaregarantien genauer ein, macht sie aber nicht universell
Anthropic und Theorem berichten über Beweise für 239 Fuzzing-Einstiegspunkte in 123 Bibliotheken, mit ausdrücklichen Maschinenannahmen und Grenzen der Aussagekraft.
- Hier veröffentlicht
- Datum der Quelle
- Quelle geprüft
In einem Forschungsartikel vom 22. Oktober beschreibt Anthropic die Zusammenarbeit mit Theorem, bei der Claude maschinell geprüfte Softwarebeweise erzeugt. Das nützliche Ergebnis ist eine Garantie für ausgewählte ausführbare Programme innerhalb eines definierten Modells und kein Sicherheitszertifikat für eine ganze Bibliothek oder jede denkbare Bereitstellung.
Nachrichten anhören
Diesen Artikel vorlesen oder mit den Nachrichten fortfahren.
Vorlesen wird vorbereitet…
Gerätestimme
Browser oder Gerät verarbeiten die Sprache. AISubHub sendet den Text nicht an eine Audio-API. Stimmen und Wiedergabe bei gesperrtem Bildschirm hängen vom Gerät ab.
Beim Fortsetzen kann sich ein kurzer Satzteil wiederholen.
Auf einen Blick
- Die Forschenden berichten über Beweise für Absturzfreiheit an 239 Einstiegspunkten in 123 OSS-Fuzz-Bibliotheken, nachdem gefundene Fehler bei Bedarf behoben wurden, für Eingaben unter 64 MB und unter den genannten Annahmen.
- Das Hauptexperiment betrifft Programme mit einem Thread, die als statische RISC-V-Binärdateien mit musl verknüpft sind, sowie modelliertes Linux-Verhalten. Übliche x86- oder ARM-Bereitstellungen sind dadurch nicht automatisch abgedeckt.
- Separate Experimente mit kleinen Aufgaben vergleichen den Tokenbedarf verschiedener Modelle und die gemeinsame Nutzung von Beweisen. Die berichteten Einsparungen gelten für diese Experimente und sind keine allgemeine Preis- oder Leistungsgarantie.
Ein Beweis gilt für einen Einstiegspunkt in einer definierten Maschine
Die Einheit der Abdeckung ist entscheidend. Ein OSS-Fuzz-Einstiegspunkt ist ein von Entwicklern bereitgestellter Zugang, um Eingaben in ein Programm einzuspeisen und Fehler zu melden. Anthropic berichtet, innerhalb mehrerer Wochen Beweise für 239 solcher Einstiegspunkte in 123 Bibliotheken fertiggestellt zu haben. Das sind weder 239 vollständig verifizierte Bibliotheken noch alle möglichen Wege durch die 123 Bibliotheken. Das Projekt erzeugte etwa 180 Millionen Zeilen Rocq-Beweiscode; ein typischer Beweis umfasste ungefähr 600.000 Zeilen, während die Binärprogramme im Median 18.000 RISC-V-Instruktionen enthielten.
Die Aussage wird durch die modellierte Ausführung begrenzt: Eingaben kleiner als 64 MB, ein festes Speicherbudget, ein Thread, ein statisches und mit musl verknüpftes RISC-V-Programm sowie festgelegte Linux-Antworten und Speicheranordnungen. Diese Bedingungen definieren die mathematische Aussage. Nach Einschätzung von AISubHub sind die Bezugsgröße der Abdeckung und die Build-Konfiguration für die Bewertung hilfreicher als allein die beeindruckende Gesamtzahl an Beweiszeilen.
Aus Fuzzing wird eine Aussage, die ein kleiner Kern prüft
Fuzzing probiert viele erzeugte Eingaben aus und kann ein Gegenbeispiel finden. Erfolgreich bestandene Versuche erschöpfen aber nicht den gesamten Eingaberaum. Hier übersetzen die Forschenden einen vorhandenen Fuzz-Test und dessen kompiliertes Programm in eine formale Spezifikation. Claude erstellt eine Argumentation dafür, dass der ausgewählte Test bei keiner zulässigen Eingabe abstürzen kann. Bereits im Test vorhandene Zusicherungen können auch aussagekräftige Eigenschaften ausdrücken, etwa dass nach Kompression und anschließender Dekompression wieder die ursprünglichen Daten vorliegen.
Das Modell darf seinen eigenen Beweis nicht einfach für korrekt erklären. Rocq prüft ihn gegen die Aussage. Vertrauen richtet sich deshalb auf die genaue Aussage, die Semantik von RISC-V und Linux sowie das Prüfprogramm einschließlich seiner zugrunde liegenden Hard- und Software. Das ist ein kleinerer Prüfgegenstand als Millionen erzeugter Zeilen, bleibt aber eine reale Abhängigkeit. Ein gültiger Beweis kann nicht belegen, dass ein ungenaues Maschinenmodell ein Produktionssystem wirklichkeitsgetreu beschreibt.
Warum auch ein gescheiterter Beweisversuch einen nützlichen Patch liefern kann
Nach Angaben der Forschenden deckten Beweisversuche Fehler auf. Dazu gehörten ein Dekompressionsproblem, das eine ungewöhnlich angeordnete Eingabe von etwa 20 MB erforderte, und ein Fehler in einem Bilddecoder, der eine Eingabe von 64 MB und mehr als 2 GB Speicher benötigte. Diese Beispiele erklären, warum eine vorwiegend auf kleinen Eingaben beruhende Suche relevantes Verhalten übersehen kann. Es handelt sich um von der Quelle berichtete Funde und nicht um von AISubHub unabhängig reproduzierte Schwachstellen.
Die Pipeline konnte ein Programm patchen, seine Spezifikation neu erzeugen und anschließend das gepatchte Artefakt beweisen. Ein Beweis für dieses neue Artefakt darf nicht als Beweis für die ursprüngliche unveränderte Version dargestellt werden. Außerdem besteht die Gefahr einer Abkürzung: Ein Agent könnte nützliches Verhalten entfernen, um eine Aussage zur Absturzfreiheit leicht erfüllbar zu machen. Die Autoren beschreiben Strafen für Patches, Anreize zur Charakterisierung der Eingaben mit verändertem Verhalten und Audits der Patches. Diese Maßnahmen zielen auf einen Fehlermodus ab; sie ersetzen nicht die Prüfung, ob eine Korrektur das beabsichtigte Verhalten erhält.
Die Tokenersparnisse stammen aus zwei verschiedenen Experimenten
Für eine separate Gruppe von 36 kleinen Verifikationsaufgaben erklärt der Artikel, dass Opus 5.5 die Hälfte der Aufgaben mit rund 40% weniger Token als Opus 5 beweist. Für jede Aufgabe gab es drei unabhängige Versuche mit jeweils einem Agenten und einem Budget von fünf Millionen Token pro Versuch. Im Diagramm zählte eine Aufgabe, sobald der erste erfolgreiche Versuch abgeschlossen war. Das ist ein Vergleich innerhalb einer bestimmten Aufgabengruppe und ihrer Budgets. Der Artikel nennt nicht alle Modelle, die beim größeren Vorhaben mit 123 Bibliotheken eingesetzt wurden; dieses Vorhaben darf deshalb nicht vollständig als Ergebnis von Opus 5.5 umetikettiert werden.
In einem Experiment mit gemeinsamem Arbeitsbereich durften Agenten die Beweise anderer wiederverwenden. Berichtet wurden 17% weniger Token als bei isolierter Arbeit. Das Diagramm mit 36 Beweisen zeigt bei 30 der 34 abgeschlossenen Einzelvergleiche einen geringeren Tokenverbrauch; allein arbeitende Agenten beendeten zwei Aufgaben nicht. Die Wiederverwendung von Beweisen für die Laufzeitinitialisierung und den Speicherfehlerdetektor bietet einen konkreten Mechanismus für Einsparungen. Keiner der Prozentwerte liefert allgemeingültige Dollarkosten, eine Verkürzung der verstrichenen Zeit oder einen unabhängig gemessenen Nutzen bei der Bereitstellung.
Andere Fallstudien messen unterschiedliche Arten von Korrektheit
Der Artikel beschreibt außerdem ein zlib-Experiment mit einer aus einem RFC abgeleiteten Spezifikation und x86-Semantik. Das ist eine separate Fallstudie und kein Nachweis dafür, dass die umfangreichen RISC-V-Ergebnisse bereits für sämtliche x86-Software gelten. Ein in Rust geschriebener Interpreter für eine große Teilmenge von Python wurde mit Verus gegen modellierte CPython-Semantik geprüft und anschließend anhand von mehr als 1,7 Millionen zufällig erzeugten Programmen empirisch mit CPython verglichen.
Die berichtete Verhaltensübereinstimmung von 99,95% gehört zu diesem empirischen Vergleich. Sie ist kein Beweis für Kompatibilität mit jedem Python-Programm. Der Unterschied ist wesentlich: Ein Beweis belegt eine bestimmte formale Aussage, während ein Testprozentsatz ein Stichprobenexperiment beschreibt. Würde man diese Ergebnisse zu einem allgemeinen Genauigkeitswert des Modells zusammenfassen, gingen die Unterschiede zwischen Spezifikationen, Werkzeugen und verbleibenden Randfällen verloren.
Der technische Gewinn besteht in einer klareren Grenze
Die Autoren benennen ausdrücklich Lücken. AddressSanitizer erkennt manche Speicherfehler nicht; das Projekt deckte nicht jeden Einstiegspunkt ab; selbst sämtliche Fuzzing-Einstiegspunkte würden nicht das gesamte Bibliotheksverhalten oder unerreichbaren Code erfassen. Auch ein aufrufendes Programm kann eine Bibliothek außerhalb der verifizierten Annahmen falsch verwenden. Übliche Bereitstellungen nutzen dynamische Verknüpfung, glibc, x86 oder ARM und unterscheiden sich damit vom Hauptexperiment. Manche Beweise werden zurückgehalten, um noch ungepatchte Fehler nicht offenzulegen. Der weiter reichende Fahrplan für das Softwareökosystem bleibt ein Vorschlag.
Analyse von AISubHub: Ein praktikabler nächster Schritt ist, jede behauptete Garantie mit einem exakten Build, einem Test-Einstiegspunkt, einer Eingabegrenze und einem vertrauenswürdigen Maschinenmodell zu verknüpfen und sie bei Änderungen dieser Grundlagen neu zu bewerten. Das kann Tests und Reviews ergänzen, statt ihre Abschaffung im gesamten Projekt zu rechtfertigen. Wir haben den Artikel und seine notwendigen Abbildungen gelesen, aber weder die Beweise erneut ausgeführt noch den externen Anhang oder die veröffentlichten Repositories auditiert, die Sicherheit der Patches validiert oder die Tokenersparnisse reproduziert. Ergebnisse und Zukunftserwartungen bleiben den Forschenden zugeschrieben.
Warum es wichtig ist
Analyse von AISubHub: Erzeugte Beweise könnten den Aufwand verringern, eine eng umrissene, überprüfbare Softwareeigenschaft nachzuweisen und wiederzuverwenden. Das verwertbare Ergebnis sind das exakt verifizierte Artefakt und die genaue Aussage mit ihren Annahmen, nicht die pauschale Behauptung, KI habe Software fehlerfrei gemacht.
Grenzen und Verfügbarkeit
Dies ist eine Analyse der veröffentlichten Darstellung der Forschenden und weder ein unabhängiges Sicherheitsaudit noch eine Reproduktion. Die Grenzen des Hauptexperiments hinsichtlich Eingaben, Architektur, Verknüpfung, Speicher und Einstiegspunkten bleiben wesentlich; der externe Anhang und die Inhalte der Repositories wurden nicht auditiert.
Quellen und Belege
Datum der Quelle: · Quelle geprüft:
KI-gestützte redaktionelle Beiträge, anhand der genannten Primärquellen geprüft. Anbieterangaben werden zugeordnet; eine Aufnahme ist keine Empfehlung.