5 bewährte Sicherheitspraktiken für den Einsatz von generativen KI-Code-Assistenten wie GitHub Copilot

Noch vor nicht allzu langer Zeit galt KI im Allgemeinen als futuristische Idee wie aus einem Science-Fiction-Film. Filme wie Her und Ex Machina warnten uns sogar davor, dass KI eine Büchse der Pandora sein könnte, die, einmal geöffnet, unerwartete Folgen haben könnte. Wie sich die Dinge seitdem verändert haben, vor allem dank der Zugänglichkeit und Akzeptanz von ChatGPT! In diesem Jahr ergab eine Gartner-Umfrage unter Top-Führungskräften im Mai, dass 89 % der Unternehmen generative KI untersuchen oder implementieren, während ein separater Gartner-Bericht aus demselben Zeitraum vorhersagt, dass bis 2025 mehr als 80 % des Codes in der Produktentwicklung durch KI generiert werden.

Entwickler/innen haben von der generativen KI stark profitiert, indem sie KI-Coding-Assistenten wie GitHub Copilot, Amazon CodeWhisperer und ChatGPT von OpenAI eingesetzt haben, um ihre Produktivität zu steigern. Doch so leistungsfähig und lebensverändernd diese KI-Tools auch sein mögen, sie sind immer noch anfällig für Fehler und Halluzinationen und sollten nur zur Ergänzung, nicht zum Ersatz von Entwickler/innen eingesetzt werden. Daher sollten eine sorgfältige menschliche Validierung von KI-generiertem Code, Sicherheitstools und Sicherheitsleitplanken sowie andere Maßnahmen zur sicheren Verwendung von generativen KI-Programmierungstools implementiert werden, damit Sie furchtlos innovieren können. Im Folgenden werfen wir einen Blick darauf, wie Sie KI-Code-Vervollständigungstools (wie Copilot) sicher einsetzen können, indem Sie diese 5 Best Practices anwenden.

Best Practice 1: Lassen Sie immer einen Menschen zu Wort kommen

Ein klassischer Fehler bei der Einführung generativer Code-Generierungstools ist das Fehlen (oder die Unzulänglichkeit) menschlicher Checks und Validierung. Wie bereits erwähnt, sind diese Tools nur zur Unterstützung von Entwickler/innen gedacht und nicht unfehlbar. Daher sollten Entwickler/innen die gleichen sicheren Gewohnheiten wie vor der Einführung von KI-Coding-Tools anwenden und ihren Code, ob KI-generiert oder nicht, weiterhin sorgfältig überprüfen.

Stellen Sie sich KI wie einen unerfahrenen Entwickler vor, der zufällig in der Lage ist, Tausende von Stack Overflow-Threads auf einmal zu lesen. Sie würden den Code eines neuen Entwicklers niemals ungeprüft weitergeben. Lassen Sie sich also nicht von der Geschwindigkeit der KI täuschen, sodass Sie denken, sie sei schlauer als sie ist.

Teams sollten über die Risiken von KI-generiertem Code aufgeklärt werden, ebenso wie über die Vorteile, und regelmäßige Code-Reviews sollten Teil der internen Softwareentwicklungspraktiken sein. Validieren, testen und korrigieren Sie in der IDE. Diese Gewohnheiten sollten in den Unternehmensrichtlinien und -verfahren verankert werden, und es sollten regelmäßige Schulungen durchgeführt werden, um sicherzustellen, dass die Teams die Bedeutung dieser Praktiken verstehen und die erforderlichen Code-Reviews angemessen umsetzen.

Best Practice 2: Scannen Sie KI-Code aus der IDE mit einem separaten, neutralen Sicherheitstool

Diese beiden Dinge gehen Hand in Hand. Erstens sollten Sie den Schub, den KI den Entwickler/innen gibt, nicht durch eine herkömmliche Sicherheitsüberprüfung aufhalten, um ihn voll auszuschöpfen. Die Entwickler/innen sind bereits in der Überzahl, was dazu geführt hat, dass Teams Linksverschiebungs-Sicherheitspraktiken einführen mussten. Jetzt, da die KI die Leistung der Entwickler/innen steigert, ist auch die Menge an verwundbarem Code gestiegen, sodass die Linksverschiebung keine Wahl ist – sie ist eine Notwendigkeit. Am einfachsten lässt sich dies erreichen, indem Sicherheitsscans direkt in die IDE integriert werden, sodass der Code in der Sekunde gescannt wird, in der er geschrieben wird. Auf diese Weise werden Schwachstellen proaktiv erfasst, anstatt sie reaktiv aufzuspüren, nachdem sie sich in der Entwicklungspipeline ausgebreitet haben.

Zweitens sollte das Scannen von einem Sicherheitstool durchgeführt werden, das nicht dasselbe Tool ist, mit dem der Code geschrieben wird. Das ist der gleiche Grund, warum Sie getrennte Entwicklerteams und Sicherheitsteams haben. Wenn Sie zulassen, dass das Team, das den Code schreibt, auch den Code sichert, werden Sie viele Schwachstellen haben. Sicherheit ist komplex und eine andere Disziplin als die Entwicklung. 

Die KI, die das Tool antreibt, das den Code schreibt, wurde auf funktionalen Code hin trainiert, um funktionalen Code zu schreiben. Ein speziell entwickeltes Sicherheitstool hingegen, das nur eines kann – Code sichern –, wurde nur auf sicherheitsrelevante Daten trainiert, um Sicherheitsprobleme zuverlässig zu erkennen und zu beheben. Darüber hinaus müssen Sicherheitstools in der Lage sein, den gesamten Kontext Ihrer Anwendung zu verstehen, nicht nur den aktuellen Code-Snippet, der gerade gescannt wird, damit Security-Fixes nicht zu Fehlern an anderer Stelle führen. Deshalb verwendet Snyk Code regelbasierte symbolische KI, um die von unserem LLM zur Verfügung gestellten Fixes zu scannen und den Anwendern dann nur Fixes anzubieten, die keine zusätzlichen Probleme verursachen. 

Mit KI brauchen Sie zwei verschiedene Tools (eines zum Schreiben, eines zum Sichern), genauso wie Sie zwei verschiedene Teams haben (Entwicklung und Sicherheit). Und beide Tools sollten den gesamten Kontext Ihrer Anwendung verstehen, damit Sie nicht mit Code-Snippets enden, die nur in einem Vakuum Sinn ergeben.

Best Practice 3: Validieren Sie den Code Dritter

Im Durchschnitt sind 70 % des Codes in einer Anwendung Open Source Code. Das bedeutet, dass 70 % Ihrer Anwendung von jemandem geschrieben und gesichert wurde, der nicht zu Ihrem Unternehmen gehört und der nicht haftbar gemacht werden kann, wenn eine Schwachstelle zu einem Einbruch für böswillige Akteure auf der Suche nach Kundendaten führt.

Wenn Entwickler/innen Abhängigkeiten von Drittanbietern verwenden, sollten sie diese immer mit einem Software Composition Analysis (SCA)-Tool scannen, um festzustellen, ob sie sicher sind. SCA-Tools finden verwundbare Pakete, melden die Art der Schwachstelle (Typ, Schweregrad usw.) und schlagen Abhilfemaßnahmen vor.

KI-geschriebener Code zieht auch Abhängigkeiten von Dritten mit ein. Sie erinnern sich? KI ist nur ein weiterer Entwickler. Einer, der zufällig unglaublich schnell Code schreiben kann. Die Abhängigkeiten dieses Codes müssen ebenfalls gescannt werden. Vor allem, wenn Sie bedenken, dass ein LLM-basiertes KI-Tool immer ein wenig hinter den neuesten Erkenntnissen und Veröffentlichungen von Drittanbieterpaketen hinterherhinkt. KI braucht SCA. Vor diesem Hintergrund empfehlen wir Ihnen, die von KI empfohlenen Open-Source-Bibliotheken immer manuell zu überprüfen und Tools wie Snyk Open Source zu verwenden, um diese Bibliotheken manuell zu testen.

Best Practice 4: Automatisieren Sie das Testen über Teams und Projekte hinweg

Wenn es nicht automatisiert ist, besteht eine gute Chance, dass es nicht passiert. Die Automatisierung ist eine so grundlegende Best Practice, das sie fast überall zu finden ist. Von Unix-Administratoren, die Cron-Jobs schreiben, über QA-Teams, die automatisierte Tests implementieren, bis hin zu DevOps-Teams, die eine ausufernde Infrastruktur entwickeln, die mit Python-Skripten zusammengehalten wird. Automatisierung macht das Leben nicht nur einfacher, sie macht es auch unmöglich, etwas zu vergessen.

Achten Sie darauf, Sicherheitstools zu implementieren, die ihre Anwendungen automatisch von CI/CD, und in den Arbeitsabläufen, die Teams bereits verwenden, absichern.

Best Practice 5: Schützen Sie Ihr geistiges Eigentum

Wenn Sie Richtlinien für die Nutzung von KI-Tools einführen, ist es äußerst wichtig, dass Sie den Tools nicht erlauben, von Ihrem proprietären Code zu lernen. Im Jahr 2023 hat Samsung die Verwendung von ChatGPT verboten, nachdem seine proprietären Daten während des nutzungsbasierten Trainings durchgesickert waren. Das Letzte, was Sie wollen, ist, dass Ihr Wettbewerbsvorteil als Codevorschlag an Entwickler/innen weitergegeben wird, die für ein anderes Unternehmen in Ihrem Bereich arbeiten. 

Daher ist es äußerst wichtig, dass Ihre KI-Nutzungsrichtlinien gut dokumentiert sind und Ihre Teams gut geschult sind (mit erlaubter Nutzung, obligatorischen Praktiken und möglichen Konsequenzen). Gehen Sie außerdem davon aus, dass alle Daten, die Sie in ein LLM eingeben, auch für dessen Training verwendet werden. Geben Sie dem LLM nur das Minimum an Informationen (nichts davon vertraulich), das es für seine Arbeit benötigt, und erwägen Sie die Implementierung von Input und Output Checks, um die Eingaben von Benutzern und die Ausgaben Ihrer LLMs zu bereinigen.

Verwenden Sie KI-Coding-Assistenten sicher

Lassen Sie sich nicht täuschen: KI-Coding-Assistenten gehört die Zukunft. Ihre Teams werden schneller als je zuvor arbeiten und mehr Code als je zuvor generieren, und es liegt an Ihnen, dafür zu sorgen, dass die Anwendungen, die sie ausliefern, sicher sind. Sie brauchen die richtigen Richtlinien, Sie brauchen die richtigen Schulungen und vor allem brauchen Sie die richtigen Sicherheitstools, damit Ihre Teams schnell arbeiten können. Genau hier kann Snyk helfen.

Die Sicherheitsplattform für Entwickler/innen von Snyk basiert auf branchenführender Intelligenz und hybrider KI. Sie scannt den Code, während er geschrieben wird (von Menschen oder KI), und liefert Empfehlungen für Fixes mit einem Klick direkt in der IDE, sodass Entwickler/innen nicht langsamer werden und Sicherheitsteams sich nicht behindern. 

Vertrauen Sie Ihrem KI-generierten Code mit Snyk. Buchen Sie noch heute eine Experten-Demo, um zu sehen, wie Snyk der Sicherheits-Copilot sein kann, den Copilot braucht.