Security-Agenten brauchen mehr als Schwachstellenbeschreibungen und Musterantworten. Sie müssen Quellcode untersuchen, Werkzeuge einsetzen, Builds reproduzieren, Hypothesen verwerfen und Ergebnisse technisch belegen. Genau hier setzt die Forschungsarbeit „CyberFactory: Scaling Cyber Security Capabilities with Instances from the Wild“ an: Sie verwandelt öffentliche Schwachstellenartefakte in ausführbare Aufgaben und maschinell prüfbare Agententrajektorien.
Für Unternehmen ist CyberFactory deshalb weniger ein neues Produkt als eine Blaupause für eine verifizierbare Datenfabrik. Der Ansatz verbindet Instanzaufbau, skill-geführte Trajektoriensynthese und Modelltraining für Proof-of-Concept-Reproduktion, Patching und Cybersecurity-Fragen. Der mögliche Nutzen liegt in besserem Trainingsmaterial. Das Risiko liegt darin, dass dieselbe Pipeline offensive Fähigkeiten erzeugen kann. Ein Pilot gehört daher ausschließlich in eine autorisierte, isolierte Forschungs- oder Verteidigungsumgebung.
Wie CyberFactory aus Schwachstellen prüfbare Aufgaben baut
Die Pipeline nutzt laut Autoren unter anderem ARVO, OSS-Fuzz und öffentlich dokumentierte CVEs. Für eine Proof-of-Concept-Aufgabe rekonstruiert sie den verwundbaren und den gepatchten Programmstand. Ein Ergebnis gilt nur dann als erfolgreich, wenn es die Zielschwachstelle im alten Build auslöst und im reparierten Build nicht mehr. Dieses Differential-Orakel reduziert ein zentrales Datenproblem: Ein beliebiger Absturz wird nicht automatisch als Beweis für die gesuchte Lücke akzeptiert.
Während der Datenerzeugung erhält ein Lehrmodell einen wiederverwendbaren Analyse-Skill. Er strukturiert Quellcodeprüfung, domänenspezifische Suche, Validierung und Überarbeitung, verrät aber keine instanzspezifische Lösung. Behalten werden nur Trajektorien, die das jeweilige ausführbare Kriterium erfüllen. Anschließend wird OpenAegis auf den verifizierten Abläufen feinabgestimmt. Nach Darstellung der Autoren zeigt das Modell den erlernten Analyse-Workflow auch ohne den Skill-Prompt zur Laufzeit.
Benchmark-Zahlen nur mit Versionsangabe verwenden
Der aktuelle arXiv-Stand ist Version 3 vom 1. September 2026. Dessen Abstract berichtet für OpenAegis 52,4 Prozent Pass@1 im CyberGym bei einem Zeitbudget von einer Stunde. Das sind 22,8 Prozentpunkte mehr als beim zugrunde liegenden Qwen-3.5-Modell unter demselben Scaffold. Die Hugging-Face-Seite enthält im begleitenden Community-Abschnitt zusätzlich noch 58,1 Prozent und +28,5 Punkte für eine Konfiguration mit Kontextkompression. Diese Werte dürfen nicht ohne Konfigurations- und Versionsangabe vermischt werden.
Auch 52,4 Prozent bedeuten, dass ein erheblicher Teil der Aufgaben im ersten Versuch ungelöst bleibt. Pass@1 misst zudem Benchmark-Erfolg, nicht automatisch Patch-Qualität, geringe Fehlalarmrate oder sicheren Produktionsbetrieb. Bestätigt ist ein Autorenresultat in einer kontrollierten Evaluation. Daraus lässt sich plausibel ein Pilot ableiten, aber weder autonome Einsatzreife noch ein wirtschaftlicher Vorteil für eine konkrete Unternehmensumgebung.
- Kennzahl immer zusammen mit Paper-Version, Modell-Checkpoint, Scaffold und Zeitbudget speichern.
- PoC-Reproduktion, Patch-Erfolg und CyberQA als getrennte Fähigkeiten auswerten.
- Pass@1 durch Fehlalarmrate, Kosten je verifizierter Trajektorie und menschliche Befundprüfung ergänzen.
- Benchmark-Aufgaben strikt von internen Testfällen und einem unangetasteten Holdout trennen.
Wann sich ein Unternehmenspilot lohnt
- Ein Security-Team betreibt bereits reproduzierbare Build-, Fuzzing- oder Patch-Validierungsumgebungen.
- Es gibt einen klar begrenzten defensiven Zweck, etwa Patch-Verifikation in eigener Software oder autorisierten Open-Source-Komponenten.
- Verwundbare und gepatchte Zustände lassen sich deterministisch bauen und ohne externe Produktionssysteme testen.
- Rechenumgebung, Netzwerkzugriff, Secrets und Artefaktexport können technisch isoliert und protokolliert werden.
- Menschen mit Anwendungssicherheitskompetenz können Ergebnisse prüfen und falsche Beweise erkennen.
- Rechts-, Lizenz- und Offenlegungsprozesse für gefundene Schwachstellen sind vorab definiert.
Fehlen reproduzierbare Builds oder belastbare Orakel, sollte das Unternehmen nicht mit Modelltraining beginnen. Dann ist der wertvollere erste Schritt, bestehende Sicherheitsfälle in ausführbare Regressionstests zu überführen. Diese Tests verbessern bereits den normalen Secure-Development-Lifecycle und können später kontrolliert als Evaluationsbasis für Agenten dienen.
Fünf Phasen für einen isolierten Pilot
- Zweck begrenzen: Nur eigene oder ausdrücklich autorisierte Software einbeziehen. Der Pilot startet mit Patch-Verifikation, nicht mit freier Zielsuche.
- Labor isolieren: Verwundbare Builds in kurzlebigen Sandboxes ausführen, ausgehenden Netzwerkverkehr standardmäßig sperren, keine Produktionszugänge bereitstellen und alle Werkzeuge allowlisten.
- Instanzen qualifizieren: Für jeden Fall Build-Reproduzierbarkeit, Zielabsturz, gepatchten Gegenbeweis und erlaubte Artefakte dokumentieren. Unklare Fälle nicht als Trainingsdaten verwenden.
- Trajektorien im Shadow Mode erzeugen: Lehrmodell und Agent beobachten, aber keine externen Aktionen erlauben. Nur maschinell bestandene und menschlich stichprobengeprüfte Abläufe freigeben.
- Klein trainieren und getrennt evaluieren: Zuerst Adapter oder begrenzte Checkpoints testen. Ein unangetastetes Set, bekannte Negativfälle und missbräuchliche Prompts prüfen; bei Regelverstoß auf den Ausgangsstand zurückrollen.
Ein Freigabe-Scoreboard sollte mindestens sechs Größen enthalten: Anteil reproduzierbarer Instanzen, Präzision des Differential-Orakels, Pass@1 je Aufgabentyp, falsche Schwachstellenmeldungen, GPU- und Agentenkosten je akzeptierter Trajektorie sowie Anzahl menschlicher Korrekturen. Zusätzlich ist zu prüfen, ob der Agent außerhalb des vorgegebenen Scopes agiert oder versucht, Netzwerk- und Werkzeuggrenzen zu umgehen.
Betriebs- und Dual-Use-Risiken
Die technische Verifikation löst nicht jedes Sicherheitsproblem. Ein PoC kann korrekt sein und dennoch unnötig gefährliche Details enthalten. Ein Patch kann den Test bestehen, aber eine Variante der Lücke offenlassen. Trainingsdaten aus öffentlichen Repositories können Lizenz-, Herkunfts- oder Kontaminationsfragen aufwerfen. Deshalb brauchen Datensatz, Build-Container, Skill-Version, Modell-Checkpoint und Evaluationscode einen gemeinsamen Prüfpfad.
Besonders kritisch ist die Fähigkeitseskalation. Ein besserer defensiver Agent kann zugleich Exploit-Reproduktion und Werkzeugnutzung verbessern. Unternehmen sollten Gewichte, Datensätze und ausführbare Artefakte daher nach Risiko klassifizieren, Zugriffe personengebunden vergeben und Exporte genehmigungspflichtig machen. Produktionssysteme, fremde Ziele und offenes Internet bleiben außerhalb des Piloten. Ein menschlicher Verantwortlicher muss jeden Befund und jede Weitergabe freigeben.
Fazit: Erst das Orakel, dann das Modell
CyberFactory zeigt einen nachvollziehbaren Weg von realen Schwachstellenartefakten zu verifizierbaren Agentendaten. Der stärkste Unternehmensnutzen liegt nicht im sofortigen Einsatz von OpenAegis, sondern in der systematischen Verbindung von reproduzierbaren Umgebungen, Differential-Tests und überprüften Trajektorien. Wer einen Pilot startet, sollte deshalb zuerst Isolation und Orakelqualität belegen, Kennzahlen an Versionen binden und Modellfortschritt nur innerhalb eines defensiven, menschlich kontrollierten Rahmens bewerten.