KI entdeckt Zero-Days schneller, als Teams reagieren können: So bereitet man die Pipeline vor

Anthropics Mythos-Preview-Modell hat kürzlich Tausende von Zero-Day-Schwachstellen in allen wichtigen Betriebssystemen und Webbrowsern identifiziert – darunter ein OpenBSD-Fehler, der 27 Jahre lang unentdeckt blieb. In Tests verknüpfte Mythos autonom vier Schwachstellen zu einem funktionierenden Browser-Exploit, der seine Sandbox verließ. Anthropic schränkt den Zugang zu Mythos ein, doch der Leiter der offensiven Cyber-Forschung des Unternehmens erwartet, dass vergleichbare Werkzeuge innerhalb von sechs bis zwölf Monaten in Angreiferhänden sein werden.

Die Verteidigungsseite hat nicht Schritt gehalten. Ein Drittel der ausgenutzten CVEs im ersten Halbjahr 2025 zeigte Aktivität vor oder am Tag der Offenlegung – bevor die meisten Teams überhaupt wissen, dass es etwas zu patchen gibt. KI komprimiert dieses Fenster weiter, beschleunigt Angreifer und überschwemmt Teams mit Whitehat-Meldungen schneller, als sie triagiert werden können. Defender-Werkzeuge haben sich verbessert, doch die meisten Unternehmen können sie nicht schnell genug operationalisieren, um die Lücke zwischen Entdeckung und Ausnutzung zu schließen.

Wenn das Fenster zwischen Offenlegung und Ausnutzung in Stunden gemessen wird, kann das Sicherheitsteam nicht die letzte Verteidigungslinie sein. Sicherheit muss dort greifen, wo Code in das System eintritt: in der Pipeline, bei jedem Merge Request, durch Richtlinien durchgesetzt. Was automatisiert werden kann, sollte automatisiert werden. Was es nicht kann, muss schneller als heute den richtigen Menschen erreichen.

Bekannte Schwachstellen übersteigen bereits die Remediation-Kapazitäten

Der Engpass ist nicht die Erkennung – sondern das Handeln im erforderlichen Umfang auf Basis bereits bekannter Informationen. 60 % der Sicherheitsverletzungen im Verizon DBIR 2025 betrafen die Ausnutzung bekannter Schwachstellen, für die bereits ein Patch verfügbar war. Teams konnten sie nicht rechtzeitig schließen.

Der Rückstand war bereits vor Mythos untragbar. Entwicklungsteams verbringen 11 Stunden pro Monat mit der Behebung von Schwachstellen nach dem Release – statt neue Funktionen zu liefern. Über die Hälfte der Unternehmen hat mindestens eine internetexponierte Schwachstelle offen, und der mediane Zeitraum zur Schließung der Hälfte dieser Schwachstellen beträgt 361 Tage. Ausnutzung dauert Stunden, Remediation dauert Monate.

KI-gestützte Entwicklung vergrößert die Lücke – und Verantwortliche sind sich dessen bewusst. Bis Juni 2025 fügte KI-generierter Code über 10.000 neue Security-Findings pro Monat in Fortune-50-Repositories hinzu – ein zehnfacher Anstieg gegenüber sechs Monaten zuvor. Georgia Tech identifizierte im März 2026 34 CVEs mit nachweisbarem KI-Ursprung, gegenüber 6 im Januar. Diese Zahl erfasst nur die Fälle, in denen die KI-Urheberschaft eindeutig nachweisbar ist. KI-Coding-Assistenten halluzinieren Paketnamen, greifen auf veraltete Muster zurück und kopieren unsichere Beispiele aus Trainingsdaten. Mehr Code, mehr Abhängigkeiten und mehr Schwachstellen pro Zeile werden schneller erzeugt, als Sicherheitsteams sie prüfen können.

Verteidiger müssen sich ebenfalls frontier KI-Modelle zunutze machen – nicht als externe Werkzeuge, die nachträglich an den SDLC angedockt werden, sondern als integrale Bestandteile derselben Richtlinien, Freigaben und Audit-Trails wie der Rest des Teams.

Sicherheit im Tempo von KI-gestützter Entwicklung

Wenn eine kritische CVE bekannt wird: Wie schnell kann das Team bestätigen, welche Projekte betroffen sind? Wie viele Werkzeugwechsel durchläuft ein Alert, bevor ein Entwickler mit der Behebung beginnen kann?

Teams, die am meisten von KI profitieren, haben Richtlinien, Durchsetzungsmechanismen und Kontrollen bereits in ihre Entwicklungs-Workflows eingebettet. KI verstärkt dieses Fundament. Sie ersetzt es nicht.

Durchsetzung am Punkt der Änderung. Wenn Ausnutzungsfenster schrumpfen, muss jede Codezeile, die in ein Repository eingeht, einen definierten Kontrollsatz durchlaufen – keine separate Prüfung, in einem anderen Werkzeug, durch ein anderes Team. Unternehmen benötigen die Möglichkeit, Sicherheitsrichtlinien über alle Gruppen und Projekte hinweg durchzusetzen, mit dem Merge Request als Durchsetzungspunkt. Richtlinien einmal definiert, überall angewendet, Ausnahmen geprüft, genehmigt und protokolliert.

Einfache Probleme vor dem Merge Request abfangen. Hardcodierte Secrets, bekannt-vulnerable Importe und veraltete API-Aufrufe können in der IDE markiert werden, bevor ein Commit gepusht wird. Das Abfangen zum Zeitpunkt der Erstellung bedeutet weniger Findings, die den MR blockieren – so dass Review-Zyklen für Findings reserviert bleiben, die komponentenübergreifenden Kontext erfordern: Erreichbarkeit, Ausnutzbarkeit und architektonisches Risiko.

Triage standardmäßig automatisiert. Sicherheit in jeden Merge Request einzubetten erzeugt ein Volumenproblem. Mehr Scans, mehr Findings, mehr Lärm erreicht Entwicklungsteams, die nicht geschult sind, eine erreichbare kritische Schwachstelle von einer theoretischen zu unterscheiden. KI muss False-Positive-Erkennung, Erreichbarkeit, Ausnutzbarkeitskontext und Schweregradbewertung übernehmen, bevor ein Entwickler das Finding sieht – damit die Findings, die ihn erreichen, tatsächlich seine Zeit rechtfertigen.

Remediation wie jede andere Änderung verwaltet. KI-gestützte Remediation komprimiert den Zeitrahmen zum Schließen von Schwachstellen, aber jeder generierte Fix muss denselben Governance-Prozess durchlaufen wie eine menschlich erstellte Änderung: Richtlinien erzwingen Scans, die richtigen Prüfer genehmigen, und Nachweise werden aufgezeichnet. GitLabs automatisierte Remediation schlägt jeden Fix in einem Merge Request mit einem Konfidenzwert vor. Der MR dokumentiert, welche Richtlinie angewendet wurde, welche Scans durchgeführt wurden, was sie gefunden haben und wer genehmigt hat. Menschlich erstellter Code und KI-generierter Code durchlaufen denselben Prozess – mit demselben Audit-Trail.

So sieht eine vorbereitete Pipeline aus

Ein Proof-of-Concept-Exploit für eine Schwachstelle in einem verbreiteten Open-Source-Paket erscheint auf einer Security-Mailingliste. Es gibt noch keine CVE, keinen NVD-Eintrag und keine Scanner-Signatur. Das Sicherheitsteam erfährt es auf dem üblichen Weg: jemand teilt es in Slack.

Ein Security-Engineer fragt den Security-Agenten, ob das Paket verwendet wird, welche Projekte betroffene Versionen haben und ob verwundbare Call-Pfade in der Produktion erreichbar sind. Der Agent prüft den Dependency-Graphen jedes Projekts, gleicht die betroffenen Versionen und Einstiegspunkte aus der Meldung ab und gibt eine priorisierte Liste exponierter Projekte mit Details zur Erreichbarkeit zurück. Eine manuelle Suche in Repositories oder das Warten auf ein Scanner-Update entfällt. Die Frage „Sind wir betroffen?" ist in Minuten beantwortet.

Der Engineer startet eine Remediation-Kampagne für alle exponierten Projekte. Der Remediation-Agent schlägt Fixes vor: Versions-Updates, wo ein gepatchtes Release verfügbar ist, und Patches für verwundbare Call-Pfade, wo es keines gibt. Scan-Execution-Policies sind bereits für Projekte mit ISO-27001-Zertifizierung aktiv. Der Engineer verschärft die Regeln, um Merges bei jedem Merge Request zu blockieren, der die betroffene Abhängigkeit einführt oder beibehält. Eine Approval-Policy erfordert nun Security-Freigabe für jeden Fix. Der erste vorgeschlagene Patch schlägt in der Pipeline fehl, weil ein Integrationstest eine Regression aufdeckt. Der Agent überarbeitet den Patch auf Basis des Testergebnisses, der zweite Versuch besteht. Das Entwicklungsteam prüft die Änderungen, Security gibt unter der verschärften Richtlinie frei, und Merges erfolgen über die gesamte Kampagne hinweg.

Beim nächsten Audit-Review legt das Sicherheitsteam einen Bericht vor, der zeigt, wie Richtlinien durchgesetzt und Risiken während der Kampagne reduziert wurden. Er enthält Scan-Ergebnisse, angewendete Richtlinien, Genehmiger und Merge-Zeitstempel für jeden MR in jedem betroffenen Projekt. Die Nachweise wurden automatisch während des Prozesses erzeugt – nicht im Nachhinein zusammengestellt.

Handlungsfelder jetzt identifizieren

Mythos existiert heute, und vergleichbare Modelle werden innerhalb eines Jahres in Angreiferhänden sein. Jeder Monat bis dahin ist eine Gelegenheit, die Software-Lieferkette zu stärken.

Diese Fragen zeigen, wo die Pipeline steht:

• Wie wird sichergestellt, dass Sicherheitsscans bei jedem Merge Request durchgeführt werden – nicht nur in Projekten, in denen Teams sie konfiguriert haben?
• Wenn ein kompromittiertes Paket heute in den Dependency-Tree eingeht – würde die Pipeline es vor dem Build abfangen?
• Wenn ein Scanner ein kritisches Finding meldet: Wie viele Werkzeugwechsel durchläuft es, bevor ein Entwickler mit der Behebung beginnt?
• Wenn ein KI-Agent einen Code-Fix für eine Schwachstelle vorschlägt – welchen Prozess durchläuft dieser Fix vor dem Erreichen der Produktion, und ist dieser Prozess auditierbar?
• Wenn Auditoren den Nachweis verlangen, dass eine bestimmte Richtlinie auf eine bestimmte Änderung angewendet wurde – wie lange dauert die Bereitstellung?

Wo diese Fragen Lücken aufzeigen, empfiehlt sich gezielte Maßnahmen. Mit einem GitLab Solutions Architect sprechen – zur Rolle von Security-Governance im Entwicklungs-Lifecycle.