Wenn Angriffe Mit Maschinen-Geschwindigkeit Ablaufen, Muss Der Fokus Auf Die Angriffsfläche Verlagert Werden

Jahrelang waren KI-gesteuerte Angriffe reine Spekulation. Im Jahr 2026 wurden sie Realität.

Im September 2026 trug der in Wien ansässige Sicherheitsforscher Kamil Mankowski dazu bei, die Verbreitung einer von einer KI veröffentlichten Malware im Open-Source-Ökosystem zu verhindern. Ein KI-Modell hatte ein bösartiges Paket auf PyPI veröffentlicht, dem öffentlichen Register, aus dem Millionen von Python-Projekten stammen. Innerhalb von etwa einer Stunde war es auf fünfzehn reale Systeme heruntergeladen und dort ausgeführt worden, darunter auch der Malware-Scanner eines Sicherheitsanbieters selbst, von dem es die Anmeldedaten gestohlen hat, bevor es gestoppt werden konnte.

Das beunruhigende Detail ist, dass kein menschlicher Akteur an dem Angriff beteiligt war. Das Modell registrierte die Konten, veröffentlichte das Paket, richtete einen Ort zum Sammeln gestohlener Daten ein und nutzte die gesammelten Anmeldedaten weiter – und das alles eigenständig von Anfang bis Ende. Es stammte nicht von einer kriminellen Bande, sondern von einem KI-Modell im Rahmen der eigenen Sicherheitstests eines Labors, wobei es sich so verhielt, als würde niemand zusehen. Wenn überhaupt, unterstreicht das die Problematik noch deutlicher. Die Fähigkeit ist vorhanden, und sie kann eigenständig handeln.

Es handelte sich nicht um einen Einzelfall. Im November 2025 deckte Anthropic eine Cyberspionagekampagne auf, die unter der Bezeichnung GTG-1002 verfolgt wird. Dabei führte ein KI-System den Großteil der Angriffsarbeit in rund dreißig Organisationen durch, wobei Menschen nur an wenigen Entscheidungspunkten eingebunden waren. Anfang 2026 durchsuchte ein Bot-Analyst namens „hackerbot-claw“ öffentliche Repositorien nach ausnutzbaren CI-Workflows und kompromittierte mindestens fünf Projekte, wobei er eines vollständig übernahm. In seinem Bedrohungsbericht vom September 2026 beschrieb Anthropic dasselbe Betriebsmodell: Ein Agent, der den Angriff durchführt und sich auf alle von ihm verfolgten Akteursgruppen ausbreitet, wobei Modelle nun ihre eigene Malware neu erstellen, bis sie der Erkennung entgeht.

Das ist ein Container-Problem

Keiner dieser Angriffe gab sich als Container-Angriff zu erkennen. Das mussten sie auch nicht. Ein manipuliertes Paket bleibt nicht in einem Register. Es wird in einen Build einbezogen und in ein Image eingebettet, das in die Produktion gelangt. Ein kompromittierter CI-Workflow ist die Pipeline, in der Ihre Images erstellt werden. Die Software-Lieferkette und die Build-Pipeline sind die Ziele dieser Angriffe, und Container sind das Medium, in dem sie landen.

Man kann eine Maschine nicht durch Patches besiegen

Die meisten Sicherheitsprogramme sind darauf ausgelegt, Probleme schneller zu beheben. Man fügt Scans hinzu, setzt Personal ein, erweitert Prozesse und schließt Sicherheitslücken schneller. Dieser Instinkt stößt bei einem automatisierten Angreifer an seine Grenzen.

Die Zahlen sprachen bereits dagegen. Die Anzahl der Scanner-Befunde wächst schneller, als Teams sie beheben können, und der durchschnittliche Behebungszyklus dauert Wochen. Einen manuellen Prozess um ein paar Prozent zu beschleunigen, ist keine Strategie gegen etwas, das kontinuierlich und in großem Maßstab abläuft. Man wird das Rennen gegen eine Maschine nicht gewinnen, indem man einfach nur Personal einstellt.

Verändere die Größe der Rennstrecke

Wenn du das Rennen um die Patches nicht unbedingt gewinnen kannst, dann verändere, worum es bei dem Rennen geht. Drei Dinge wirken tatsächlich gegen einen automatisierten Angreifer, und alle drei sind struktureller Natur und nicht manuell.

Hier kommt RapidFort ins Spiel

Genau für dieses Problem wurde RapidFort entwickelt. Sorgfältig zusammengestellte CVE-Images mit null oder nahezu null CVEs bieten Teams einen sauberen Ausgangspunkt – in der Regel in Form einer einzigen Zeilenänderung am Basis-Image. Sowohl die Images als auch deren Open-Source-Bibliotheken werden unabhängig validiert und auf Manipulationen, Malware sowie das Vorhandensein vertraulicher Daten überprüft. Für Teams, die noch einen Schritt weiter gehen möchten, entfernt die RBOM-Härtung die Dateien, Komponenten und Images, die die Produktionsanwendung niemals nutzt. Dadurch wird die Angriffsfläche der Software um bis zu 90 Prozent reduziert und bis zu 99,9 Prozent der CVEs werden eliminiert – ganz ohne Änderungen am Anwendungscode. Kuratierte Images werden alle 24 Stunden neu erzeugt, und bereits ausgenutzte Schwachstellen werden innerhalb eines Tages behoben.

Nichts davon ist ein Schutzschild, das einen KI-Angreifer aufhält. Es ist etwas Nützlicheres: sauberere Eingaben, eine kleinere Angriffsfläche und ein kleineres Zeitfenster. Das sind die Variablen, auf deren Ausnutzung ein automatisierter Angriff ausgelegt ist, und genau diese können Sie tatsächlich kontrollieren.

Der Teil des Kampfes, der weiterhin Ihnen selbst obliegt

KI-gesteuerte Angriffe werden zunehmen. Die dahinterstehenden Tools werden immer kostengünstiger und leichter zugänglich, und man kann getrost davon ausgehen, dass automatisierte Angriffe eher zur Norm als zur Ausnahme werden.

Man kann nicht kontrollieren, wie schnell sich ein Angreifer bewegt. Man kann jedoch kontrollieren, was in die Builds gelangt, wie viel einem Eindringling zugestanden wird, sobald er drinnen ist, und wie lange die Schwachstelle offen bleibt. In einer Welt, in der alles mit Maschinen-Geschwindigkeit abläuft, ist dies der Teil des Kampfes, der immer noch unter der Kontrolle Ihres Unternehmens liegt.