Anfang dieses Monats haben wir eine Bug-Bounty-Prämie in Höhe von 2,5 Millionen US-Dollar gewonnen – die höchste Prämie, die je von einem KI-Agenten erzielt wurde. Es handelte sich um einen Fehler in einer großen Blockchain, durch den über 100 Millionen US-Dollar an Geldern gefährdet waren. Wir fanden den Fehler vollständig autonom mit V12, unserem KI-Sicherheitsagenten, und arbeiteten mit dem Team zusammen, um das Problem zu beheben.
V12 ist kein generisches agentisches Sicherheitstool. Es findet regelmäßig kritische Bugs wie diesen, neben unzähligen 0-Days (darunter Linux-LPEs, QEMU-Escape, Firefox-UXSS, bidirektionale RCEs in Postgres und Redis). Das liegt daran, dass wir zwar ein Produkt entwickeln, unsere Hauptmission aber darin besteht, gefährlich mächtige offensive Sicherheitstools zu erforschen und zu bauen. Um das zu ermöglichen, haben wir eine 10-Millionen-Dollar-Seed-Runde abgeschlossen, angeführt von Electric Capital, mit Beteiligung von ZachXBT, samczsun, Walden Yan und weiteren.
Wir ermutigen dich, V12 selbst auszuprobieren. Es ist ein Self-Service-Produkt, und du bekommst bei der Anmeldung für die nächsten sieben Tage 200 US-Dollar kostenlose Nutzung.
Teil 1: Was wir tun
Unser Ziel ist es, eine Cyber-Nuke zu bauen. Das bedeutet, etwas zu entwickeln, das alle Bugs in einem System finden kann. Das ist besonders interessant, weil eine solche Fähigkeit es erlauben würde, Software auszunutzen, die zuvor als sicher galt. Das war bisher nicht möglich, aber die Grenzen der KI verändern das.
Wir betreiben kein Pentesting. Black-Box-Pentesting, das einen externen Angreifer simuliert, interessiert uns nicht. Das ist ein gesättigter Markt, und wir wollen kein weiteres Produkt bauen, das XSS-Payloads ausspuckt. Ein agentischer Pentest eignet sich hervorragend, um ein paar Bugs zu finden, aber wir wollen etwas, das alle Bugs findet. Das ist nicht möglich, ohne den Code zu lesen und zu verstehen. Wir müssen uns auf White-Box-Code-Audits konzentrieren, die eher wie Schwachstellenforschung aussehen.
Meme-Credit: LiveOverflow
Konkret sieht das wie ein System aus, das über Code und all seine zugrunde liegenden Abstraktionen nachdenken kann und sogar neue Abstraktionen erschafft (z. B. Weird Machines). Wir wollen ein System, das nicht nur Bugs findet, sondern komplett neue Bug-Klassen erfindet. Allerdings ist genau dieser Bereich der Sicherheit bisher am stärksten gegen Automatisierung resistent. Ein großer Teil der Schwachstellenforschung besteht darin, sorgfältig über Code nachzudenken und sich selbst zu beweisen: „Nein, das kann nicht anfällig sein“ – oder sich zu fragen: „Moment, was wäre, wenn…?“ All das erfordert menschliche Intelligenz, die es bisher nicht zu skalieren gab.
Kurz gesagt, was wir wollen, ist ein KI-System, das eine beliebig große und komplexe Codebasis aufnimmt, darüber nachdenkt, wie sie wirklich funktioniert, und dieses Verständnis nutzt, um Bugs und Exploits zu erfinden – nicht nur zu entdecken.
Natürlich ist ein System, das wirklich alle Bugs finden kann, nicht wirklich möglich; das ist das Halteproblem in Verkleidung. Es ist gleichbedeutend damit, zu beweisen, dass etwas keine Bugs hat, wobei Exploits die Gegenbeispiele sind. Man kann Programme bauen, die beliebig schwer auszunutzen sind. Zum Beispiel ein Programm, das anfällig ist, wenn die Collatz-Vermutung falsch ist. Aber wir haben vor, die Grenzen zu verschieben und die bestmögliche Annäherung zu bauen, die praktisch umsetzbar ist.
Und keiner, der uns den Weg weist
Angenommen, wir bauen tatsächlich die Cyber-Nuke. Was dann?
Angesichts einer Explosion offensiver Fähigkeiten wird sich die Welt drastisch verändern. Es ist jedoch unrealistisch zu erwarten, dass sich Entwickler – insbesondere Unternehmen – von allein plötzlich anpassen. Etablierten Organisationen fehlt die Vision oder das Fachwissen, um diesen Wandel wirklich zu vollziehen. Sie brauchen auch Lösungen – funktionierende, gut gestaltete Produkte – und nicht nur „Werkzeugsammlungen“.
Was die Anpassungsfähigkeit von Organisationen angeht: Es ist leicht, auf neue, hochmoderne Modelle zu verweisen und zu behaupten, das Cybersicherheitsproblem sei gelöst. Es ist aber etwas anderes, ob Entwickler diese Modelle sinnvoll einsetzen, um ihren Code abzusichern. Der durchschnittliche Entwickler bittet Claude oder Codex immer noch darum, „meinen PR auf Bugs zu überprüfen“ und dann „OK, behebe die“. Das ist bei Weitem nicht genug! Angreifer setzen bereits komplexe, aggressive Bug-Finding-Harnesses und -Pipelines ein. Hier herrscht eine Asymmetrie. Verteidiger haben weder die Ressourcen, solche Pipelines zu erstellen, noch können sie die Kosten über viele Bug-Hunting-Ziele amortisieren. Sie brauchen jemanden, der diese Modelle nutzt, einspannt und einsetzt, um ihr volles Potenzial auszuschöpfen.
In der Zwischenzeit sind die Leute beschäftigt. Sie sind überfordert, wenn sie versuchen, Deadlines einzuhalten und Features auf der Roadmap auszuliefern. Sie haben keine Zeit, über Sicherheit nachzudenken; sie wollen, dass jemand – oder etwas – hereinkommt und es für sie behebt. Es sollte sich direkt in ihre Organisation einbinden lassen (z. B. in ihren Slack), ihren Workflow verstehen (nutzt du GitHub? Wie werden Bugs zugewiesen? Was verwendest du für Issue-Tracking? Welche Agenten nutzt du?) und sich an ihren Kontext angepasst anfühlen.
Aus demselben Grund haben Verteidiger kaum eine Chance, es sei denn, sie haben ein Produkt, das sofort einsatzbereit ist. Es muss entweder vollständig im Self-Service-Modus nutzbar sein oder mit einer White-Glove-Implementierung kommen. Es sollte den richtigen Formfaktor haben (eine CLI? ein MCP? ein Slack-Agent? ein GitHub-Bot? alles davon?); es sollte sich gut anfühlen (nicht träge, funktioniert auf Mobilgeräten, die Buttons sind dort, wo man sie erwartet, …); es sollte nachvollziehbar sein (unaufdringliches Abrechnungsmodell, Zugriffskontrolle funktioniert angemessen, logische Auswahl des Audit-Umfangs, …). Es gibt eine Million Dinge, die bei einem solchen Produkt richtig sein müssen, damit es tatsächlich angenommen wird.
Kurz gesagt: Bau etwas, das beliebig komplexe Programme aufnimmt, vollständig über sie nachdenkt und neuartige Bugs findet. Verpacke diese Fähigkeit dann in ein nützliches Produkt und nimm Entwickler an die Hand, damit sie es tatsächlich nutzen und davon profitieren können.
Teil 2: Woran wir glauben
OK, aber wie machen wir das tatsächlich möglich? Ein konkreter Gameplan ist nutzlos (das ist ein Seed-Stage-Unternehmen). Es ist sinnvoller, unsere Leitprinzipien darzulegen und wie wir die Entwicklung der Welt vorhersagen.
Gegen den „Safetyism“
Zuerst glauben wir, dass der effizienteste Weg, die Software der Welt abzusichern, darin besteht, jedem die Fähigkeit zu geben, Bugs zu finden. Wir glauben nicht an „kontaktiert uns“ oder „beantragt Zugang“. Der logische Endzustand ist eine Welt, in der alle Bugs gefunden und gepatcht werden. Zugang zu beschränken verlangsamt diesen Prozess nur. Für Maintainer ist es unangenehm, aber unvermeidlich, sich auf eine neue Bedrohungslandschaft einzustellen, und wir denken, der beste Ansatz ist, einfach jetzt alle Bugs zu finden. In der Praxis bedeutet das, Verteidiger mit offensiven Fähigkeiten auszustatten, damit sie ihren eigenen Code härten können.
Um es klar zu sagen: Wir wollen, dass Software sicher und vertrauenswürdig ist. Es ist unverantwortlich, offensive Fähigkeiten freizusetzen, auf die die Welt nicht vorbereitet ist. Aber vieles von dem, was wir in letzter Zeit als „kontrollierten Zugang“ oder „Cyber-Verifizierung“ sehen, ist bloße Fassade und Marketing. Menschen nutzen Sicherheitsbedenken als Vorwand, um niemandem wirklich Zugang zu gewähren – und schützen dabei keine große Anzahl von Menschen. Allein in diesem Jahr hat V12 Nutzer mit über 6.000 Sicherheitsüberprüfungen geschützt. Wir sind nicht gegen Sicherheit, wir sind gegen gespielte Sicherheit.
Offene Offenlegung
Wir glauben an offene Offenlegung. Verantwortungsvolle Offenlegung wird als veraltete Methode zur Meldung und Behebung von Bugs angesehen werden. Embargos und koordinierte Offenlegung ergeben in einer Welt keinen Sinn, in der jeder mit den richtigen Werkzeugen eine Schwachstelle mit minimalem menschlichem Eingriff oder Fachwissen finden und ausnutzen kann. Das haben wir gesehen, als wir Fragnesia, Pintheft und DirtyDecrypt – Linux-LPE-0days – gefunden und gemeldet haben, die durchgesickert sind, bevor Patches in die Mainline-Kernel eingespielt wurden. Jeder kann öffentliche Commits überwachen und trivial einen Exploit nachbauen. Die einzige wirkliche Lösung ist, die Patch-Lücke vollständig zu beseitigen. In der Praxis sieht das so aus: häufigere (und automatische) Updates und Anbieter, die Patches noch am selben Tag (in derselben Stunde!) ausliefern, an dem ein Bug gefunden wird. Insbesondere bedeutet das, dass Verteidiger außergewöhnliche PoC- und Patch-Generierungsfähigkeiten benötigen.
Bug-Bounties sind tot
Bug-Bounties in ihrer heutigen Form werden tot sein, abgesehen von Programmen zum Ankauf von Schwachstellen für außergewöhnlich wertvolle Bugs. Alle anderen Bugs werden von offensiven Cyber-Tools wie V12 ausgemint, noch bevor der Code ausgeliefert wird – also bevor Angreifer überhaupt eine Chance haben, nach ihnen zu suchen.
Maintainer brechen unter der Last der KI-Bug-Bounty-Einreichungen zusammen. Viele haben angekündigt, Bug-Bounties komplett zu beenden. Jetzt, wo Bugs billiger als je zuvor sind, gibt es nur zwei Lösungen: (1) die meisten Bugs zu ignorieren oder (2) sie gar nicht erst auszuliefern. In der Vergangenheit waren beide Optionen unhaltbar, denn obwohl praktisch aller Code fehlerhaft ist, war es zu zeit- und kostenintensiv, über alle möglichen Bugs nachzudenken. Aber jetzt glauben wir, dass das nicht nur möglich, sondern unvermeidlich ist.
Crypto-Sicherheit ist interessant
Crypto-Projekte sind interessante Ziele und ein wichtiger Einstieg für unser Unternehmen. Wir sind besessen davon, alle Bugs zu finden, und Crypto ist derzeit der Bereich, in dem das am wichtigsten ist. Allein in diesem Jahr wurden durch Hacks mehr als 500 Millionen US-Dollar gestohlen. Wenn V12 in Crypto erfolgreich sein kann – wenn wir im „Hard Mode“ gewinnen können – dann können wir überall gewinnen.
Mit wenigen Ausnahmen (iOS Full Chain?) gibt es außerhalb von Crypto keine Bugs, die Belohnungen im sieben- oder achtstelligen Bereich einbringen. Außerhalb von Crypto gelten 50.000 US-Dollar immer noch als riesige Belohnung. In Crypto ist eine kritische Schwachstelle im Zusammenhang mit einem Verlust von Geldern, wenn sie ausgenutzt wird, Hunderte Millionen US-Dollar wert. Generell will niemand Sicherheit ernst nehmen, aber Crypto-Unternehmen sind dazu gezwungen. Das bedeutet: Wenn sie Sicherheitsprodukte auswählen, achten sie auf die Fähigkeit, Bugs zu finden, und weniger auf Dashboards – genau darauf ist V12 optimiert. Außerhalb von Crypto hingegen dreht sich Sicherheit immer noch um eine Compliance-Kultur, nicht um Substanz.
Alle Software ist anfällig, aber die Welt tut so, als wäre das nicht der Fall. Das hat bisher nur funktioniert, weil Angreifer selten waren – technisches Können war der Engpass. KI beseitigt diese Einschränkung. Wenn Software nicht sicher ist, wird sie jetzt ausgenutzt.
Die Auswirkungen werden dadurch verstärkt, dass die Welt zunehmend online ist und der Großteil der Welt mittlerweile praktisch „in einem Computer“ existiert. Alles wird sehr schnell viel sicherer werden müssen, und das sieht so aus, dass viele weitere Teams Sicherheit so ernst nehmen wie Crypto-Unternehmen.
Übrigens, um ein verbreitetes Missverständnis auszuräumen: Crypto-Codebasen sind in Größe, Komplexität und Vielfalt nicht trivial. Firedancer umfasst 722.000 Zeilen hochoptimierten C-Code, Geth + Prysm sind 1,1 Millionen Zeilen Go-Code, Zcash besteht aus 304.000 Zeilen C++ und Python (allein Orchard umfasst 44.000 Zeilen Circuits und Kryptografie in Rust). Alle enthalten virtuelle Maschinen, systemnahen Code und verteilte Datenbanken. Zum Vergleich: Postgres und CPython liegen beide bei etwa einer Million Zeilen Code.
Zeit für echte Sicherheit
Die Software der Welt war schon immer anfällig, aber jetzt kann man das nicht mehr ignorieren. Das moderne Web hängt von sicherer Kryptografie und Browsern ab, hochmoderne Modelle verlassen sich auf TEEs, um ihre Gewichte zu schützen, und Innovationen in der Robotik und Biologie werden Sicherheit nur noch wichtiger machen. Im Grunde wird aller Code irgendwann zu sicherheitskritischem Code.
Denk auch an die wachsende Komplexität von Software-Lieferketten. Eine Menge Code, an den wir nicht denken, wird (oder ist bereits) sicherheitskritisch. OpenSSH kommt einem sicher in den Sinn, aber was ist mit all den Paketen, die wir vergessen haben? Das Internet hängt von Software ab, auf die niemand schaut.
Die derzeitige Art, Sicherheit zu betreiben, wird nicht funktionieren. Sie ist ein nachträglicher Gedanke und wird auf Best-Effort-Basis durchgeführt. Teams konzentrieren sich auf die Entwicklung von Funktionen und machen Sicherheit zur Aufgabe von jemand anderem. Die meisten Sicherheitsprodukte wirken wie Pflaster, die die Symptome von Bugs behandeln, statt echte Lösungen zu sein. Aber in einer Welt mit mächtiger KI wird jemand einen Bug finden und ausnutzen, selbst wenn es nur ein einziger ist.
Stattdessen muss Sicherheit kontinuierlich und umfassend sein – jeder gemergte PR muss frei von Schwachstellen sein. Der Weg dorthin wird nicht einfach, und wir haben nicht alles herausgefunden. Das hat niemand. Aber das grundlegende Problem, auf das es hinausläuft – Bugs zu finden – ist das, was uns in den letzten 10 Jahren besessen hat. Vor V12 haben wir Zellic gegründet, eines der weltweit führenden Sicherheitsunternehmen, mit über 1.500 Sicherheitsüberprüfungen für über 500 häufig angegriffene Kunden (z. B. Krypto-Börsen, Brücken, L1s, Wallets, Open-Source-Betriebssysteme). Und davor haben wir perfect blue gegründet, das drei Jahre lang weltweit beste CTF-Team.
Jedes Mitglied des V12-Teams kommt entweder aus dem CTF-Bereich oder aus der Schwachstellenforschung. Schau dir an, was wir bisher gemeldet haben: mehrere Linux-LPEs, ein QEMU-Escape, wurmartige RCEs in Redis und PostgreSQL (bidirektional!), MariaDB und AnyDesk. Und was noch vielversprechender ist: Egal, auf welche neue Software wir V12 loslassen, es sprudeln immer wieder neue Bugs heraus: Dolphin-Emulator, die NAS eines Mitarbeiters, Signal-Messenger.
Abschließende Gedanken
Eine gute Seed-Runde gibt dir das Beste der Welt: die Chance, mit deinen Freunden etwas zu bauen, das du liebst.
Wir träumen von diesem Problem – automatisch alle Bugs zu finden – schon seit wir Teenager waren. Jetzt ist KI endlich mächtig genug, damit wir uns richtig daran versuchen können. Wir sind aufgeregt. Wenn wir recht haben, wird das, was wir bauen, gefährlich leistungsfähig sein, und die Welt wird sich daran anpassen.
Wir wollen diejenigen sein, die es möglich machen. Wenn V12 sich nach etwas anhört, bei dem du dabei sein möchtest: Komm zu uns, wir stellen ein!
