Warum AI-generierter Code Ihr Vulnerabilitätsmanagement-Modell bricht

AI-Code-Generatoren haben etwas erreicht, was Jahre von DevOps-Tooling nie ganz geschafft haben: Sie haben es ermöglicht, Funktionen in Tagen zu liefern, die früher Wochen dauerten. Das Problem ist, dass die Geschwindigkeit gleichermaßen auf die Schwachstellen anwendbar ist.

Über meine Jahre in der Cybersicherheit hinweg habe ich beobachtet, wie Organisationen durch das gleiche reaktive Muster zyklisch verlaufen: Eine Schwachstelle entdecken, sich bemühen, ihren Umfang zu verstehen, über die Verantwortung für die Behebung streiten und sie Wochen oder Monate später beheben. AI hat dieses Muster nicht geändert. Es hat es auf ein Tempo beschleunigt, bei dem das alte Modell nicht mehr mithalten kann. Der Branchendurchschnitt für die MTTR für kritische CVEs liegt über 60 Tagen. AI-gestützte Entwicklung gibt Ihnen keine 60 Tage. Sie gibt Ihnen eine neue Codebasis bei jedem Sprint.

Das Abhängigkeitsproblem ist jetzt ein AI-Problem

Sechsundneunzig Prozent der Unternehmensanwendungen enthalten Open-Source-Komponenten. Die meisten wurden nie gründlich geprüft, sondern einfach aus öffentlichen Registern gezogen, weil sie funktionierten und jemand sie an diesem Nachmittag benötigte. Sicherheitsteams haben in diesem Bereich jahrelang Boden verloren, und AI-Coding-Assistenten haben eine langsame Blutung in etwas viel Schwierigeres zu kontrollieren verwandelt.

Wenn ein Entwickler Code manuell schreibt, trifft er bewusste Entscheidungen über Abhängigkeiten. Wenn ein AI-Modell Code generiert, zieht es aus dem, worauf es trainiert wurde. Das bedeutet oft halluzinierte Pakete, veraltete Versionen oder Komponenten mit bekannten CVEs, die das Modell keinen Grund hatte, zu vermeiden. Der Code sieht sauber aus. Das Risiko ist in dem Abhängigkeitsbaum mehrere Ebenen tiefer verborgen und unsichtbar für jeden, der nicht speziell danach sucht.

Ich habe an Sicherheitsprüfungen teilgenommen, bei denen Teams schockiert waren, eine kritische CVE in einer transitiven Abhängigkeit eines Pakets zu finden, das sie Monate zuvor genehmigt hatten. Das Paket war in Ordnung. Was es mit sich brachte, war es nicht. Diese Dynamik spielt sich jetzt auf Maschineniveau ab, über Hunderte von Entwicklern, die AI-Tooling verwenden, das keine Vorstellung von der Sicherheitslage Ihrer Organisation hat.

Scannen nach dem Ereignis ist keine Strategie

Das vorherrschende Modell für Open-Source-Software-Sicherheit ist scan-and-patch: einen Scanner ausführen, die Ergebnisse triagieren, Tickets zuweisen und warten. Dieses Modell war immer reaktiv, und in einer AI-beschleunigten Entwicklungsumgebung ist es völlig überholt.

Scanner finden Probleme, nachdem sie bereits in Ihrem Code sind. Das Zeitfenster zwischen Einführung und Entdeckung ist der Ort, an dem Ihre Exposition lebt. Wenn AI Code im großen Maßstab generiert, wird dieses Zeitfenster breiter und das Volumen der Ergebnisse wächst schneller, als jedes Team manuell beheben kann. Das Ergebnis ist eine CVE-Liste, die sich unendlich ausdehnt, eine Priorisierung, die zu einem Rätsel wird, und Entwickler, die 4 bis 8 Stunden pro Schwachstelle für Arbeiten aufwenden, die keinen Geschäftswert erzeugen.

Fügen Sie die Regierungsfehlschläge hinzu, die folgen, und das Bild wird schlimmer. Die Verantwortung für die Behebung ist häufig unklar. Sicherheit flaggt eine CVE, Ingenieurwesen bezeichnet sie als Konfigurationsfrage und Betrieb bezeichnet sie als Codeproblem. Ich habe dieses Muster vor 20 Jahren gesehen und es hat sich nicht geändert. AI macht die Folgen dieser Mehrdeutigkeit wesentlich schwieriger zu absorbieren.

Der Wechsel, der tatsächlich funktioniert: Kontrolle, was hereinkommt

Die Organisationen, die vorankommen, haben aufgehört, ihre Sicherheit durch Scans zu erreichen, und haben begonnen, zu kontrollieren, was ihre Entwickler und AI-Tools konsumieren können. Der Mechanismus ist ein kuratierter, politikgesteuerter Katalog von Open-Source-Komponenten, der aus der Quelle erstellt, kontinuierlich überwacht und als privater interner Registry bereitgestellt wird, der direkte Abrufe aus öffentlichen Ökosystemen wie PyPI, npm oder Maven ersetzt.

Dieser Ansatz verschiebt die Sicherheit nach links im wörtlichen Sinne. Schwachstellen werden am Verbrauchspunkt blockiert, bevor sie jemals in die Build-Pipeline eindringen. Entwickler verwenden die gleichen Tools, die sie immer verwendet haben. AI-Coding-Assistenten lösen Abhängigkeiten aus der gleichen regulierten Quelle auf. Das Sicherheitsteam legt die Richtlinie einmal fest, und diese Richtlinie gilt überall, einschließlich für Code, der von einem Modell um 2 Uhr morgens ohne menschliche Überprüfung generiert wird.

Wie dies in der Praxis aussieht

Für Sicherheitsleiter, die durch diesen Prozess arbeiten, sind einige Dinge wichtiger als alles andere:

1. Definieren Sie Ihren genehmigten Komponentensatz, bevor Sie die AI-Adoption skalieren. Wenn Ihre AI-Coding-Tools Abhängigkeiten aus öffentlichen Registern auflösen, existiert Ihr Genehmigungsprozess nur auf dem Papier. Stellen Sie einen regulierten internen Registry ein, leiten Sie alles durch ihn und verlangen Sie, dass Komponenten aus der Quelle mit überprüfbarer Herkunft erstellt werden.
2. Behandeln Sie die Behebung als einen gesteuerten Prozess und nicht als Ticket-Warteschlange. Die Organisationen, die vorankommen, haben die manuelle Behebung nicht beschleunigt. Sie haben die manuelle Behebung aus der Gleichung entfernt. Wenn ein von der Community genehmigtes Patch verfügbar ist, wird es automatisch in den Katalog eingebaut. Entwickler erhalten das Update beim nächsten Abruf. Niemand weist ein Ticket zu. Niemand wartet 60 Tage.
3. Ordnen Sie Ihre AI-Toolkette Ihren Compliance-Verpflichtungen zu, bevor Sie gezwungen werden. Ich habe Teams gesehen, die Monate lang auf AI-Tooling aufgebaut haben, nur um auf eine Wand zu stoßen, als ein Kunde eine FedRAMP- oder SOC-2-Übereinstimmung verlangte. Ihr kuratierter Katalog ist auch Ihre Compliance-Prüfungsliste. SBOMs und Herkunftsunterlagen sollten mit jedem Komponenten geliefert werden, nicht retroaktiv unter Zeitdruck zusammengestellt werden.
4. Weisen Sie eine klare Verantwortung auf der Regierungsebene zu, nicht auf der Ticket-Ebene. Die Teams, die am schnellsten auf die Behebung reagieren, sind nicht diejenigen mit den meisten Entwicklern. Sie sind diejenigen, bei denen das Sicherheitsteam die Richtlinie besitzt, das Plattformteam die Lieferung besitzt und keines von beiden auf das andere wartet, um zu handeln.

Sicherheit, die ermöglicht, anstatt zu blockieren

Es gibt eine hartnäckige Überzeugung, dass Sicherheit und Entwicklungsgeschwindigkeit in einem fundamentalen Konflikt stehen. Ich habe nie festgestellt, dass dies der Fall ist, wenn die Sicherheit in den Prozess integriert und nicht darauf aufgesetzt wird. Entwickler, die aus einem kuratierten Komponentensatz arbeiten, bewegen sich tatsächlich schneller, weil sie keine Genehmigungen zweifeln, auf Sicherheitsprüfungen warten oder Schwachstellen beheben, die bereits im Voraus blockiert werden könnten.

Die Organisationen, die AI-gesteuerte Entwicklung ohne die Ansammlung nicht nachhaltiger Sicherheitsverschuldung meistern, sind nicht diejenigen, die die meisten Scanner ausführen. Sie sind diejenigen, die eine bewusste Entscheidung getroffen haben, zu regieren, was in ihre Software-Lieferkette eingeht, bevor es zu einem Incident-Response-Problem wird. Diese Entscheidung gehört zur Führung. Die Tools, um sie auszuführen, existieren heute.