OSS-CRS: Liberating AIxCC Cyber Reasoning Systems for Real-World Open-Source Security

Die Arbeit stellt OSS-CRS vor, ein offen zugängliches, lokal einsetzbares Framework, das die zuvor an die DARPA-Cloud gebundenen KI-gestützten Cyber-Reasoning-Systeme für reale Open-Source-Projekte nutzbar macht und dabei erfolgreich neue Sicherheitslücken aufdeckt.

Das Wesentliche

Stell dir vor, du hast eine riesige Bibliothek voller Bücher (das sind die Open-Source-Softwareprojekte im Internet). In diesen Büchern gibt es manchmal Fehler, die wie unsichtbare Fallen sind. Wenn jemand in diese Fallen tritt, kann das ganze Buch kaputtgehen oder gestohlen werden.

Vor kurzem gab es einen großen Wettbewerb (den „AI Cyber Challenge"), bei dem sieben Teams super-intelligente Roboter gebaut haben. Diese Roboter waren Meister darin, diese Fallen zu finden und sie sofort zu reparieren. Das war eine riesige Sensation!

Aber hier kommt das Problem: Als der Wettbewerb vorbei war, haben die Teams ihre Roboter zwar veröffentlicht, aber sie waren wie hochspezialisierte Rennwagen, die nur auf einer ganz bestimmten, abgerissenen Rennstrecke fuhren. Die Rennstrecke (die Cloud-Infrastruktur des Wettbewerbs) existiert heute nicht mehr. Niemand kann diese Roboter zu Hause auf der normalen Straße fahren lassen. Sie sind nutzlos für die Allgemeinheit.

Das ist genau das Problem, das die Autoren dieses Papiers lösen wollen.

Die Lösung: OSS-CRS – Der „Universal-Adapter" für Sicherheits-Roboter

Die Forscher haben ein neues System namens OSS-CRS gebaut. Stell dir das wie einen großen, flexiblen Baukasten oder eine universelle Steckdose vor.

Hier ist, wie es funktioniert, einfach erklärt:

1. Das Problem: Jeder hat sein eigenes Werkzeug

Früher hat jedes der sieben Teams sein eigenes Haus gebaut, um seine Roboter unterzubringen.

• Team A hat eine eigene Stromleitung verlegt.
• Team B hat eine eigene Wasserversorgung gebaut.
• Team C hat eine eigene Sicherheitsanlage installiert.
  Alle haben im Grunde das Gleiche gemacht, aber jeder auf seine eigene, komplizierte Art. Wenn du einen Roboter von Team A nehmen und bei Team B einsetzen wolltest, passte er nicht. Er brauchte die spezielle Stromleitung von Team A.

OSS-CRS baut nun ein gemeinsames Fundament. Es ist wie ein riesiger Park, in dem alle Roboter auf demselben Boden laufen können. Jeder Roboter muss sich nur noch an die Regeln dieses Parks halten, nicht mehr an die speziellen Regeln seines alten Teams.

2. Die drei großen Hindernisse, die sie beseitigt haben

Die Autoren haben drei Hauptprobleme identifiziert, die die Roboter bisher festhielten:

• Der „Doppelte Bau"-Effekt (Infrastruktur-Duplizierung): Jeder hat sein eigenes Haus gebaut. OSS-CRS sagt: „Nein, wir bauen ein großes Haus für alle." Das spart Zeit und Geld.
• Die „Wolken-Falle" (Cloud Lock-in): Die Roboter waren so gebaut, dass sie nur in der „Wolke" (der Cloud des Wettbewerbs) leben konnten. Wenn die Wolke verschwand, starben die Roboter. OSS-CRS erlaubt es ihnen, lokal zu laufen – also direkt auf deinem eigenen Computer oder Server, ohne eine teure Cloud zu brauchen.
• Der „Einzelkämpfer"-Effekt (Monolithisches Design): Die Roboter waren wie ein einziger, riesiger Steinblock. Man konnte keine Teile austauschen. Wenn Team A einen besseren „Fehlerfinder" hatte und Team B einen besseren „Reparateur", konnte man sie nicht kombinieren. OSS-CRS zerlegt diese Steine in Bausteine. Jetzt kannst du den Fehlerfinder von Team A nehmen und den Reparateur von Team B dazu stecken. Sie arbeiten zusammen wie ein Team von Spezialisten.

3. Wie funktioniert das im Alltag? (Die Analogie der Werkstatt)

Stell dir OSS-CRS als eine moderne Autowerkstatt vor:

• Der Kunde (Du): Du bringst ein Auto (ein Software-Projekt) in die Werkstatt. Du sagst: „Bitte prüft dieses Auto auf Fehler."
• Die Roboter (Die CRSs): Verschiedene Spezialisten kommen rein.
  • Einer ist ein Fuzz-Tester (ein Roboter, der das Auto wild hin und her schüttelt, um zu sehen, ob etwas bricht).
  • Einer ist ein LLM-Analyst (ein Roboter, der mit künstlicher Intelligenz die Baupläne liest und sagt: „Aha, hier ist ein Riss!").
  • Einer ist ein Reparatur-Roboter, der den Riss schweißt.
• Der Manager (OSS-CRS): Der Manager sorgt dafür, dass:
  • Jeder Roboter genau so viel Benzin (Rechenleistung) und Geld (für KI-Abfragen) bekommt, wie er darf. Niemand darf das Budget sprengen.
  • Die Roboter sich nicht gegenseitig stören (sie haben eigene Werkbänke).
  • Wenn der Schüttel-Roboter einen Riss findet, gibt er das Auto dem Reparatur-Roboter weiter, ohne dass sie sich direkt unterhalten müssen. Sie tauschen nur die Werkzeuge und Teile über einen gemeinsamen Tisch aus.

4. Das Ergebnis: Es funktioniert wirklich!

Die Forscher haben den besten Roboter vom Wettbewerb (nämlich ATLANTIS) in dieses neue System eingebaut.

• Sie haben ihn auf 8 verschiedene, echte Open-Source-Projekte angesetzt.
• Das Ergebnis? Sie haben 10 bisher unbekannte Fehler gefunden. Drei davon waren sehr gefährlich (hohe Schwere).
• Der Roboter hat nicht nur die Fehler gefunden, sondern auch Reparaturanleitungen geschrieben, die die Entwickler der Software tatsächlich nutzen können.

Warum ist das wichtig?

Früher mussten Sicherheits-Experten warten, bis ein KI-System einen Fehler findet, und dann selbst mühsam den Code reparieren. Oder sie bekamen nur eine Liste von Fehlern, die sie erst verifizieren mussten.

Mit OSS-CRS können wir jetzt:

1. Echte Sicherheit: Die KI findet den Fehler und liefert sofort einen funktionierenden Reparatur-Patch.
2. Zugänglichkeit: Jeder kann diese Systeme nutzen, ohne Millionen in Cloud-Server zu investieren.
3. Zusammenarbeit: Wir können die besten Teile aller Wettbewerbs-Teams mischen, um einen „Super-Roboter" zu bauen, der besser ist als die Summe seiner Teile.

Zusammenfassend:
Die Autoren haben die „Rennwagen" der Sicherheits-KI aus dem abgerissenen Stadion geholt, ihnen neue Reifen und einen Motor für die normale Straße verpasst und ihnen erlaubt, als Team zu arbeiten. Das Ergebnis ist ein Werkzeug, das Open-Source-Software sicherer macht, ohne dass man ein IT-Genie sein muss, um es zu benutzen.

Technische Zusammenfassung

1. Problemstellung

Die DARPA AI Cyber Challenge (AIxCC) demonstrierte, dass autonome Cyber-Reasoning-Systeme (CRS) nicht nur Schwachstellen entdecken, sondern diese auch autonom bestätigen und patchen können. Sieben Finalistenteams entwickelten solche Systeme und veröffentlichten den Quellcode. Dennoch bleiben diese Systeme für die breite Gemeinschaft unbrauchbar, da sie an drei wesentliche Barrieren gebunden sind:

1. Infrastruktur-Duplikation: Jedes Team baute unabhängig voneinander die gleiche Plattform-Infrastruktur (z. B. Container-Orchestrierung, LLM-Gateways, Budget-Tracking) nach.
2. Cloud-Lock-in: Alle Systeme waren stark an die spezifische Azure- und Kubernetes-Infrastruktur der AIxCC-Wettbewerbe gebunden, die nach dem Wettbewerb abgeschaltet wurde. Ohne diese Cloud-Umgebung sind die Systeme nicht lauffähig.
3. Monolithisches Design: Die Analyse-Techniken (Fuzzing, LLM-Reasoning, Patching) waren fest in monolithische Systeme integriert. Dies verhindert, dass Forscher Komponenten verschiedener Teams kombinieren oder vergleichen können.

Das Ergebnis ist eine „Adoption Gap": Die Technologie ist vorhanden, kann aber nicht in realen Open-Source-Projekten eingesetzt, verglichen oder weiterentwickelt werden.

2. Methodik: Das OSS-CRS-Framework

Um diese Barrieren zu überwinden, stellen die Autoren OSS-CRS vor, ein offenes, lokal bereitstellbares Framework. Es ist kein CRS selbst, sondern eine Infrastrukturplattform, auf der CRSs entwickelt, ausgeführt und kombiniert werden können.

Kernarchitektur und Design-Prinzipien:

• Einheitliches Ausführungsmodell: OSS-CRS führt ein dreiphasiges Lebenszyklus-Modell ein:
  1. Prepare: Build von CRS-Container-Images (unabhängig vom Zielprojekt).
  2. Build-Target: Kompilierung des Zielprojekts (basierend auf OSS-Fuzz-Standards).
  3. Run: Ausführung der Analyse-Kampagne in isolierten Containern.
• libCRS Schnittstelle: Eine Python-Bibliothek, die in jedes CRS-Container injiziert wird. Sie standardisiert die Interaktion mit der Infrastruktur (z. B. submit-build-output, apply-patch-build, run-pov). Dies entkoppelt die Analyse-Logik von der Infrastruktur.
• Ressourcen-Management:
  • Isolation: Jeder CRS läuft in einem eigenen Docker-Container mit isoliertem Netzwerk, CPU-Zuteilung (cpuset) und Speicherlimits (mem_limit).
  • LLM-Budget: LLM-Kosten werden als erste Klasse Ressource behandelt. Ein Proxy (basierend auf LiteLLM) verwaltet Budgets pro CRS und weist Anfragen ab, sobald das Limit erreicht ist.
• Artifact Exchange: Ein dateisystembasiertes Austauschmechanismus (via „Exchange Sidecar") ermöglicht es verschiedenen CRSs, Artefakte (Seeds, Proof-of-Vulnerability, Patches) zu teilen, ohne direkt miteinander zu kommunizieren. Dies fördert Ensemble-Methoden.
• Zielinterface: Das Framework nutzt das OSS-Fuzz-Format als Standard-Schnittstelle, sodass jedes integrierte CRS über 1.000 OSS-Fuzz-Projekte ohne projektspezifische Anpassungen testen kann.

3. Schlüsselbeiträge

1. Empirische Analyse: Eine detaillierte Untersuchung der Codebasen aller sieben AIxCC-Finalisten, die die drei oben genannten Barrieren (Infrastruktur-Duplikation, Cloud-Lock-in, Monolithisches Design) identifiziert und quantifiziert.
2. OSS-CRS Framework: Ein Open-Source-Framework, das diese Barrieren durch ein standardisiertes Interface, lokale Ressourcenisolierung und Budget-Management für CPU, Speicher und LLMs beseitigt.
3. Portierung und Validierung: Die erfolgreiche Portierung des Erstplatzierten Systems ATLANTIS auf OSS-CRS. Dies beweist, dass komplexe, cloud-abhängige Systeme in eine lokale, ressourcenkontrollierte Umgebung überführt werden können, ohne die Kern-Logik zu ändern.
4. Ensemble-Fähigkeit: Demonstration, wie verschiedene CRS-Techniken (z. B. Fuzzer und Patch-Generatoren) über das Framework kombiniert werden können.

4. Ergebnisse

Die Autoren führten eine Validierung durch, bei der die portierte Version von ATLANTIS gegen 8 verschiedene OSS-Fuzz-Projekte (C/C++ und Java) getestet wurde.

• Entdeckte Schwachstellen: Es wurden 10 bisher unbekannte Zero-Day-Schwachstellen entdeckt.
  • Davon sind 3 von hoher Schwere (High Severity).
  • Die Bugs umfassen Speichersicherheitsprobleme, Logikfehler und undefiniertes Verhalten (z. B. CWE-476, CWE-674, CWE-681).
• Patching: Das System generierte nicht nur Beweise für die Verwundbarkeit (PoV), sondern auch validierte Patches.
• Status der Meldung: Zum Zeitpunkt der Veröffentlichung waren 3 Fehler bereits von den Maintainer-Teams behoben, einer bestätigt und 6 in Prüfung.
• Effizienz: Die Portierung von ATLANTIS erforderte nur etwa 3–4 Personentage pro Subsystem, wobei sichergestellt wurde, dass die Kern-Analysealgorithmen unverändert blieben. Das System lief erfolgreich auf einer einzelnen Maschine (32 CPU-Kerne, 128 GB RAM) ohne Cloud-Infrastruktur.

5. Bedeutung und Ausblick

Das Paper zeigt, dass die fortschrittlichen Techniken von Wettbewerbs-CRSs nicht an die spezifische Wettbewerbsinfrastruktur gebunden sein müssen.

• Demokratisierung der Sicherheit: OSS-CRS ermöglicht es der Sicherheitsgemeinschaft, die besten Komponenten verschiedener Teams zu kombinieren, ablation studies durchzuführen und die Systeme unter kontrollierten Bedingungen zu vergleichen.
• Praktische Anwendbarkeit: Es beweist, dass autonome Schwachstellenfindung und -behebung in realen Open-Source-Projekten ohne massive Cloud-Ressourcen durchführbar sind.
• Zukünftige Arbeit: Die Autoren planen die Integration weiterer Finalisten-Systeme, die Entwicklung eines Benchmark-Suites (ähnlich wie FuzzBench) für CRSs und die Erweiterung auf eine breitere Palette von Open-Source-Projekten.

Zusammenfassend stellt OSS-CRS einen entscheidenden Schritt dar, um die Lücke zwischen akademischen Wettbewerbs-Erfolgen und der praktischen, skalierbaren Anwendung von KI-gestützter Cybersicherheit in der realen Welt zu schließen.