KI-Sicherheit durch Verschleierung ist tot – und Verteidiger stehen vor dem schwierigeren Problem

KI-Sicherheit durch Verschleierung brach 2026 zusammen, als Agenten vernachlässigte Schwachstellen fanden, die Entwicklung von Exploits beschleunigten und Systeme erreichten, die hauptsächlich durch spezialisierte Komplexität geschützt waren.

Die unmittelbaren Belege reichen von vergessenen Windows-Komponenten über vielfach untersuchte Open-Source-Bibliotheken bis hin zu industriellen Steuerungen, die essenzielle Dienste betreiben. Diese Systeme unterscheiden sich technisch, doch sie teilten eine stille Verteidigungslinie. Angreifer benötigten seltenes Fachwissen, erhebliche Geduld oder genügend wirtschaftlichen Anreiz, um sie zu untersuchen.

KI-gestützte Schwachstellenentdeckung verändert diese Rechnung. Modelle können unbekannten Code interpretieren, proprietäre Protokolle erklären, Test-Harnesses erzeugen und repetitive Aufklärungsarbeit automatisieren. Das Ergebnis ist kein neues Sicherheitsprinzip. Es ist der Abbau jener Reibung, die Organisationen erlaubte, die Befolgung der alten Prinzipien aufzuschieben.

Das führt zu einer schwierigen Umkehrung für Verteidiger. Schwachstellen zu finden wird günstiger und schneller, während Patches zu validieren, Offenlegungen zu koordinieren, operative Systeme zu testen und fehlerhafte Entwicklungspraktiken zu ändern, hartnäckig menschliche Prozesse bleiben.

Die Frage ist nicht länger, ob verborgene Schwachstellen ans Licht kommen werden. Sie lautet, ob Verteidiger die Bedingungen beseitigen können, die sie hervorbringen, bevor automatisierte Entdeckung jedes vernachlässigte System zu einem wirtschaftlich attraktiven Ziel macht.

KI-Sicherheit durch Verschleierung hat ihren wirtschaftlichen Burggraben verloren

KI hat Sicherheit durch Verschleierung nicht widerlegt. Sie hat den Arbeitskräftemangel beseitigt, der Organisationen vorgaukeln ließ, Verschleierung funktioniere.

Sicherheit durch Verschleierung beschreibt eine Design- oder Betriebsannahme, die darauf beruht, dass Architektur, Schnittstellen oder Schwachstellen schwer zu entdecken bleiben. Sie galt nie als solide primäre Schutzmaßnahme. Dennoch bot Verschleierung praktischen Schutz, wenn die Untersuchung eines unbekannten Systems knappe Spezialisten und Wochen konzentrierter Arbeit erforderte.

Dieser Schutz funktionierte wie ein wirtschaftlicher Burggraben. Eine verwundbare Komponente konnte unangetastet bleiben, weil Angreifer mit der gezielten Ausnutzung vertrauter Software mehr verdienen konnten. Ein proprietäres Protokoll konnte Außenstehende abschrecken, weil die Dokumentation begrenzt war. Ein altes Subsystem konnte der Prüfung entgehen, weil sich nur wenige Forschende daran erinnerten, dass es überhaupt existierte.

Die am 13. September veröffentlichte ursprüngliche Sicherheitsanalyse zeigt, wie sich dieses Gleichgewicht verändert hat. Anbieter und unabhängige Forschende nutzen inzwischen KI-Agenten, um obskure, alte und intensiv geprüfte Software zu untersuchen. Angreifer setzen verwandte Fähigkeiten ein, um Korrekturen zu analysieren und Exploits zu entwickeln.

Brett Leatherman, stellvertretender Direktor der Cyber Division des FBI, beschrieb, wie Modelle erhebliche Schwachstellen in Open-Source-Komponenten finden, die Communities ein Jahrzehnt lang untersucht hatten. Einige dieser Bibliotheken laufen Berichten zufolge in einem beträchtlichen Teil der Webinfrastruktur.

Das bedeutet nicht, dass KI jedes System eigenständig versteht oder zuverlässig einen funktionierenden Exploit erzeugt. Es bedeutet, dass Untersuchende unbekanntes Terrain betreten können, ohne bei null anzufangen. Ein Modell kann Code zusammenfassen, Dokumentation übersetzen, wahrscheinliche Vertrauensgrenzen identifizieren und Skripte erzeugen, um Hypothesen zu testen.

Agentische KI-Systeme erweitern diese Unterstützung über eine Abfolge von Aufgaben hinweg. Ein Agent kann Dateien prüfen, Tools ausführen, Ergebnisse bewerten, seinen Ansatz überarbeiten und weitermachen, bis er ein definiertes Ziel erreicht. Menschliche Bediener setzen weiterhin Ziele und stellen Infrastruktur bereit, doch die Maschine übernimmt einen Großteil der repetitiven Arbeit.

Deshalb setzt KI-gestützte Schwachstellenentdeckung geschlossene und offene Software gleichermaßen unter Druck. Öffentlicher Code erleichtert die direkte Analyse, doch geschlossene Software legt weiterhin Binärdateien, Firmware, Netzwerkverhalten, Dokumentation, Patches und Konfigurationsartefakte offen. Modelle können diese Fragmente mit einer Geschwindigkeit korrelieren, die die Wirtschaftlichkeit des Reverse Engineerings verändert.

Dustin Childs, Leiter von Trend Micros Zero Day Initiative, verwies auf vergessene Technologien, die in Microsofts rekordverdächtiger Patch-Veröffentlichung im September behandelt wurden. Zu den betroffenen Komponenten gehörten ein Telnet-Client, Windows RNDIS, NFS Portmapper und Link Layer Topology Discovery.

Ihr Alter ist bedeutsam, weil es die alte Abmachung verdeutlicht. Legacy-Komponenten konnten ohne ständige Aufmerksamkeit von Experten überleben, wenn nur wenige Menschen das Interesse oder den Hintergrund hatten, sie zu untersuchen. KI gibt neugierigen Forschenden und Angreifern einen kostengünstigen Wegweiser in genau diese vernachlässigten Bereiche.

Verschleierung sorgt weiterhin für Unannehmlichkeiten. Ein undokumentiertes Protokoll kann einen Agenten verlangsamen, und ein proprietäres Gerät kann die verfügbaren Belege begrenzen. Doch Unannehmlichkeit ist keine Autorisierung, Isolation, Authentifizierung oder Speichersicherheit. Ihr kann nicht vertraut werden, um eine hartnäckige automatisierte Untersuchung aufzuhalten.

Der Burggraben hat sich daher von verborgenem Wissen hin zu überprüfbaren Kontrollen verlagert. Systeme benötigen starke Identitätsgrenzen, minimale Angriffsfläche, sichere Standardeinstellungen, getestete Segmentierung und Designs, die sicher bleiben, wenn ihre Funktionsweise bekannt wird.

Dies ist das etablierte Sicherheitsprinzip, das als Kerckhoffs’sches Prinzip bekannt ist und über die Kryptografie hinaus angewendet wird. Ein System sollte sicher bleiben, selbst wenn ein Angreifer versteht, wie es funktioniert – abgesehen von ordnungsgemäß verwalteten Geheimnissen wie kryptografischen Schlüsseln.

KI macht dieses Prinzip operativ dringlich. Dokumentation muss nicht mehr ordentlich veröffentlicht sein, damit das Verhalten eines Systems verständlich wird. Ausreichend verstreute Belege können einem Agenten inzwischen eine brauchbare Karte liefern.

Der erste Druckpunkt ist vergessene Software

Die Systeme mit dem größten Druck sind nicht immer die neuesten oder wertvollsten. Es sind jene, deren Sicherheit davon abhing, dass niemand genau hinschaut.

Traditionelle Schwachstellenforschung umfasst kostspielige Phasen. Forschende müssen eine Codebasis erlernen, ihre Betriebsumgebung reproduzieren, ihre Annahmen verstehen und bedeutsame Schwachstellen von harmlosen Anomalien trennen. Diese Schritte benötigen oft mehr Zeit, als den verdächtigen Code selbst zu finden.

KI kann mehrere davon verkürzen. Sie kann Harnesses schreiben, Datenflüsse verfolgen, verwandte Implementierungen vergleichen und unbekannte Programmiermuster erklären. Sie kann zudem weiter scannen, wenn die Aufgabe repetitiv wird, was wichtig ist, weil menschliche Aufmerksamkeit begrenzt ist.

Das garantiert keine nützlichen Ergebnisse. Modelle erzeugen Fehlalarme, missverstehen Kontext und erfinden manchmal technische Erklärungen. Dennoch erlaubt kostengünstige Unterstützung Betreibern, mehr Ziele zu testen und unproduktive Wege aufzugeben, ohne dieselbe Menge an Spezialistenzeit zu verbrauchen.

Diese breitere Suche verändert, welche Software attraktiv wird. Maintainer alter Bibliotheken, spezialisierter Unternehmensprodukte, Geräte-Firmware und nur spärlich dokumentierter interner Dienste können nicht länger davon ausgehen, dass Angreifer sich auf andere Ziele konzentrieren werden. Ihr Verschleierungsrabatt schrumpft.

Derselbe Druck gilt für bekannte Schwachstellen, deren Korrekturen noch nicht ausgerollt wurden. Sobald ein Anbieter einen Fix veröffentlicht, können Angreifer gepatchte und ungepatchte Versionen vergleichen. Dieser Prozess, Patch Diffing genannt, zeigt, welcher Code geändert wurde, und hilft Untersuchenden, die zugrunde liegende Schwachstelle zu rekonstruieren.

KI beschleunigt Patch Diffing, indem sie die Änderung interpretiert, auslösende Eingaben vorschlägt und Testcode erzeugt. Die Forschung von Anthropic zur schnellen Exploit-Entwicklung untersuchte, wie Modelle kürzlich offengelegte Schwachstellen analysieren und die Ausnutzung unterstützen könnten, bevor jede Organisation den Fix installiert hatte.

Das verkürzt die Patch-Lücke, also den Zeitraum zwischen der Verfügbarkeit eines Fixes und dem tatsächlichen Erhalt durch Nutzer. Die Lücke war schon immer gefährlich. Automatisierte Analyse macht jede Stunde darin für Angreifer wertvoller.

Eine jüngste Kampagne mit einem Chromium-basierten Exploit-Kit zeigte das operative Risiko. Spionagegruppen nutzten Berichten zufolge Schwachstellen, nachdem ein Upstream-Projekt einen Patch veröffentlicht hatte, jedoch bevor nachgelagerte stabile Releases alle Nutzer erreichten. KI war nicht unbedingt für jeden Teil dieser Kampagne verantwortlich, doch sie stärkt die Methode, die ein solches Timing wirksam macht.

Open Source ist unter diesem Modell nicht einzigartig zum Untergang verurteilt. Öffentliche Prüfung gibt Verteidigern Zugang zu demselben Code und ermöglicht umfassende Zusammenarbeit. Das tieferliegende Problem ist die asymmetrische Ausführung. Angreifer können viele Möglichkeiten testen, während Maintainer Meldungen validieren, Regressionen vermeiden, Releases koordinieren und Nutzer unterstützen müssen.

Geschlossene Software steht vor einem verwandten Problem mit weniger öffentlicher Sichtbarkeit. Ein KI-gestützter Forschender kann weiterhin Binärdateien, Schnittstellen, Fehlerverhalten, Update-Pakete, mobile Anwendungen und Geräte-Firmware untersuchen. Anbieter können nicht davon ausgehen, dass das Zurückhalten von Quellcode ein dauerhaftes technisches Geheimnis bewahrt.

Damit stehen Maintainer vor einem wachsenden Eingangsproblem. Mehr KI-generierte Meldungen bedeuten nicht automatisch mehr bestätigte Schwachstellen. Einige Einsendungen werden Duplikate, unvollständige Behauptungen oder plausibel wirkende Fehler sein, die ohne ausreichende Tests erzeugt wurden.

Die Flut kann genau jene Experten binden, die zur Behebung echter Schwachstellen benötigt werden. Kleine Open-Source-Projekte sind besonders exponiert, weil eine breit eingesetzte Komponente möglicherweise nur wenige Maintainer hat. Automatisierte Entdeckung kann unabhängig von ihrer Prüfungskapazität skalieren.

Organisationen müssen daher mehr als nur die Zahl der Meldungen messen. Nützliche Indikatoren umfassen die Zeit bis zur Reproduktion, die Zeit bis zur Bestimmung des Schweregrads, den Anteil doppelter Funde, die Patch-Validierungszeit und Wiederholungen nach Schwachstellenklasse.

Diese Kennzahlen unterscheiden Sicherheitsverbesserung von Aktivität. Ein Team, das Hunderte risikoarmer Meldungen schließt, während ein wiederkehrender Injection-Fehler in seinem Entwicklungsprozess fortbesteht, arbeitet schneller, ohne die künftige Gefährdung zu verringern.

Industriesysteme verlieren ihre Spezialistenbarriere

Betriebstechnologie zeigt, warum der Zusammenbruch der Verschleierung Folgen hat, die über gewöhnliche Softwarewartung hinausgehen.

Betriebstechnologie, kurz OT, steuert physische Prozesse wie Wasseraufbereitung, Fertigungslinien, Kraftstoffverteilung und elektrische Anlagen. Industrielle Steuerungssysteme kombinieren häufig langlebige Hardware, proprietäre Protokolle, spezialisierte Engineering-Software und strenge Verfügbarkeitsanforderungen.

Dieses Umfeld schreckte historisch viele Angreifer ab. Das Verständnis einer speicherprogrammierbaren Steuerung, kurz PLC, erforderte Kenntnisse industrieller Prozesse und gerätespezifischer Kommunikation. Das Testen einer Theorie konnte zudem den physischen Betrieb unterbrechen.

John Hultquist, Chefanalyst bei Google Threat Intelligence Group, argumentierte, dass spezialisiertes Wissen einen Großteil des praktischen Schutzes industrieller Systeme geboten habe. KI erleichtert es, dieses Wissen zu erwerben, zu organisieren und anzuwenden.

Das Risiko wurde im August konkret, als fünf US-Behörden vor Angreifern warnten, die KI-gestützte Skripte gegen über das Internet erreichbare Siemens S7 Series PLCs einsetzen. Zu den betroffenen Umgebungen gehörten Wasserwirtschaft, Fertigung, Energie, Chemie, Landwirtschaft und gewerbliche Anlagen.

Laut der bundesweiten Bedrohungswarnung kombinierten die Betreiber öffentliche Bibliotheken für industrielle Automatisierung mit KI-Coding-Assistenten. Ihre Tools ahmten legitime Überwachungssoftware nach und interagierten mit PLC-Speicher, Konfigurationsdaten und Ladder Logic.

Ladder Logic ist eine grafische Programmiersprache zur Definition industrieller Steuerungsabläufe. Unbefugte Änderungen können reale Anlagen beeinflussen, statt lediglich Informationen auf einem Bildschirm zu verändern.

Die berichtete Aktivität verringerte den Fachkenntnisbedarf für die Arbeit mit dem von diesen Steuerungen verwendeten S7comm-Protokoll. KI konnte Betreibern helfen, mithilfe öffentlich verfügbarer Informationen Skripte zu erstellen oder zu verändern. Sie machte eine isolierte Steuerung weder erreichbar noch umging sie jede korrekt konfigurierte Sicherheitskontrolle.

Die Exponierung blieb die entscheidende Voraussetzung. Angreifer suchten Berichten zufolge nach mit dem Internet verbundenen PLCs, Systemen mit veralteter Software oder solchen, die durch Standardanmeldedaten geschützt waren. Schwache Segmentierung eröffnete generierten Skripten anschließend einen Weg zu kritischen Funktionen.

Diese Unterscheidung ist wichtig. Die Vorfälle als „KI-Angriffe“ zu bezeichnen, kann Organisationen von Schutzmaßnahmen ablenken, deren Umsetzung sie bereits beherrschen. Direkten Internetzugang zu entfernen, Standardanmeldedaten zu ändern, unterstützte Geräte zu patchen und Engineering-Netzwerke zu trennen, bleibt unverzichtbar.

Sicherheit durch Unklarheit scheitert bei KI am deutlichsten, wenn Organisationen Unvertrautheit mit Isolation verwechseln. Ein seltenes Protokoll verhindert keinen Zugriff. Eine proprietäre Engineering-Schnittstelle authentifiziert ihren Nutzer nicht. Ein undokumentierter Befehl hält kein Modell auf, das darauf trainiert ist, Beispiele zu vergleichen und Antworten zu testen.

Gleichzeitig können Verteidiger Industrieumgebungen nicht wie Consumer-Laptops patchen. Anlagen planen Wartungen möglicherweise Monate im Voraus. Anbieter müssen Änderungen unter Umständen zertifizieren. Ältere Steuerungen können jahrzehntelang betrieben werden, und ihr Austausch kann erhebliche physische Arbeiten erfordern.

Auch die Verfügbarkeit schafft ein Testdilemma. Eine fehlerhafte defensive Maßnahme kann die Produktion unterbrechen oder Geräte beschädigen. Angreifer haben weniger Gründe, Störungen zu vermeiden, während Betreiber jede Änderung gegen Sicherheits- und Betriebsanforderungen validieren müssen.

Diese Asymmetrie erklärt, warum bessere Erkennung allein nicht ausreicht. Eigentümer benötigen präzise Asset-Inventare, kontrollierten Fernzugriff, Netzwerküberwachung und durchgesetzte Kommunikationspfade. Sie sollten jeden Datenverkehr zu einer PLC von einer Nicht-Engineering-Workstation identifizieren und Schreibvorgänge außerhalb genehmigter Änderungsfenster untersuchen.

Eine Daten-Diode, die Informationen nur in eine Richtung passieren lässt, kann Umgebungen schützen, in denen Telemetriedaten hinausgehen müssen, Befehle aber nie zurückkehren müssen. Starke Segmentierung kann die Auswirkungen einer kompromittierten Workstation oder eines generierten Skripts begrenzen.

Dabei handelt es sich um architektonische Kontrollen und nicht um Versuche, das System zu verbergen. Sie gehen davon aus, dass Angreifer die Ausrüstung verstehen, und verweigern ihnen dennoch einen nutzbaren Zugriffsweg.

Die Erkenntnis reicht bis in Unternehmenssoftware hinein. Ein System sollte nicht nur deshalb sicher bleiben, weil seine interne API undokumentiert ist oder sein Administrationspanel eine unvorhersehbare Adresse verwendet. KI verwandelt diese Unannehmlichkeiten zunehmend in kurze Rechercheaufgaben.

Die KI-gestützte Schwachstellensuche überholt die Behebung

Der zentrale Sicherheitskonflikt besteht nicht mehr zwischen Entdeckung und Unwissenheit. Es geht um maschinenschnelle Entdeckung gegenüber durch Menschen begrenzter Behebung.

Katie Moussouris, Gründerin und CEO von Luta Security, bezeichnete Triage, Priorisierung und Behebung als die eigentlichen Engpässe. Zusätzliche Schwachstellen zu finden, hat nur begrenzten Wert, wenn Organisationen nicht bestimmen können, welche davon relevant sind oder ihre Ursachen beseitigen können.

Hier werden optimistische Darstellungen der KI-gestützten Schwachstellensuche unvollständig. Ein Modell, das zehnmal mehr plausible Befunde erzeugt, kann die Sicherheit verschlechtern, wenn der Prüfungsstau keine vertrauenswürdigen Belege, reproduzierbaren Tests und klaren Verantwortlichkeiten enthält.

Verteidiger müssen für jeden Bericht mehrere Fragen beantworten. Ist das Verhalten real? Kann ein Angreifer es erreichen? Welche Berechtigungen sind erforderlich? Überschreitet die Ausnutzung eine wichtige Vertrauensgrenze? Wird die vorgeschlagene Behebung das erwartete Verhalten beeinträchtigen?

KI-generierte Patches scheinen eine entsprechende Beschleunigung zu bieten. Ein Modell kann verwundbaren Code untersuchen, eine Änderung vorschlagen und Tests erzeugen. Aktuelle Erkenntnisse zeigen jedoch, dass die Erstellung von Patches deutlich weniger zuverlässig bleibt als das Auffinden verdächtigen Verhaltens.

Ein Forschungsteam von 1Password bewertete 6.080 Patches für sechs kürzlich veröffentlichte Schwachstellen, die mit zwei Spitzenmodellen generiert wurden. Nur 26,0 Prozent beseitigten die Schwachstelle vollständig, ohne das Anwendungsverhalten wesentlich zu verändern.

Weitere 20,1 Prozent behoben die Schwachstelle, veränderten jedoch die Funktionsweise der Anwendung. Noch schwerwiegender ist, dass 53,9 Prozent die Schwachstelle nicht beseitigten, eine weitere Schwachstelle einführten oder beides taten, laut der Studie zur Patch-Validierung.

Diese Ergebnisse belegen keine allgemeingültige Fehlerquote für jedes Modell, jede Sprache oder jede Schwachstelle. Die Forschenden wählten bewusst aktuelle, komplexe Fehler aus, die umfangreiche Reparaturen erforderten. Einfachere Defekte und stärkere Testsuiten können zu anderen Ergebnissen führen.

Die Studie legt dennoch das zentrale Ungleichgewicht offen. Eine überzeugende Codeänderung zu erzeugen, ist leichter als nachzuweisen, dass sie jede wichtige Sicherheits- und Funktionseigenschaft erhält.

Einige vorgeschlagene Reparaturen blockierten lediglich die bekannte Proof-of-Concept-Eingabe, ohne die zugrunde liegende Ursache zu beheben. Dieses Muster kann einen Patch hervorbringen, der einen grundlegenden Test besteht, aber weiterhin für alternative Eingaben anfällig bleibt.

KI-generierte Patches übernehmen zudem Schwächen aus den Umgebungen, die sie bewerten. Eine unvollständige Testsuite kann kein Verhalten bestätigen, das sie nie prüft. Ein Modell kann darauf optimieren, sichtbare Tests zu bestehen, selbst wenn diese Tests nur einen Bruchteil des Sicherheitsvertrags abbilden.

Separate Forschung mit mehr als 100 Modellen und 80 Programmieraufgaben ergab eine durchschnittliche Rate sicheren Codes von 56 Prozent. Dieses Ergebnis untersuchte generierten Code statt der Behebung von Schwachstellen, unterstreicht jedoch die Notwendigkeit unabhängiger Validierung.

Organisationen sollten diese Zahlen nicht als Beweis lesen, dass KI defensive Arbeit nicht unterstützen kann. Modelle können Änderungen entwerfen, Regressionstests generieren, unbekannte Funktionen erklären und alternative Korrekturen vergleichen. Solche Einsatzmöglichkeiten können den Engineering-Aufwand senken, wenn Fachleute die endgültige Entscheidung behalten.

Die Gefahr beginnt, wenn Geschwindigkeit zur primären Erfolgskennzahl wird. Ein schnell bereitgestellter Patch ohne angemessene Validierung kann die ursprüngliche Schwachstelle erhalten, eine neue schaffen oder Zugriffsregeln unbemerkt verändern.

Defensive Automatisierung muss daher ausführungsgestützt sein. Das bedeutet, vorgeschlagene Änderungen zu kompilieren und auszuführen, Sicherheitseigenschaften zu testen, Verhalten zu vergleichen und Patches abzulehnen, die definierte Invarianten verletzen. Eine Invariante ist eine Bedingung, die bei jeder akzeptablen Implementierung wahr bleiben muss.

Menschliche Prüfung bleibt bei Systemen mit hoher Auswirkung notwendig, weil Tests niemals den gesamten Betriebskontext erfassen. Engineers müssen verstehen, warum die Schwachstelle existierte, welche Annahmen scheiterten und ob verwandter Code dasselbe Muster enthält.

Das ist langsamer als einen Patch zu generieren. Es ist jedoch genau die Arbeit, die einen Schwachstellenbericht in nachhaltige Risikoreduktion verwandelt.

Mehr Befunde werden keine fehlerhaften Sicherheitsprozesse reparieren

Organisationen, die auf KI mit einer größeren Patch-Warteschlange reagieren, werden gefangen bleiben, denn Volumen korrigiert nicht den Prozess, der die Defekte hervorgebracht hat.

Ein Schwachstellenprogramm kann produktiv wirken, während das Risiko weiter steigt. Teams zählen kritische Befunde, Abschlusszeiten und die Gesamtzahl der Patches, weil diese Zahlen leicht zu erfassen sind. Sie zeigen Aktivität, offenbaren jedoch nicht immer, ob die Software sicherer wird.

Moussouris warnte, dass Organisationen nicht gewinnen können, indem sie endlos Ressourcen für einzelne Entdeckungen und Behebungen hinzufügen. Die nachhaltige Antwort besteht darin, Muster zu identifizieren und die Systeme zu verändern, die wiederkehrende Klassen von Schwachstellen erzeugen.

Angenommen, eine KI-gestützte Prüfung findet Dutzende Injection-Schwachstellen. Jede Instanz zu beheben ist wichtig, doch die größere Chance liegt früher in der Entwicklung. Teams können sicherere Vorlagen, zentralisierte Eingabeverarbeitung, Framework-Schutzmechanismen und Tests einführen, die verhindern, dass derselbe Defekt zurückkehrt.

Das ist der Unterschied zwischen der Behandlung von Befunden und der Verbesserung einer Sicherheitskontrolle. Ersteres senkt die unmittelbare Exponierung. Letzteres verändert die künftige Rate, mit der Exponierung entsteht.

Organisationen sollten Schwachstellendaten mit Code-Verantwortlichkeit, Architekturentscheidungen und Entwicklungsstandards verknüpfen. Wenn ein Dienst wiederholt Autorisierungsfehler hervorbringt, muss die Führungsebene sein Zugriffsmodell untersuchen, statt schnellere Ticketabschlüsse zu feiern.

Dieselbe Logik gilt für Infrastruktur. Wiederkehrende Befunde zu exponierten Administrationsschnittstellen weisen auf ein Versagen beim Asset-Management oder der Netzwerk-Governance hin. Einen einzelnen Server zu reparieren, ohne das Bereitstellungsmuster zu korrigieren, lässt den zugrunde liegenden Mechanismus bestehen.

Eine reife Reaktion auf Sicherheit durch Unklarheit bei KI beginnt mit einem ehrlichen Inventar. Teams müssen wissen, welche Komponenten bereitgestellt sind, wer sie wartet, welche Schnittstellen erreichbar sind und was geschieht, wenn der Support endet.

Software-Stücklisten können helfen, Abhängigkeiten zu identifizieren, doch ein Inventar muss über Paketnamen hinausgehen. Organisationen benötigen außerdem Firmware-Versionen, Gerätemodelle, Cloud-Dienste, interne APIs, geerbte Berechtigungen und Assets der Betriebstechnologie.

Wissenssysteme schaffen eine weitere Form des Risikos durch Unklarheit. KI-Assistenten können Dokumente, Nachrichten, Transkripte und Notizen sichtbar machen, auf die Mitarbeitende technisch zugriffsberechtigt waren, die sie aber manuell nur selten entdeckt hätten.

Das ist nicht zwingend eine Umgehung der KI-Autorisierung. Es kann die Offenlegung von Berechtigungen sein, die schon immer zu weit gefasst waren. KI verringert den Aufwand, der erforderlich ist, um sensibles Material innerhalb dieser Berechtigungen zu finden.

Teams, die Enterprise-Search- oder Retrieval-Systeme einführen, sollten vor einer breiten Bereitstellung Inhaltseigentümerschaft, Aufbewahrung, Zugriffsvererbung und Indexierungsgrenzen prüfen. Eine gut konzipierte KI-Wissensdatenbank sollte Quellberechtigungen bewahren, statt alle indexierten Informationen als gleichermaßen verfügbar zu behandeln.

Dies erfordert auch sorgfältige Protokollierung. Sicherheitsteams benötigen Aufzeichnungen darüber, worauf ein Agent zugegriffen hat, welche Tools er aufgerufen hat, welche Änderungen er vorgeschlagen hat und wer folgenreiche Maßnahmen genehmigte. Ohne diese Belege werden automatisierte Workflows schwerer zu untersuchen als die Altsysteme, die sie ersetzen.

Prozessreformen sollten strenge Anforderungen für die Aufnahme KI-generierter Schwachstellenberichte umfassen. Einreichungen sollten betroffene Versionen identifizieren, die Vertrauensgrenze beschreiben, Reproduktionsschritte bereitstellen und beobachtetes Verhalten von modellgenerierter Spekulation trennen.

Maintainer können dann Automatisierung nutzen, um Duplikate zu gruppieren, Umgebungsdetails zu verifizieren und Befunde mit nachgewiesener Auswirkung zu priorisieren. Das Ziel ist nicht, KI-gestützte Forschung abzulehnen. Es besteht darin, Belege zu verlangen, die mit dem Volumen der Behauptungen skalieren.

Auch Beschaffungsteams spielen eine Rolle. Käufer sollten Anbieter fragen, wie sie von Agenten generierte Patches testen, Legacy-Komponenten verwalten, koordinierte Offenlegung handhaben und wiederkehrende Schwachstellenklassen messen. Das Versprechen, „KI für Sicherheit einzusetzen“, bietet ohne diese Details wenig Gewissheit.

Die skeptische Sicht bleibt wichtig. Aktuelle Modelle sind inkonsistent, und beeindruckende Demonstrationen nutzen oft kuratierte Umgebungen. Manche KI-Befunde erfordern umfangreiche menschliche Korrekturen, während vollständig autonome Ausnutzung weniger verbreitet bleibt als unterstütztes Scripting und Aufklärung.

Inkonsistenz stellt den alten Burggraben jedoch nicht wieder her. Ein Angreifer muss nicht jeden Versuch erfolgreich abschließen. Günstige parallele Versuche können selbst eine niedrige Erfolgsquote operativ wertvoll machen, insbesondere gegen viele ähnliche Ziele.

Verteidiger müssen für diese Ökonomie planen. Sie sollten davon ausgehen, dass zugänglicher Code, Binärdateien, Konfigurationen und Patches automatisierter Prüfung unterzogen werden. Ihr Vorteil muss aus sichererem Design und schnellerer verifizierter Reaktion entstehen, nicht aus der Hoffnung, dass die Prüfung scheitert.

Drei Signale werden zeigen, ob Verteidiger aufholen können

Die nächste Phase wird durch Patch-Verifizierung, die Exponierung kritischer Infrastruktur und die Frage entschieden, ob Organisationen wiederkehrende Schwachstellen verhindern, statt sie nur zu zählen.

Das erste Signal ist die gemessene Zuverlässigkeit von KI-generierten Patches. Künftige Bewertungen sollten kürzlich bekannt gewordene Schwachstellen testen, realistisches Anwendungsverhalten bewahren und reproduzierbare Methoden veröffentlichen. Eine steigende Quote vollständiger Behebungen würde die derzeitige Lücke zwischen Entdeckung und Behebung verkleinern.

Das entscheidende Ergebnis ist nicht, ob ein Patch kompiliert. Forschende müssen prüfen, ob er die Grundursache beseitigt, neue Schwächen vermeidet und das erwartete Verhalten erhält. Verbesserungen, die einer unabhängigen Bewertung standhalten, würden die Argumente für überwachte defensive Automatisierung stärken.

Bleiben die Fehlerraten in der Nähe des derzeitigen Niveaus, spricht das für eine vorsichtigere Schlussfolgerung. KI würde weiterhin die Zahl der Funde erhöhen, während die Validierung durch Fachleute der begrenzende Faktor bliebe.

Das zweite Signal ist die Exponierung industrieller Steuerungen und anderer Altsysteme. Behörden und Betreiber sollten verfolgen, ob die Zahl internetzugänglicher SPSen sinkt, Standardzugangsdaten verschwinden und Organisationen unbefugten Datenverkehr über Industrieprotokolle erkennen.

Eine weitere Welle KI-gestützter Angriffe auf exponierte Steuerungen würde die zentrale Einschätzung stützen. Sie würde zeigen, dass Angreifer öffentliches Wissen wiederholt in funktionierende Werkzeuge gegen Systeme umwandeln, die weiterhin durch eine schwache Architektur geschützt sind.

Ein anhaltender Rückgang der Exponierung würde die alarmierendste Prognose abschwächen. Er würde die Obskurität nicht wiederherstellen, aber zeigen, dass grundlegende Isolierung und Asset-Management Agenten einen praktischen Angriffsweg versperren können.

Das dritte Signal ist, wie Sicherheitsorganisationen Fortschritt messen. Ein Team, das sich nur auf die Zahl der Funde und die mittlere Zeit bis zum Abschluss konzentriert, wird Schwierigkeiten bekommen, wenn sich automatisierte Berichte häufen. Ein Team, das wiederkehrende Fehlerklassen, exponierte Assets, Grundursachen und validierte Behebungen verfolgt, kann den künftigen Bedarf senken.

Achten Sie darauf, ob Anbieter und große Softwareprojekte solche tiefergehenden Kennzahlen veröffentlichen. Hinweise darauf, dass Injektions-, Autorisierungs-, Speicher­sicherheits- oder Konfigurationsfehler zurückgehen, würden darauf hindeuten, dass Prozessänderungen wirken.

Wenn die Offenlegungszahlen weiterhin Rekorde brechen, während dieselben Fehlerklassen wiederkehren, werden Verteidiger auf dem bleiben, was Moussouris als Laufband beschrieb. Schnellere Entdeckung wird mehr Risiken offenlegen, ohne die Mechanismen zu verändern, die sie hervorbringen.

Die praktische Reaktion beginnt jetzt. Inventarisieren Sie vergessene Systeme, beseitigen Sie unnötige Exponierung, testen Sie Berechtigungsgrenzen und verlangen Sie für jede automatisierte Sicherheitsbehauptung Belege. Nutzen Sie Agenten zur Unterstützung von Forschenden und Ingenieuren, halten Sie folgenreiche Reparaturen jedoch hinter reproduzierbaren Tests und einer verantwortlichen Prüfung zurück.

KI-Sicherheit durch Obskurität ist bereits eine verlorene Position, weil die alte Verteidigung auf knapper Neugier und spezialisierter Arbeit beruhte. Beides wird zunehmend als Softwaredienst verfügbar.

Die schwierigere Aufgabe besteht darin, Systeme zu entwickeln, die sicher bleiben, nachdem ihre Details verständlich geworden sind. Welche versteckte Abhängigkeit, geerbte Berechtigung oder exponierte Steuerung würde Ihre Organisation heute am wenigsten gern von einem KI-Agenten untersuchen lassen?