Schwachstellen durch KI-generierten Code: Ein neues Risiko für die IT-Sicherheit?

Künstliche Intelligenz hat sich in der Softwareentwicklung als nützliches Werkzeug etabliert – doch sie bringt eigene Risiken mit. Kürzlich habe ich selbst ein kleines Script mit ChatGPT generiert. Auf den ersten Blick schien alles in Ordnung, doch bei genauerem Hinsehen fielen mir einige Variablen und Funktionen auf, die keinen erkennbaren Nutzen hatten. Nach einer kurzen Analyse war klar: Solche überflüssigen Codeelemente sind nicht nur unsauber – je nach Einsatzgebiet können sie zusätzliche Angriffsfläche schaffen und unerwartete Sicherheitslücken öffnen.

Der entscheidende Punkt dabei: Ich habe es nur bemerkt, weil ich den Code überhaupt geprüft habe. Und genau das ist der Kern des Problems.

Warum KI unsicheren Code erzeugt

Einer der häufigsten Irrtümer im Umgang mit generativer KI – insbesondere mit großen Sprachmodellen (LLMs wie ChatGPT) – ist die Annahme, diese Modelle würden eine Frage so verstehen und interpretieren wie ein Mensch. Tatsächlich tun sie nichts anderes, als auf Grundlage ihrer Trainingsdaten vorherzusagen, was die plausibelste nächste Ausgabe ist – ob bei einer Antwort oder bei der Vervollständigung von Code. Ohne echtes Verständnis für Kontext oder Sicherheit schlägt ein Modell mühelos Code mit unsicheren Funktionen, fehlender Eingabevalidierung oder hartkodierten Zugangsdaten vor.

Das ist kein Randphänomen. Der GenAI Code Security Report 2025 von Veracode untersuchte über 100 Sprachmodelle und kam zu dem Ergebnis, dass rund 45 % des KI-generierten Codes Schwachstellen aus den OWASP Top 10 enthielten (Help Net Security). Andere Analysen kommen auf eine etwa 2,7-mal höhere Schwachstellendichte gegenüber von Menschen geschriebenem Code. Bemerkenswert: Neuere und größere Modelle schnitten dabei kaum besser ab – mehr Rechenleistung allein löst das Sicherheitsproblem nicht.

Das eigentliche Risiko: trügerische Sicherheit

Noch gefährlicher als der unsichere Code selbst ist oft das Vertrauen, das ihm entgegengebracht wird. Studien zeigen, dass Entwicklerinnen und Entwickler mit KI-Unterstützung tendenziell unsichereren Code schreiben – sich dabei aber sicherer fühlen. Eine viel beachtete Untersuchung der Stanford University fand genau diesen Effekt: Wer KI nutzte, produzierte mehr Schwachstellen und bewertete die eigenen Lösungen zugleich als sicherer. KI erzeugt also nicht nur Schwachstellen, sondern auch ein falsches Sicherheitsgefühl, das die kritische Prüfung untergräbt, die man sonst angewandt hätte.

Genau hier schließt sich der Kreis zu meinem eingangs erwähnten Script: Der überflüssige Code wäre niemandem aufgefallen, der ihn ungeprüft übernimmt.

Ein wirklich neues Risiko: „Slopsquatting"

Manche Risiken sind alte Bekannte in neuem Gewand – andere sind tatsächlich neu. Ein gutes Beispiel ist „Slopsquatting", ein Begriff, der vom Sicherheitsforscher Seth Larson geprägt wurde und an das bekannte „Typosquatting" angelehnt ist.

Der Hintergrund: LLMs neigen dazu, Paketnamen zu halluzinieren – also Bibliotheken vorzuschlagen, die gar nicht existieren. Eine Studie mit 16 Code-Modellen und hunderttausenden Beispielen ergab, dass rund 20 % der vorgeschlagenen Pakete nicht real waren. Entscheidend ist, dass diese Halluzinationen nicht zufällig sind: Bei wiederholten Anfragen tauchten viele derselben erfundenen Namen immer wieder auf. Genau diese Vorhersagbarkeit machen sich Angreifer zunutze. Sie registrieren häufig halluzinierte Paketnamen mit Schadcode auf öffentlichen Registries wie PyPI oder npm. Wer den KI-Vorschlag ungeprüft installiert, holt sich Malware direkt in die Lieferkette (BleepingComputer). MITRE ATT&CK führt diesen Angriffsweg unter „Compromise Software Supply Chain" (T1195).

Vor wenigen Jahren gab es diesen Angriffsvektor schlicht nicht. Er ist ein direktes Nebenprodukt der breiten KI-Nutzung – und damit eine klare Antwort auf die Frage im Titel: Ja, KI-generierter Code bringt neue Risiken mit sich.

Was man dagegen tun kann

Grundsätzlich gilt: KI-generierter Code sollte denselben strengen Sicherheitsprüfungen unterzogen werden wie von Menschen geschriebener Code – inklusive Pentests und Source-Code-Reviews. Einen lesenswerten Überblick dazu liefert dieser Artikel von Forbes.

Bei kurzen Scripts, die man im Entwicklungsalltag schnell generiert, würde eine vollständige Sicherheitsüberprüfung allerdings dem eigentlichen Zweck der KI widersprechen – nämlich schnell und effizient funktionierenden Code zu erhalten. Für diese Fälle ein paar einfache, aber wirkungsvolle Maßnahmen, um Schwachstellen schon bei der Generierung zu reduzieren:

• Sicherheit von Anfang an einfordern. Weist die KI explizit an, sicheren Code zu erzeugen und sich an die OWASP Secure Coding Practices zu halten.
• Den Code erklären lassen. Lasst die KI den generierten Code Schritt für Schritt erläutern – das deckt überflüssige oder unklare Elemente schnell auf.
• Die KI gegen sich selbst antreten lassen. Lasst das Modell den eigenen Code auf Schwachstellen prüfen und nach Security-Best-Practices verbessern.
• Abhängigkeiten verifizieren. Prüft jedes von der KI vorgeschlagene Paket, bevor ihr es installiert: Existiert es wirklich, wer ist der Herausgeber, seit wann ist es registriert? Das ist die einfachste Verteidigung gegen Slopsquatting.

Diese Schritte ersetzen keine vollständige Sicherheitsüberprüfung wie einen Pentest oder ein Source-Code-Review – aber sie heben die Codequalität schon während der Entwicklung spürbar an.

Wenn es ernst wird

Wenn es dann an die eigentliche Sicherheitsüberprüfung geht, stehe ich bei HSEC.Consulting mit technologie- und branchenspezifischer Expertise zur Verfügung – sei es für einen Pentest, ein Source-Code-Review oder eine fundierte Einschätzung, wie sich KI sicher in eure Entwicklungsprozesse integrieren lässt. 😉

#CyberSecurity #AI #KISicherheit #SecureCoding #Pentesting