In den letzten Monaten haben wir die Qualität computergenerierter Gesichter, Katzenbilder, Videos, Essays und sogar Kunst bestaunt. Künstliche Intelligenz (KI) und maschinelles Lernen (ML) haben mit Tools wie GitHub Copilot, Tabnine, Polycode, und anderen beteiligt Wir gehen den logischen nächsten Schritt und integrieren die vorhandene Funktion zur automatischen Codevervollständigung in KI-Steroide. Anders als bei Katzenbildern können Herkunft, Qualität und Sicherheit von Anwendungscode jedoch weitreichende Auswirkungen haben – und zumindest für die Sicherheit zeigen Untersuchungen, dass das Risiko real ist.
Vor akademische Forschung hat bereits gezeigt, dass GitHub Copilot häufig Code mit Sicherheitslücken generiert. Dies zeigte kürzlich eine praktische Analyse des Invicti-Sicherheitsingenieurs Kadir Arslan Vorschläge für unsicheren Code sind bei Copilot immer noch eher die Regel als die Ausnahme. Arslan stellte fest, dass Vorschläge für viele gängige Aufgaben nur das Nötigste enthielten und häufig den einfachsten und am wenigsten sicheren Weg einschlugen und dass die Annahme dieser Vorschläge ohne Änderungen zu funktionsfähigen, aber anfälligen Anwendungen führen konnte.
Ein Tool wie Copilot verfügt (von Natur aus) über eine verbesserte Autovervollständigung und ist auf Open-Source-Code trainiert, um Snippets vorzuschlagen, die in einem ähnlichen Kontext relevant sein könnten. Dadurch sind die Qualität und Sicherheit der Vorschläge eng mit der Qualität und Sicherheit des Trainingssatzes verknüpft. Die größeren Fragen beziehen sich also nicht auf Copilot oder ein anderes spezifisches Tool, sondern auf KI-generierten Softwarecode im Allgemeinen.
Man kann davon ausgehen, dass Copilot nur die Speerspitze ist und dass ähnliche Generatoren in den kommenden Jahren alltäglich werden. Das bedeutet, dass wir als Technologiebranche anfangen müssen, uns zu fragen, wie solcher Code generiert wird, wie er verwendet wird und wer die Verantwortung übernimmt, wenn etwas schief geht.
Navi-Syndrom
Die herkömmliche automatische Codevervollständigung, die nach Funktionsdefinitionen sucht, um Funktionsnamen zu vervollständigen und Sie daran zu erinnern, welche Argumente Sie benötigen, spart enorm Zeit. Da diese Vorschläge lediglich eine Abkürzung für das Nachschlagen der Dokumente selbst darstellen, haben wir gelernt, implizit allen Vorschlägen der IDE zu vertrauen. Sobald ein KI-gestütztes Tool eintrifft, ist nicht mehr garantiert, dass seine Vorschläge korrekt sind – aber sie wirken immer noch freundlich und vertrauenswürdig, sodass die Wahrscheinlichkeit größer ist, dass sie akzeptiert werden.
Insbesondere bei weniger erfahrenen Entwicklern fördert die Bequemlichkeit, einen kostenlosen Codeblock zu erhalten, eine Änderung der Denkweise von der Frage „Ist dieser Code nah genug an dem, was ich schreiben würde“ hin zur Frage „Wie kann ich diesen Code optimieren, damit er für mich funktioniert?“.
GitHub gibt sehr deutlich an, dass Copilot-Vorschläge immer sorgfältig analysiert, überprüft und getestet werden sollten, aber die menschliche Natur schreibt vor, dass selbst minderwertiger Code gelegentlich in die Produktion gelangt. Es ist ein bisschen so, als würde man beim Fahren mehr auf das GPS als auf die Straße schauen.
Sicherheitsprobleme in der Lieferkette
Das Log4j-Sicherheitskrise hat kürzlich die Sicherheit der Software-Lieferkette und insbesondere die Open-Source-Sicherheit ins Rampenlicht gerückt Memo des Weißen Hauses über sichere Softwareentwicklung und eine neue Gesetzentwurf zur Verbesserung der Open-Source-Sicherheit. Bei diesen und anderen Initiativen könnte es bald erforderlich sein, Open-Source-Code in Ihren Anwendungen in eine Software-Stückliste (SBOM) zu schreiben, was nur möglich ist, wenn Sie wissentlich eine bestimmte Abhängigkeit einbeziehen. Auch SCA-Tools (Software Composition Analysis) stützen sich auf dieses Wissen, um veraltete oder anfällige Open-Source-Komponenten zu erkennen und zu kennzeichnen.
Was aber, wenn Ihre Anwendung KI-generierten Code enthält, der letztendlich aus einem Open-Source-Trainingssatz stammt? Wenn auch nur ein einziger wesentlicher Vorschlag mit vorhandenem Code identisch ist und unverändert akzeptiert wird, könnte Ihre Software zwar Open-Source-Code enthalten, aber nicht Ihr SBOM. Dies könnte zu Compliance-Problemen führen, ganz zu schweigen von der Möglichkeit einer Haftung, wenn sich der Code als unsicher erweist und zu einem Verstoß führt – und SCA hilft Ihnen nicht weiter, da es nur anfällige Abhängigkeiten finden kann, keine Schwachstellen in Ihrem eigenen Code .
Fallstricke bei Lizenzierung und Namensnennung
Um diesen Gedankengang fortzusetzen: Um Open-Source-Code zu verwenden, müssen Sie dessen Lizenzbedingungen einhalten. Abhängig von der spezifischen Open-Source-Lizenz müssen Sie zumindest eine Quellenangabe angeben oder manchmal Ihren eigenen Code als Open Source veröffentlichen. Einige Lizenzen verbieten die kommerzielle Nutzung gänzlich. Unabhängig von der Lizenz müssen Sie wissen, woher der Code stammt und wie er lizenziert ist.
Und noch einmal: Was passiert, wenn Ihre Anwendung KI-generierten Code enthält, der zufällig mit vorhandenem Open-Source-Code identisch ist? Würde bei einer Prüfung festgestellt, dass Sie Code ohne die erforderliche Quellenangabe verwenden? Oder müssen Sie möglicherweise einen Teil Ihres kommerziellen Codes als Open Source veröffentlichen, um konform zu bleiben? Vielleicht ist das mit den aktuellen Tools noch kein realistisches Risiko, aber das sind die Fragen, die wir uns alle heute stellen sollten, und nicht in 10 Jahren. (Und um es klarzustellen: GitHub Copilot verfügt über einen optionalen Filter, um Vorschläge zu blockieren, die mit vorhandenem Code übereinstimmen, um Risiken in der Lieferkette zu minimieren.)
Tiefergehende Auswirkungen auf die Sicherheit
Zurück zur Sicherheit: Ein KI/ML-Modell ist nur so gut (und so schlecht) wie sein Trainingssatz. Das haben wir in der Vergangenheit gesehen - zum Beispiel in Fällen von Gesichtserkennungsalgorithmen zeigen rassistische Vorurteile aufgrund der Daten, auf denen sie trainiert wurden. Wenn wir also Untersuchungen haben, die zeigen, dass ein Codegenerator häufig Vorschläge ohne Rücksicht auf die Sicherheit erstellt, können wir daraus schließen, dass sein Lernsatz (d. h. öffentlich verfügbarer Code) so aussah. Und was passiert, wenn unsicherer KI-generierter Code dann in diese Codebasis zurückfließt? Können die Vorschläge jemals sicher sein?
Die Sicherheitsfragen hören hier nicht auf. Wenn KI-basierte Codegeneratoren an Popularität gewinnen und einen bedeutenden Anteil des neuen Codes ausmachen, ist es wahrscheinlich, dass jemand versuchen wird, sie anzugreifen. Es ist bereits möglich, die KI-Bilderkennung zu täuschen, indem man ihren Lernsatz vergiftet. Früher oder später werden böswillige Akteure versuchen, besonders anfälligen Code in öffentlichen Repositories abzulegen, in der Hoffnung, dass er in Vorschlägen auftaucht und schließlich in einer Produktionsanwendung landet, was ihn für einen einfachen Angriff anfällig macht.
Und was ist mit der Monokultur? Wenn mehrere Anwendungen am Ende denselben äußerst anfälligen Vorschlag verwenden, unabhängig von seiner Herkunft, könnte es sich um Schwachstellenepidemien oder vielleicht sogar um KI-spezifische Schwachstellen handeln.
Behalten Sie die KI im Auge
Einige dieser Szenarien mögen heute weit hergeholt erscheinen, aber sie sind alles Dinge, über die wir in der Technologiebranche diskutieren müssen. Auch hier steht GitHub Copilot nur deshalb im Rampenlicht, weil es derzeit führend ist und GitHub klare Warnungen vor den Vorbehalten von KI-generierten Vorschlägen ausgibt. Wie bei der automatischen Vervollständigung auf Ihrem Telefon oder den Routenvorschlägen in Ihrem Navigationsgerät handelt es sich lediglich um Hinweise, die uns das Leben erleichtern sollen, und es liegt an uns, sie anzunehmen oder zu lassen.
Mit ihrem Potenzial, die Entwicklungseffizienz exponentiell zu verbessern, werden KI-basierte Codegeneratoren wahrscheinlich ein dauerhafter Bestandteil der Softwarewelt werden. Im Hinblick auf die Anwendungssicherheit ist dies jedoch eine weitere Quelle potenziell anfälliger Codes, die strenge Sicherheitstests bestehen müssen, bevor sie in die Produktion gelangen dürfen. Wir suchen nach einer völlig neuen Möglichkeit, Schwachstellen (und möglicherweise ungeprüfte Abhängigkeiten) direkt in Ihren Erstanbieter-Code einzuschleusen. Daher ist es sinnvoll, KI-erweiterte Codebasen bis zum Test als nicht vertrauenswürdig zu behandeln – und das bedeutet, dass Sie alles so oft testen müssen wie Sie dürfen.
Selbst relativ transparente ML-Lösungen wie Copilot werfen bereits einige rechtliche und ethische Fragen auf, ganz zu schweigen von Sicherheitsbedenken. Aber stellen Sie sich vor, dass eines Tages ein neues Tool anfängt, Code zu generieren, der perfekt funktioniert und Sicherheitstests besteht, bis auf ein kleines Detail: Niemand weiß, wie er funktioniert. Dann ist es Zeit, in Panik zu geraten.
