Understanding the Impact of AI Code Assistants on Security API Usage: An Empirical Study
Diese empirische Studie von 44 professionellen Entwicklern zeigt auf, dass GitHub Copilot zwar die funktionale Korrektheit verbessert und einige unsichere Muster geringfügig reduziert, es jedoch versäumt, die sichere Verwendung von Sicherheits-APIs signifikant zu verbessern, wodurch Entwickler oft über verbleibende Schwachstellen nicht im Klaren sind.
Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Stellen Sie sich vor, Sie bauen ein supergeheimes Baumhaus und müssen hochtechnologische Schlösser, Alarme und Geheimtunnel installieren, um Eindringlinge fernzuhalten. Diese Schlösser sind wie Security-APIs – spezielle Werkzeuge, die Entwickler nutzen, um Software zu schützen. Aber hier ist der Clou: Diese Schlösser sind tückisch. Wenn man sie falsch installiert, könnte der „Geheimtunnel“ einfach eine weit offen stehende Tür für Hacker sein.
Stellen Sie sich nun vor, Sie haben einen superintelligenten Roboter-Assistenten namens Copilot, der Code für Sie schreiben kann. Sie könnten denken: „Großartig, der Roboter kennt alle Regeln, also wird mein Baumhaus wie Fort Knox sein!“ Aber eine neue Studie von Zahra Mousavi und ihrem Team an Universitäten und Forschungslaboren in Australien beschloss, genau diese Idee auf die Probe zu stellen. Sie haben den Roboter nicht nur gebeten, ein Schloss zu bauen; sie haben 44 echte professionelle Entwickler dabei beobachtet, wie sie versuchten, diese Schlösser zu bauen – sowohl mit Hilfe des Roboters als auch ohne ihn.
Hier ist das, was sie herausgefunden haben, serviert mit einer Portion Realität.
Der Roboter ist ein großartiger Helfer, aber ein schlechter Sicherheitswächter
Zuerst die guten Nachrichten: Copilot ist ein fantastischer Sprinter. Als die Entwickler ein komplexes Schloss bauen mussten (speziell ein Google-OAuth-System für den Zugriff auf Benutzerdaten), half ihnen der Roboter, die Aufgabe viel schneller zu erledigen.
- Ohne den Roboter bekamen nur 45 % der Entwickler (10 von 22) das Schloss überhaupt zum Laufen.
- Mit dem Roboter bekamen 91 % der Entwickler (20 von 22) es zum Laufen.
- Der Roboter verkürzte zudem die Zeit, die für die komplexe Aufgabe benötigt wurde, um 63 % – die durchschnittliche Zeit sank von 62 Minuten auf 23 Minuten.
Wenn Ihr Ziel also nur ist, die Tür zu bauen und sie schwingen zu lassen, ist der Roboter ein riesiger Gewinn.
Aber hier ist der Haken: Nur weil die Tür gebaut ist, heißt das noch lange nicht, dass sie abgeschlossen ist. Tatsächlich hat keiner der Entwickler, egal ob sie den Roboter benutzten oder nicht, es geschafft, ein vollständig sicheres Schloss für die Aufgaben zu bauen, die ihnen gestellt wurden. Jeder einzelne Versuch bei den evaluierten Aufgaben wies mindestens eine schwerwiegende Schwachstelle auf.
Die „Vertrau mir“-Falle
Die Studie untersuchte zwei spezifische Arten von Schlössern: JSSE (für sichere Internetverbindungen) und Google OAuth (für das Einloggen in Apps). Sie fanden heraus, dass der Roboter die Sicherheitsprobleme nicht behob; in vielen Fällen half er lediglich dabei, die kaputten Schlösser schneller zu bauen.
- Der „Vertraue allen“-Fehler: Stellen Sie sich einen Wächter vor, der jeden reinlässt, nur weil er nett aussieht. In der Studie richteten einige Entwickler (und der Roboter) das System so ein, dass es „alle Zertifikate vertraut“. Das ist so, als würden Sie Ihrem Wächter sagen: „Wenn jemand einen Ausweis zeigt, lass ihn rein, selbst wenn es ein gefälschter ist.“ Das ist ein riesiges Sicherheitsloch.
- Der „Geheimcode“-Fehler: Einige Entwickler schrieben ihre geheimen Passwörter direkt in den Code, so wie man seinen Hausschlüssel unter die Fußmatte legt. Der Roboter schlug dies manchmal auch vor!
- Der „Keine Prüfung“-Fehler: Wenn man eine Verbindung zu einem Server herstellt, muss man prüfen, ob man tatsächlich mit der richtigen Person spricht. Viele Implementierungen übersprangen diesen Schritt, wodurch die Tür für einen „Man-in-the-Middle“-Angreifer offen stand (jemand, der vorgibt, Ihr Freund zu sein, um Ihre Sachen zu stehlen).
Die Forscher fanden heraus, dass der Roboter zwar half, einige kleine Fehler zu beheben, aber die großen Sicherheitsfehler nicht verhinderte. Tatsächlich führten 100 % der evaluierten Aufgaben zu Code mit Sicherheitsmängeln. Der Roboter machte den Code nicht sicherer als die Menschen, die alleine arbeiteten; er ließ den unsicheren Code nur schneller erscheinen.
Der blinde Fleck des Menschen
Dies ist der überraschendste Teil der Geschichte. Die Forscher fragten die Entwickler: „Glauben Sie, dass Ihr Code sicher ist?“
- Obwohl keiner der Codes tatsächlich sicher war, sagten die meisten Entwickler: „Ja, ich denke, ich habe das sicher gelöst!“
- Nur eine sehr kleine Anzahl von Leuten bemerkte, dass sie einen Fehler gemacht hatten.
- Wenn sie mit dem Roboter sprachen, fragten fast niemanden: „Hey, ist das sicher?“ Sie fragten nur: „Lass es funktionieren.“
Es ist, als würde eine Gruppe von Menschen eine Brücke bauen und einen Roboter um Hilfe bitten. Der Roboter hilft ihnen, die Steine schnell zu legen, aber niemand prüft, ob die Brücke tatsächlich Gewicht tragen kann. Wenn gefragt wird: „Glauben Sie, dass diese Brücke halten wird?“, sagen die meisten Leute: „Sicher!“, obwohl sie kurz vor dem Einsturz steht.
Können wir den Roboter besser lehren?
Die Forscher versuchten noch eine Sache. Sie baten die Entwickler, dem Roboter explizit zu sagen: „Hey, prüfe das auf Sicherheit!“ oder „Du bist ein Sicherheitsexperte, behebe das!“
- Wenn sie dies taten, korrigierte der Roboter tatsächlich einige der Fehler im einfacheren Schloss (JSSE).
- Beim komplexeren Schloss (OAuth) übersah der Roboter jedoch auch dann noch viele kritische Sicherheitslücken, selbst wenn man ihm sagte, er solle vorsichtig sein.
Das Fazntit
Diese Studie deutet darauf an, dass KI-Assistenten wie Copilot zwar großartig dabei sind, uns zu helfen, Code schnell und korrekt zu schreiben, aber sie sind kein magischer Schutzschild gegen Hacker.
- Der Roboter: Großartig bei Geschwindigkeit und Funktionalität, aber kein Sicherheitsexperte.
- Die Menschen: Oft zu vertrauensvoll gegenüber dem Roboter und prüfen die Sicherheit selbst nicht ausreichend.
- Das Ergebnis: Wir bauen scheinbar sichere Systeme, die in Wirklichkeit voller Löcher sind.
Die Forscher kommen zu dem Schluss, dass wir uns nicht einfach auf den Roboter verlassen können, um uns sicher zu halten. Wir müssen diejenigen sein, die die schwierigen Sicherheitsfragen stellen, die Arbeit überprüfen und sicherstellen, dass die „Schlösser“, die wir bauen, auch wirklich verschlossen sind. Der Roboter ist ein mächtiges Werkzeug, aber er ist kein Ersatz für einen sicherheitsbewussten Verstand.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.