LLMs automatisieren die formale Verifizierung von Open-Source-Bibliotheken im großen Maßstab

Softwareentwickler kämpfen seit langem mit den hohen Kosten der formalen Verifizierung, einer Methode, die mathematisch beweist, dass Code frei von bestimmten Fehlern ist. Eine kürzliche Zusammenarbeit zwischen einem KI-Forschungsteam und Theorem zeigt, dass große Sprachmodelle diesen Prozess nun im großen Maßstab automatisieren können. Durch die Analyse kompilierter Binärdateien mit Claude konnte das Team Sicherheitsmerkmale für über 100 reale Open-Source-Bibliotheken erfolgreich nachweisen – ein bedeutender Wandel in der Gewährleistung der Softwarekorrektheit.

Was passiert ist

Das Projekt konzentrierte sich auf die Anwendung formaler Verifizierung auf Produktionssoftware auf Ebene des Assemblercodes, speziell für die RISC-V-Architektur. Das Team wählte 123 Open-Source-Bibliotheken aus der OSS-Fuzz-Initiative von Google aus, die bereits Tausende von Entwickler-eingetragenen Einstiegspunkten enthält, die bei gefundenen Fehlern abstürzen sollen. Anstatt auf Brute-Force-Tests zu setzen, bat das Team Claude zu beweisen, dass diese Programme bei keiner Eingabe unter 64 MB abstürzen würden, vorausgesetzt, es handelt sich um eine statische, single-threaded Binärdatei, die unter Linux läuft.

Innerhalb weniger Wochen generierte Claude Beweise für 239 Einstiegspunkte über diese Bibliotheken hinweg. Die resultierenden Beweise umfassten insgesamt etwa 180 Millionen Zeilen Rocq-Code, wobei einzelne Beweise durchschnittlich rund 600.000 Zeilen lang waren. Während dieses Prozesses hat das Modell nicht nur die Beweise generiert, sondern auch Fehler identifiziert und behoben, die trotz Billionen vorheriger Testläufe bestehen geblieben waren. Dieser Aufwand stellt die erste großflächige Anwendung von KI zur formalen Verifizierung von Produktionssoftware auf Assemblerebene dar.

Um diese Erkenntnisse zugänglich zu machen, veröffentlicht das Team eine Teilmenge der Beweise zusammen mit den RISC-V- und Betriebssystem-Semantiken, die in der Analyse verwendet wurden. Theorem bietet zudem an, diese Verifizierungspipeline für andere Open-Source-Projekte durchzuführen, und hat eine Claude-Skill veröffentlicht, um Entwicklern beim Beginn der Verifizierung ihres eigenen Codes zu helfen. Dieser Ansatz verschiebt die formale Verifizierung von einer Nischenpraxis, die kritischen Systemen wie der Avionik vorbehalten war, hin zu einem breiter anwendbaren Werkzeug für die allgemeine Softwareentwicklung.

Wie es funktioniert

Formale Verifizierung erfordert die Übersetzung von Code in ein mathematisches Modell und den Nachweis, dass es einer Reihe von Sicherheitsregeln entspricht. Die größte Herausforderung war stets die Definition dessen, was "korrekt" für komplexe Software bedeutet. In diesem Projekt umging das Team die Notwendigkeit manueller Spezifikationen, indem es bestehende Fuzz-Tests in formale Spezifikationen umwandelte. Fuzz-Tests erzeugen zufällige Eingaben, um Abstürze zu finden, können aber nicht garantieren, dass jeder Pfad getestet wird. Die neue Methode definiert die Spezifikation als "diese Testsuite besteht immer", angewendet auf die kompilierten RISC-V-Anweisungen statt auf den Quellcode.

Claude arbeitet, indem es die ausführbaren Artefakte sowie die formalen Semantiken des RISC-V-Befehlssatzes und des Linux-Prozessverhaltens analysiert, die von Theorem bereitgestellt werden. Das Modell generiert massive Beweise, die zeigen, dass unter den definierten Bedingungen keine Speicherfehler oder Assertionsfehler auftreten können. Diese Beweise werden anschließend vom Rocq-Beweisprüfer validiert, einem vertrauenswürdigen Kernel, der sicherstellt, dass die mathematische Logik stimmt. Da der Prüfer den Beweis automatisch validiert, müssen Entwickler die Millionen von Zeilen generierten Codes nicht manuell überprüfen; sie vertrauen lediglich den zugrunde liegenden Modellen und dem Prüfer selbst.

Wichtige Details

• Das Projekt verifizierte 239 Einstiegspunkte über 123 Open-Source-Bibliotheken aus der OSS-Fuzz-Initiative.
• Claude generierte ungefähr 180 Millionen Zeilen Rocq-Beweiscode, wobei typische Beweise 600.000 Zeilen erreichten.
• Die Verifizierung zielte auf RISC-V-Assemblercode ab und bewies, dass keine Abstürze bei Eingaben unter 64 MB unter Linux auftreten.
• Das Modell entdeckte und behob Fehler, die Billionen vorheriger Fuzz-Test-Läufe überlebt hatten.
• Das Vertrauen liegt in den formalen Modellen für RISC-V und Linux, den Theoremaussagen und dem Rocq-Beweisprüfer.
• Theorem veröffentlicht eine Claude-Skill, um Entwicklern bei der Anwendung ähnlicher Verifizierungsworkflows auf ihre eigenen Projekte zu unterstützen.

Warum es wichtig ist

Für Softwareingenieure senkt diese Entwicklung die Einstiegshürde für die formale Verifizierung, die historisch Jahre spezialisierter Expertise erforderte. Durch die Automatisierung der Beweiserstellung ermöglichen LLMs die Anwendung rigoroser Sicherheitsgarantien auf alltägliche Bibliotheken und Anwendungen. Dieser Wandel erlaubt Teams, über reaktives Bugfixing und proaktives Fuzzing hinaus zu einem Modell zu gehen, in dem kritische Komponenten mathematisch als sicher vor ganzen Klassen von Schwachstellen, wie z. B. Speicherfehlern, nachgewiesen werden.

Die Fähigkeit, kompilierte Binärdateien anstelle von nur Quellcode zu verifizieren, ist besonders signifikant. Das bedeutet, dass Sicherheitsmerkmale für die tatsächlichen, in der Produktion eingesetzten ausführbaren Artefakte garantiert werden können, wobei Compiler-Verhalten und Low-Level-Interaktionen berücksichtigt werden. Mit zunehmenden Modellfähigkeiten und verfügbaren Semantiken für weitere Architekturen könnte dieser Ansatz zum Standardteil des Softwareentwicklungszyklus werden und das Risiko von Exploits in weit verbreiteten Open-Source-Abhängigkeiten reduzieren.

Was Sie tun können

• Erkunden Sie die veröffentlichte Teilmenge der Beweise und die RISC-V-Semantiken, um die Struktur der KI-generierten formalen Verifizierung zu verstehen.
• Probieren Sie die neue Claude-Skill aus, die von Theorem veröffentlicht wurde, um mit Verifizierungsworkflows in Ihren eigenen Codebasen zu experimentieren.
• Überprüfen Sie die bestehenden Fuzz-Tests Ihres Projekts, da diese als Grundlage für formale Spezifikationen in zukünftigen Verifizierungsbemühungen dienen können.
• Erwägen Sie die Integration von Schritten zur formalen Verifizierung für kritische Bibliotheken in Ihrer Abhängigkeitskette, insbesondere für solche, die nicht vertrauenswürdige Eingaben verarbeiten.
• Bleiben Sie über Entwicklungen in den formalen Semantiken für RISC-V und Linux informiert, da die Erweiterung dieser Modelle den Umfang der verifizierbaren Software erweitern wird.
• Evaluieren Sie, ob Annahmen für single-threaded statische Binärdateien auf Ihre aktuellen Projekte zutreffen, als Ausgangspunkt für die Verifizierung.