KI-Agenten finden Zero-Days schneller, als Sicherheitsteams sie verwalten können
Ein Sicherheits-Startup meldete gerade 21 bisher unbekannte Schwachstellen in FFmpeg, einer der am weitesten verbreiteten Medienbibliotheken im Internet.
Das Unangenehme war nicht nur die Anzahl der Fehler.
Es war, wie sie gefunden wurden.
Ein autonomer KI-Sicherheitsagent durchsuchte etwa 1,5 Millionen Zeilen C-Code, erzeugte reproduzierbare Proof-of-Concept-Eingaben und meldete bestätigte Zero-Days für etwa 1.000 US-Dollar Rechenkosten. In derselben Woche patchte Google rekordverdächtige 429 Chrome-Sicherheitslücken, nachdem das Bug-Bounty-Programm auf die Flut von KI-generierten Meldungen umgestellt wurde.
Das ist keine kleine Produktivitätssteigerung. Es ist ein neues Betriebstempo für die Entdeckung von Schwachstellen.
Für CISOs ist die Frage nicht mehr, ob KI bei der Entdeckung von Sicherheitsproblemen helfen kann. Das kann sie eindeutig. Die schwierigere Frage ist, ob die Organisation eine Governance hat, die mit dem erhöhten Volumen, der Geschwindigkeit und der Unschärfe von KI-basierten Sicherheitsfunden Schritt halten kann.
Der Zero-Day-Flaschenhals verschiebt sich
Jahrelang war die Entdeckung der Engpass im Schwachstellenmanagement.
Das Finden eines bedeutenden Fehlers erforderte bisher selten menschliche Expertise, Zeit und tiefgehende Vertrautheit mit einer Codebasis. Diese Einschränkung prägte, wie Sicherheitsteams Risiken bewerteten. Man konnte Prioritäten basierend auf bekannten CVEs, Herstellerhinweisen, Exploit-Aktivitäten und Asset-Exposition setzen, weil der Strom neuer Erkenntnisse zwar laut, aber dennoch einigermaßen begrenzt war.
KI verändert diese Einschränkung.
Wenn ein autonomer Agent ein großes Open-Source-Projekt scannen und schnell dutzende plausible Erkenntnisse liefern kann, verschiebt sich der begrenzende Faktor von der Entdeckung hin zur Validierung, Priorisierung, Verantwortlichkeit, Offenlegung und Behebung.
Das klingt nach operativem Management. Es ist tatsächlich Governance.
Wer darf autonome Schwachstellenforschung an internem Code durchführen? Auf welche Systeme darf der Agent zugreifen? Was passiert, wenn der Agent einen Fehler in einer Drittanbieter-Abhängigkeit, einem kundenorientierten Workflow oder einem regulierten System findet? Wer überprüft den Proof of Concept, bevor er gespeichert, geteilt oder eskaliert wird? Wie verhindert man, dass sensibler Code, Geheimnisse oder Exploit-Details während des Prozesses in nicht verwaltete KI-Tools eingefügt werden?
Die meisten Unternehmen haben darauf noch keine klaren Antworten.
KI-generierte Sicherheitserkenntnisse schaffen ein Vertrauensproblem
KI findet nicht nur Probleme. Sie erzeugt Arbeit.
Einige Erkenntnisse sind echt. Einige sind Duplikate. Einige haben geringe Auswirkungen. Einige sind subtil falsch. Einige enthalten Proof-of-Concept-Artefakte, die bei unsachgemäßem Umgang Risiken schaffen. Einige wirken dringend, weil der Agent mit Selbstvertrauen schreibt, auch wenn die Ausnutzbarkeit unklar ist.
Das schafft ein neues Vertrauensproblem im Sicherheitsteam.
Wenn jeder Entwickler, Red Teamer, Anbieter und externe Forscher KI nutzen kann, um Sicherheitsberichte in großem Umfang zu generieren, brauchen Security Operations eine Möglichkeit, Signal von Automatisierungsrauschen zu trennen, ohne die Verantwortlichen für die Prüfung zu überlasten.
Hier sind viele KI-Governance-Programme noch zu eng gefasst. Sie konzentrieren sich darauf, ob Mitarbeiter ChatGPT, Claude, Gemini oder Copilot nutzen dürfen. Das ist wichtig, aber nicht ausreichend.
Das größere Problem ist, dass KI selbst Teil des Sicherheits-Workflows wird. Sie führt Tests durch, erstellt Berichte, schreibt Proof-of-Concept-Code, fasst Schwachstellen zusammen, schlägt Lösungen vor und berührt manchmal sensiblen Quellcode oder Produktionskontexte.
Dieser Workflow braucht Transparenz.
Shadow-KI umfasst jetzt auch Schatten-Sicherheitstools
Sicherheitsteams sprechen oft von Shadow-KI als Problem der Fachanwender: Mitarbeiter fügen Kundendaten in nicht genehmigte Tools ein, Marketingteams nutzen KI-Apps, Analysten laden Tabellen hoch usw.
Aber dasselbe Muster zeigt sich auch in technischen Teams.
Ein Entwickler nutzt einen Agenten, um ein Repository zu prüfen. Ein Sicherheitsanalyst verwendet ein Modell, um verdächtigen Code zusammenzufassen. Ein Red Teamer bittet ein KI-Tool, Exploit-Payloads zu verändern. Ein Ingenieur lädt Protokolle hoch, um die Ursachenanalyse zu beschleunigen. Ein Auftragnehmer nutzt seinen bevorzugten KI-Assistenten, um ein Abhängigkeitsproblem zu überprüfen.
Keines dieser Verhaltensweisen ist automatisch böswillig. Viele sind sogar nützlich.
Wenn sie jedoch außerhalb genehmigter Workflows stattfinden, schaffen sie genau die Art von blinden Flecken, die KI-Governance reduzieren soll.
Das Risiko ist nicht nur Datenleckage. Es ist unkontrollierte Autorität:
- KI-Tools, die Quellcode, Zugangsdaten, Protokolle oder Architekturdetails erhalten
- Agenten, die Exploit-Material ohne klare Handhabungsregeln erzeugen
- Erkenntnisse, die ohne Herkunftsnachweis oder Vertrauensbewertung in Ticket-Queues gelangen
- Teams, die KI-generierte Empfehlungen ohne Prüfung umsetzen
- Sensibler Behebungskontext, der in persönlichen KI-Konten gespeichert wird
Deshalb ist das FFmpeg-Beispiel über Open-Source-Sicherheit hinaus relevant. Es zeigt, was passiert, wenn Schwachstellenerkennung billig und autonom wird. Dasselbe Muster wird in Unternehmensumgebungen auftreten, aber mit privatem Code, internen Systemen und regulierten Daten.
Richtlinien werden mit der Geschwindigkeit der Agenten nicht Schritt halten
Eine PDF-Richtlinie mit dem Hinweis „Keine sensiblen Daten in KI-Tools hochladen“ wird dieses Problem nicht lösen.
Sicherheitsteams brauchen Kontrollen dort, wo die Arbeit stattfindet.
Das bedeutet, zu wissen, welche KI-Tools genutzt werden, welche Identitäten darauf zugreifen, welche Datenarten durch sie fließen und welche Workflows Code, Protokolle, Tickets, Schwachstellen oder Kundenkontext betreffen.
Es bedeutet auch, sichere Wege zu schaffen statt pauschaler Verbote.
Wenn Mitarbeiter glauben, genehmigte Tools seien langsamer als der KI-Assistent, den sie bereits nutzen, umgehen sie die Richtlinie. Die Lösung ist nicht, jedes Experiment zu blockieren, sondern sichere, überwachte Möglichkeiten zu bieten, KI für Sicherheitsarbeit zu nutzen - mit klaren Grenzen für Daten, Aktionen, Speicherung und Prüfung.
Für autonome Sicherheitsagenten sollten Unternehmen definieren:
- Genehmigte Ziele: welche Codebasen, Systeme und Umgebungen Agenten testen dürfen
- Datenbegrenzungen: welche Quellcodes, Protokolle, Geheimnisse und Kundendaten geteilt werden dürfen
- Menschliche Prüfung: wer Erkenntnisse vor Eskalation oder Behebung validiert
- Umgang mit Artefakten: wie Proof-of-Concept-Code und Exploit-Eingaben gespeichert werden
- Offenlegungsregeln: wann Erkenntnisse Drittsoftware oder Open Source betreffen
- Audit-Trails: welcher Agent lief, unter wessen Autorität, gegen welches Asset und mit welchem Ergebnis
Ohne diese Struktur wird KI-gestützte Sicherheitsarbeit zu einer weiteren Form von Shadow-KI.
Die Frage für CISOs ändert sich
Früher lautete die Frage: „Nutzen unsere Teams KI-Tools?“
Die bessere Frage ist: „Welche KI-gesteuerten Workflows beeinflussen jetzt Sicherheitsentscheidungen, Codeänderungen, Schwachstellenmanagement oder Produktionsrisiken?“
Auf dieser Ebene muss Governance ansetzen.
KI-Agenten, die 21 Zero-Days in einer großen Bibliothek finden, sind beeindruckend. Es ist auch eine Warnung. Das Unternehmenssicherheitssystem rund um KI muss sich genauso schnell weiterentwickeln wie die Tools selbst.
Sonst wird der nächste Engpass nicht das Finden von Schwachstellen sein.
Sondern zu wissen, welchen KI-generierten Erkenntnissen man vertrauen kann, welche KI-Workflows sensible Daten berührt haben und welche Risiken Ihre Organisation unbeabsichtigt geschaffen hat, während sie schneller werden wollte.
Aona hilft Teams, diese Lücke zu schließen, indem es Sicherheitsverantwortlichen Einblick in die tatsächliche KI-Nutzung, Abweichungen zwischen Richtlinien und Verhalten sowie in Workflows gibt, in denen KI sensible Daten, Code und Geschäftsentscheidungen berührt.
Wenn Ihr KI-Governance-Programm dies noch als reines Zugriffsproblem auf Tools behandelt, ist es Zeit, den Blick zu erweitern.
