Claude prüft 239 Softwaretests mit formalen Beweisen – was wirklich sicher ist

Formale Softwareverifikation: Technik, Grenzen und Einordnung

Fuzzing hat Open-Source-Software über Jahre sicherer gemacht. Die Methode probiert sehr viele veränderte Eingaben und sucht Abstürze, erreicht aber zwangsläufig nicht jeden möglichen Programmzustand. Anthropic und das Forschungsunternehmen Theorem haben nun einen anderen Weg dokumentiert: Claude erhält die Aufgabe, aus vorhandenen Fuzz-Tests formal beweisbare Eigenschaften abzuleiten. Am 22. Oktober 2026 stellte das Team Ergebnisse für 123 Bibliotheken aus dem OSS-Fuzz-Umfeld vor. Die Nachricht ist relevant, weil ein erfolgreiches maschinell geprüftes Argument mehr leistet als eine bloße Testserie – sofern seine Voraussetzungen stimmen.

Der veröffentlichte Kernbefund ist präzise: Für 239 Test-Einstiegspunkte wurden No-Crash-Beweise erzeugt. Anthropic spricht von rund 180 Millionen Zeilen Rocq-Beweissprache. Claude schrieb die Beweisversuche; die formale Prüfung übernahm der Rocq-Kernel, der mathematische Aussagen anhand einer festgelegten Semantik kontrolliert. Als Eingabe dienten für RISC-V übersetzte Programme, deren erwartetes Verhalten aus bestehenden Fuzz-Tests abgeleitet wurde. Der Erfolg besagt also nicht, dass jeder denkbare Anwendungsfall einer vollständigen Bibliothek sicher ist.

Besonders wichtig sind die technischen Grenzen. Der No-Crash-Beweis gilt für Eingaben unter 64 Megabyte und für modellierte Linux-Reaktionen und Speicherlayouts. Das zugrunde gelegte Programm ist ein statisch gelinktes Single-Thread-Binary mit festem Speicherbudget auf RISC-V. Betrieb unter anderen Prozessorarchitekturen, Thread-Interleavings, abweichende Systemaufrufe und externe Komponenten sind damit nicht automatisch erfasst. Auch die Korrektheit der Spezifikation, der Maschinen- und Betriebssystemsemantik sowie des Rocq-Prüfers bleibt Teil der Vertrauensbasis. Formal verifiziert heißt nicht: ohne jede Sicherheitslücke.

Während der Arbeit meldeten die Forscher Hunderte Fehler, die Fuzzing bisher nicht offengelegt hatte. Claude konnte nach Herstellerangaben einige dieser Probleme patchen und anschließend die entsprechende Eigenschaft beweisen. Ein Beispiel betraf eine besondere Eingabestruktur von ungefähr 20 Megabyte in einem Dekompressor. Für Entwickler ist gerade diese Kombination interessant: Ein fehlgeschlagener Beweisversuch kann ein reproduzierbarer Hinweis auf einen Fehler sein, selbst wenn am Ende kein vollständiger Beweis gelingt. Der Forschungsbericht ist dafür Primärquelle, keine unabhängige Wirksamkeitsstudie jeder Änderung.

Für den praktischen Einsatz empfiehlt sich kein sofortiger Ersatz aller Qualitätssicherung. Teams sollten mit einem überschaubaren, gut spezifizierten Modul beginnen und festhalten, welche Binärversion, CPU-Semantik, Betriebssystemannahmen, Eingabegrenzen und Tests tatsächlich erfasst werden. Der Proof Checker muss unabhängig und reproduzierbar laufen; Patch-Vorschläge gehören weiterhin in Code-Review, CI und Regressionstests. Besonders bei kryptografischen, vernetzten oder nebenläufigen Diensten reicht eine No-Crash-Eigenschaft nicht aus, um korrekte Berechtigungen, Vertraulichkeit und funktionale Richtigkeit zu garantieren.

Die redaktionelle Einordnung: Hier verschiebt sich der Beitrag von KI vom Finden wahrscheinlicher Bugs zum Schreiben überprüfbarer Aussagen über genau bezeichnete Programme. Das kann hochwertige Softwareprüfungen günstiger und breiter zugänglich machen. Ob der Ansatz auf typische Cloud-Dienste, reale Betriebssystemkonfigurationen und komplexe Multi-Thread-Anwendungen skaliert, muss aber erst separat gezeigt werden. Auch ein riesiger formaler Beweis ist nur so aussagekräftig wie die Aussage, die er tatsächlich beweist.

Originalquellen und weiterführende Artikel

• Anthropic – LLMs are making formal software verification feasible at a much larger scale ↗
• Anthropic/Theorem – veröffentlichtes Beweis-Repository ↗

Die Angaben wurden anhand der genannten Dokumente für diesen Beitrag redaktionell eingeordnet; es gab keinen eigenen Produkt- oder Labortest.

Sicherheitsrisiken von KI-Agenten verstehen →

KI-gestützte PHP-Sicherheitsfunde einordnen →