KI-Code-Generatoren: Wie viel Kontrolle ist nötig?

KI als Codierungsassistent

Die Art und Weise, wie Entwickler ihre KI-Coding-Tools einsetzen, variiert. So lässt sich KI beispielsweise ganz simpel verwenden, um Codezeilen vorausschauend zu vervollständigen, während sie geschrieben werden. Das Ganze kann allerdings auch deutlich komplexer sein. Etwa beim Schreiben von Codekommentaren als Prompts. Dann wird die KI anschließend verwendet, um eine komplette Methode oder Funktion auf Basis dieses Prompts zu generieren. Das erste Beispiel ist strukturell ähnlich zu den Vorschlägen, die Microsoft Outlook liefert, um Sätze zu komplettieren. Das zweite Beispiel lässt sich eher verstehen als eine Aufforderung in dieser Art: „Senden Sie eine E-Mail an meine Chefin, um ihr den Status hinsichtlich aller Jira-Tickets mitzuteilen, mit deren Bearbeitung wir derzeit im Rückstand sind.“

Unabhängig davon, wie weitreichend man KI zur Codegenerierung einsetzt, man sollte nicht vergessen, dass diesen Kodierungsassistenten in der Regel der kritische Kontext der gesamten Anwendung fehlt. Das heißt, selbst wenn diese LLMs auf Basis von sicherem und qualitativ hochwertigem Code trainiert werden, ist es schwer, Sicherheits- und Compliance-Probleme zu vermeiden. Jedenfalls wenn man nicht weiß, wie der generierte Code verwendet wird. Tools wie GitHub CoPilot sind hervorragend geeignet, um sehr zügig eine Funktion für die Bearbeitung von zum Beispiel HTTP-Anfragen bereitzustellen. Trotzdem sollte man darüber nachdenken, wie die von einem Benutzer bereitgestellten Eingaben behandelt werden. Kümmert sich der KI-generierte Code darum? Ruft er eine separate Bibliothek auf, um die Eingaben zu verarbeiten? Oder ist es ganz allein die Sache des jeweiligen Entwicklers, das herauszufinden?

Sicherheitsprobleme durch KI

Wie schon erwähnt, fehlt einer KI der größere Kontext einer Anwendung. Dieses mangelnde Verständnis, kann dazu führen, dass es zu Sicherheitsschwachstellen kommt. Und das unabhängig von der Qualität des Codes, mit dem ein Large Language Model trainiert wurde. Der Fairness halber sollte man anmerken, dass dies kein alleiniges Problem von KI-Codierungsassistenten ist - damit haben auch menschliche Entwickler zu kämpfen. Laut dem eingangs zitierten OSSRA-Bericht weisen 84 Prozent der untersuchten Codebasen Schwachstellen auf. Es ist aber schwierig einzuschätzen, ob diese Schwachstellen auf menschliche oder KI-basierte Entwicklungstätigkeiten zurückgehen. Schon allein deshalb sollte man beiden die gleiche Aufmerksamkeit widmen.

Sicherheitsprobleme, die ihren Weg in den Quellcode gefunden haben (wie die in den OWASP Top 10 beschriebenen), erweisen sich oft als sehr komplex. Zudem sind sie bei einer manuellen Überprüfung nur schwer zu erkennen. Entsprechend schwierig ist es, sie zu vermeiden, vor allem wenn man sich nur auf einen kleinen Teil der gesamten Anwendung konzentriert. Genau aus diesem Grund setzen die meisten Entwicklungsteams Code-Review-Tools wie die statische Analyse ein. Sie durchlaufen die gesamte Anwendung, erfassen den Kontext des Informationsflusses und erkennen knifflige Probleme, die zu Exploits wie Cross-Site Scripting, SQL Injection und anderen führen können. Es empfiehlt sich also, KI-generierten Quellcode wie jeden anderen von Entwicklern geschriebenen Quellcode auf Sicherheitsprobleme hin zu prüfen.

Durch KI verursachte Probleme beim Einhalten von Lizenzbestimmungen

Es steht außer Frage, dass KI-Code-Generatoren die Diskussion um das Einhalten von Open-Source-Lizenzbestimmungen neu entfachen werden. Eine Reihe von Klagen wurde bereits im Namen einiger Programmierer eingereicht. Demnach hätten GitHub CoPilot, Microsoft und OpenAI gegen beigefügte Projektlizenzen verstoßen. Zugegebenermaßen stützt die Logik die Ansprüche der Kläger: die besagten LLMs wurden auf Open Source Code trainiert. Beim Prompten generieren diese Tools einen Code, der dem Code, auf den sie trainiert wurden, ähnlich wenn nicht sogar identisch mit ihm ist.

Anscheinend liegt die Stärke dieser LLMs in ihrer Fähigkeit, Eingabeaufforderungen in relevanten Code zu übersetzen, und eben nicht in der Fähigkeit, brandneuen, ursprünglichen Code zu produzieren. Wenn der resultierende Code der ursprünglichen Quelle ähnlich genug ist, kommt zudem die Frage der IP-Verpflichtungen hinsichtlich geistigen Eigentums ins Spiel.

„Unabhängig davon, wie weitreichend man KI zur Codegenerierung einsetzt, man sollte nicht vergessen, dass diesen Kodierungsassistenten in der Regel der kritische Kontext der gesamten Anwendung fehlt.“

Mike McGuire. Synopsys Software Integrity Group

Offensichtlich sind viele Fragen in Bezug, auf den von einer KI erzeugten Code noch offen. Wie ähnlich ist dieser Code den Quellen, aus denen er gelernt hat? Welches sind diese Quellen, denen er möglicherweise ähnelt? Welche Lizenzverpflichtungen sind mit ihnen verbunden? In welchem Maß sollte sich der Code, von dem seiner Quelle unterscheiden, um das rechtliche Risiko angemessen zu senken? Keine dieser Fragen lässt sich im Moment mit Sicherheit beantworten. Und wenn es etwas gibt, das Rechtsabteilungen missfällt, dann Fragen, die sich nicht beantworten und Risiken, die sich nicht einschätzen lassen.

Glücklicherweise existieren heute Tools, die Quellcode analysieren und ohne zusätzliche Metadaten dem Projekt zuordnen können, aus dem er stammt. Von dort aus kann man den Lizenzkontext ermitteln und die daraus resultierenden Verpflichtungen erfüllen oder problematische Abhängigkeiten beseitigen.

An neue Technologien anpassen

Letztendlich sind KI-Code-Generatoren für Softwareentwickler vielseitig nutzbar. Etwa, um eine Software schneller auf den Markt zu bringen, Kundenanforderungen umzusetzen und sich von der Konkurrenz abzuheben. Der rasante Anstieg bei der Nutzung von generativer KI im Bereich der Softwareentwicklung erinnert an die Erfolgsgeschichte von Open Source Software beim Einsatz in kommerziellen Anwendungen. Anfangs gab es reichlich Skeptiker. Vielfach wurden Bedenken laut – sei es hinsichtlich der Sicherheit, sei es hinsichtlich der Qualität des Codes. Trotzdem ist es etlichen Firmen gelungen, sich auf die eigentlichen Vorteile zu konzentrieren. Sie haben für sich erkannt, dass es nicht darum gehen kann, die neue Technologie dauernd in Frage zu stellen oder gar zu verteufeln. Stattdessen haben sie nach Wegen gesucht, sich an die veränderten Gegebenheiten anzupassen.

So sollte man es auch beim Einsatz von KI-Assistenten handhaben, die Code generieren können. Der Code einiger LLMs wird vermutlich sicherer sein als der von anderen, und einige werden besser in der Lage sein, den Code zu modifizieren, um IP-Probleme auszuschließen. Den größten Nutzen aus KI-basierter Code-Generierung werden diejenigen ziehen, die diesen Code wie jeden anderen Code in ihrer Anwendung auch behandeln. Er wird denselben Prüfungen unterworfen, um Risiken so weit wie möglich zu senken.

Die Überprüfung von KI-generiertem Code ist derzeit wohl einfacher, als die damit verbundenen Risiken in der Gänze verstehen zu wollen. Tools zur Software Composition Analysis untersuchen, wie genau sich eine Software zusammensetzt, einschließlich von Open Source. SCA-Tools nehmen analog auch KI erzeugte Codezeilen unter die Lupe, und warnen beispielsweise Risikomanagement-Teams, wenn sie lizenzgeschützter Software zu sehr ähneln.

Auf der Sicherheitsseite behandeln Tools zur statischen Analyse, den von der KI erzeugten Code wie jeden anderen Quellcode auch. Sie simulieren den Anwendungsfluss und identifizieren etwaige Sicherheitslücken oder CWEs. Entwickler können so mit zwei simplen Schritten die Vorteile einer generativen KI nutzen, ohne sich deren Risiken auszusetzen. Diese auszumerzen, dafür haben sie ohnehin schon hart genug gearbeitet.

Über den Autor:
Mike McGuire ist Senior Software Solutions Manager bei der Synopsys Software Integrity Group.

Die Autoren sind für den Inhalt und die Richtigkeit ihrer Beiträge selbst verantwortlich. Die dargelegten Meinungen geben die Ansichten der Autoren wieder.