3 KI-Fehler, die die Sicherheit nachhaltig gefährden

Wenn Ihre KI unkontrolliert Implementierungsentscheidungen trifft, wissen das vor allem Cyberkriminelle zu schätzen.wee dezign | shutterstock.com



Es wird viel darüber gesprochen, dass KI immer stärker Einzug in die Produktionssysteme von Unternehmen hält. Diese Realität ist allerdings längst eingetreten – und kann, je nachdem, wie Organisationen damit umgehen, zum Albtraum geraten.



Meist beginnen KI-Initiativen als Pilotprojekt oder Prototyp. Zum Beispiel wenn jemand mit einem Agenten ein internes Dashboard erstellt. Dieses wird dann oft schnell unverzichtbar – und schon ist aus dem Experiment ein System im Produktivbetrieb geworden. Leider wird gerade in solchen Situationen allzu oft vergessen, die zwar langweiligen und unbequemen, aber enorm wichtigen Fragen zu stellen. Etwa:




Welche Komponenten für das Projekt wurden über npm, PyPI oder Docker Hub bezogen?



Wie ist (oder war) die Authentifizierung konfiguriert?



Werden die vom Agenten gewählten Tools und Bibliotheken mit Blick auf mögliche Supply-Chain-Angriffe im Blick behalten?




Das ist besonders problematisch, weil KI es ermöglicht, schneller als je zuvor Code zu generieren und Produkte auf den Markt zu bringen. Deshalb bleibt es in den meisten Unternehmen auch nicht bei einem Projekt oder ein paar einzelnen Apps.



Bis das Security-Team dann einen Blick auf diese KI-Erzeugnisse werfen kann, ist das Business bereits der Sucht nach Generative AI erlegen und es gibt kein Zurück mehr. Das ist der Stoff, aus dem Security-Albträume gemacht sind. Dass diese zur Realität werden können, hängt regelmäßig vor allem mit den folgenden drei Fehlern, beziehungsweise Missständen zusammen.



1. Maschinelle Naivität



Wenn Sie einen KI-Agenten bitten, eine App zu erstellen, spuckt dieser nicht einfach nur ein einzelnes Skript aus. Er baut still und leise ein ganzes Ökosystem rund um das von Ihnen beschriebene Problem auf. Er bindet ein Web-Framework ein, holt sich eine Reihe von Bibliotheken, richtet Datenbanken ein und baut dann möglicherweise alles auf Basis der Abhängigkeiten in Container-Images auf.



Aus Produktivitätssicht ist das großartig. Aus Security-Perspektive ist es, gelinde gesagt, besorgniserregend. Ich habe selbst schon Apps auf diese Art und Weise erstellt. Und ich konnte nicht einmal ansatzweise nachvollziehen, welche Komponenten dabei eingeflossen sind – ohne den KI-Agenten explizit danach zu fragen.  



Heute kann jeder auf npm oder PyPI etwas veröffentlichen. Das wissen bekanntlich auch Angreifer, die in der Vergangenheit bereits schadhafte Packages in diese Entwickler-Ökosysteme eingeschleust – oder weit verbreitete kompromittiert – haben.



Bei einigen dieser Vorfälle haben Security- und DevOps-Tools selbst kompromittierte Abhängigkeiten aufgerufen und diese im Rahmen von CI/CD mit erweiterten Berechtigungen ausgeführt. Heimlich gestohlene Secrets oder manipulierte Builds waren das Resultat. Ich habe das auch schon am eigenen Leib erfahren und musste wegen einer ähnlichen Kompromittierung meine Zugangsdaten bei GitHub umfassend aktualisieren.



Kommen in so einem Szenario KI-Agenten ins Spiel, verschärft das die Gemengelage deutlich: Diese entscheiden sich schließlich standardmäßig für die Lösung, die am einfachsten zu finden und zu integrieren ist. Löst ein Paket ein Problem, wird der Agent es hinzufügen.



Im Grunde taucht damit eine Problemstellung wieder auf, die wir eigentlich schon seit den späten 1990er-Jahren hinter uns gelassen haben sollten: Es ist nach wie vor keine gute Idee, Dinge nach dem Zufallsprinzip aus dem Netz herunterzuladen. Der Unterschied zu damals: Mit KI-Agenten geschieht das automatisiert, in großem Maßstab und in maschinellem Tempo.



Auflösen lässt sich dieses Problem zum Beispiel, indem wir KI-Agenten:




ein tiefes Verständnis für unsere Risikotoleranz vermitteln,



eine Liste mit zugelassenen Komponenten übergeben, oder



mit spezifischen Vorgaben füttern.




Das lässt sich mit Spec-Dateien und dem, was in der Branche als „Constitutions“ bezeichnet wird, erreichen. Dieses Vorgehen wird auch gerne unter dem Begriff „Harness Engineering“ zusammengefasst (dazu gleich mehr).



2. Unkritisches Denken



Es wurde bereits ausgiebig über die Frage spekuliert, wie Junior Developer künftig das Programmierhandwerk erlernen sollen, wenn die KI die Arbeit für sie erledigt. Das bereitet mir allerdings keine Sorgen. Code zu generieren, ist meiner Einschätzung nach ein Task, den die Technologie gut beherrscht. Weniger fähig ist die KI, wenn es darum geht, Probleme im Code zu erkennen – und zu vermeiden. 



Ich selbst habe schon seit geraumer Zeit keinen Code mehr geschrieben. Das könnte ich zwar, aber es macht für mich keinen Sinn, das zu tun. Ich investiere die Zeit lieber dafür, darauf zu achten, ob der KI-Agent etwas Dummes oder gar Gefährliches (oder auch beides) vorschlägt.



Als ich zum Beispiel kürzlich an einem privaten Projekt gearbeitet habe, hat mir die KI (indirekt) vorgeschlagen, einen Memory-Server ohne Authentifizierung mit dem Internet zu verbinden. Dabei hat der Agent alles so reibungslos eingerichtet, dass auf den ersten Blick alles gut und funktional aussah.



Erst in einem Moment der Stille kam ich zu mir und fragte mich, wie dabei eigentlich die Authentifizierung abläuft. Daraufhin stellte sich heraus, dass keine stattfand und es auch kein Passwort gab. Hätte ich in diesem Fall nicht kurz innegehalten – und mich anschließend eine Weile mit dem Agenten herumgestritten –, wäre die App ohne jegliche Schutzmaßnahmen live gegangen.



Das eigentliche Skills-Problem dreht sich also nicht um die Frage, ob unsere Fähigkeit zu programmieren verlorengeht. Vielmehr darum, ob wir:




die nötigen Kompetenzen haben, um die richtigen, kritischen Fragen zu stellen, und



das Verständnis, das nötig ist, um zu erkennen, wann etwas nur richtig aussieht.




Man braucht Menschen, die es erkennen, wenn eine Architektur zu einem großen Haufen technischer Schulden verkommen ist. Und die wissen, dass die richtige Lösung darin besteht, eine ganze Schicht abzutragen und neu aufzubauen.



Es geht also nicht um Syntax. Sondern um Architektur, ein Bewusstsein für die Lieferkette und die Bereitschaft, die Dinge von Anfang an richtig aufzusetzen – selbst wenn der Prototyp oberflächlich überzeugend wirkt.



Es empfiehlt sich deshalb, Entwicklern, die mit KI arbeiten, grundlegende Security-Prinzipien und Architekturmuster zu vermitteln. Die KI wird ihnen die fortgeschritteneren Dinge beibringen – solange die Devs weiterhin Fragen stellen.



3. Zügellose Agenten



Das dritte Problem besteht darin, dass wir einige sehr fähige Agenten in unsere Entwicklungsabläufe integriert haben. Und diese dabei nicht wie vollwertige Akteure behandeln, die einer Steuerung bedürfen.



Viele Unternehmen binden KI-Assistenten in ein Repo oder eine IDE ein und lassen sie Projekte und Pipelines aufsetzen. Vielleicht fügen sie noch einen Security-Scanner hinzu und deklarieren dann ein erfolgreiches „AI Enablement“. In so einem Fall von Steuerungsmodell zu sprechen, wäre schlicht gelogen. Im besten Fall könnte man das Vorgehen „optimistisch“ nennen.



Ein Agent, der Code generiert und dabei umfassenden Zugriff auf Repositories, CI/CD-Pipeline und Artefakt-Register hat, kommt im Grunde einem hyperproduktiven, aber nicht besonders gut ausgebildetem Nachwuchsentwickler gleich: Er kann neue Tools, Abhängigkeiten und Muster schneller einführen, als Ihre Review-Prozesse Schritt halten können.



Ich betrachte das als „Harness-Engineering-Problem“. Um es aufzulösen, versuche ich für jeden Agenten, der Code erstellt oder verknüpft, einen weiteren Agenten in den Prozess einzubinden. Diese „Zusatz-KI“ ist dafür verantwortlich, den generierten Code – zumindest konzeptionell – wieder zu zerlegen. Ein Agent fokussiert sich beispielsweise auf die Sicherheit und sucht nach offensichtlichen Schwachstellen und schlechten Praktiken. Ein anderer befasst sich mit der Architektur und weist darauf hin, wenn das App-Design in einen Bereich abdriftet, der nicht mehr wartbar ist. Ein dritter prüft Performance- und Zuverlässigkeitsprobleme, die selbst eine Art Sicherheitsrisiko darstellen können.



Kombiniert man diesen Ansatz mit „Constitutions“, die den KI-Agenten Grundprinzipien zu Architektur, Security und Design vorgeben, wird Vibe Coding zu Harness Engineering – und zwar in großem Maßstab.  



Zur Wahrheit gehört auch: Mein Ansatz ist nicht perfekt. Weil es sich in diesem Bereich um nicht-deterministische Tools handelt, ist ein Zustand der Perfektion auch nicht existent. Aber viele Organisationen bleiben komplett untätig, während ihre KI-Agenten wie Freiberufler arbeiten und nach „Gefühl“ programmieren. Diese sind dann weder an vertrauenswürdige Register noch an gehärtete Basis-Images gebunden, protokollieren ihre Entscheidungswege nicht und können so auch nicht vom Security-Team unter die Lupe genommen werden.



Wenn niemand für das „Harness“ verantwortlich zeichnet, werden diverse Implementierungsentscheidungen vollständig auf Systeme verlagert, die niemand wirklich überwacht. Dann ist es nur eine Frage der Zeit, bis der Security-Albtraum real wird. (fm)



Dieser Artikel ist im Original bei unserer Schwesterpublikation Infoworld.com erschienen.