GitHub Copilot in den Arbeitsalltag einführen – lieber nicht, oder?
Oftmals wiederholt obwohl vermeidbar: Die 4 häufigsten Fehler bei der Risikobewertung neuer Technologien am Beispiel von GitHub Copilot
Vor dem Einsatz von Neuem – Egal ob Technologie, Prozess oder anderem – wird gern zuerst auf die Risiken geschaut – Was kann im schlimmsten Fall passieren? Sollen wir nicht lieber beim Bewährten bleiben?
Eine saubere Risikobetrachtung ist gerade bei fundamentalen Neuerungen notwendig und sinnvoll. Allerdings wird hier oft zu kurz gedacht, also oberflächlich und nicht systematisch. Man hat manchmal den Eindruck, das Ziel sei eher die Bestätigung der vorgefassten Meinung und nicht die neutrale Analyse.
In diesem Blog-Post möchten wir häufige Fehler bei der Risikobewertung am Beispiel von GitHub Copilot aufzeigen – einem neuen Service von GitHub, der als „AI Pair Programmer“ beworben wird und Vorschläge für Programmcode aus dem Kontext oder Kommentaren generieren kann.
Wie funktioniert GitHub Copilot?
Das Fundament von GitHub Copilot ist ein großes Machine-Learning-Modell, genauer gesagt ein Large Language Model (LLM), wie es auch ChatGPT zugrunde liegt. Trainiert wurde dieses Modell mit „Milliarden Zeilen frei verfügbaren Quellcodes“, der zum Großteil aus auf GitHub gehosteten Repositorien stammt. Mit diesem Modell ist Copilot in der Lage, aus dem Kontext der aktuellen Programmierung (d.h. Code und Kommentare um den Prompt herum) Vorschläge zu generieren. Copilot kann in verbreitete Entwicklungs-umgebungen integriert werden. Die Vorschläge werden dann als Type-Ahead angezeigt und können einfach übernommen werden. Das Übertragen des aktuellen Kontexts an GitHub und das Generieren der Vorschläge passieren kontinuierlich.
Alternativen zu Copilot existieren, z.B. Amazon CodeWhisperer oder Tabnine. Die hier diskutierten Risiken und mögliche strukturelle Fehler in der Bewertung gelten für alle Tools, obwohl die tatsächliche Bewertung natürlich je nach Tool anders ausfallen kann.
In der Community wird die Steigerung in der Effizienz durch Copilot z.T. enthusiastisch gefeiert. Neutrale Studien zu dem Thema sind noch nicht durchgeführt worden. Eine von GitHub durchgeführte quantitative Analyse fällt – erwartungsgemäß – sehr positiv aus.
Uns als consilica hilft Copilot auch, schneller Software zu entwickeln. Schon die Vorschläge der noch auf GPT-3.5 Version bilden unserer Erfahrung immer eine brauchbare Basis, die sofort zur Verfügung steht. Das Verstehen und ggf. Verbessern dieses Codes geht einfach schneller, als von Grund auf Funktionen neu zu schreiben. Manchmal werden bisher unbekannte Idiome vorgeschlagen, das Wissen um die Programmiersprache wird also tatsächlich erweitert. Zur Abwechslung trainiert eine KI hier mal den Menschen, nicht andersherum.
Nicht mehr ganz ungewöhnlich: Mensch und Maschine programmieren gemeinsam eine Software.
Was ist nun mit den Risiken?
Häufig werden folgende Risiken genannt (siehe z.B. den englischen Wikipedia-Artikel zu Copilot) :
- Copyright-Verletzungen: Copilot wird aus öffentlich verfügbaren Code-Repositorien (Public Repos) trainiert. Dieser Code steht in der Regel unter einer bestimmten Softwarelizenz (z.B. MIT, GPL, etc.), die regelt, unter welchen Umständen der Code weiter verwendet werden darf. Diese Lizenz wird beim Trainieren ignoriert. Falls man jetzt Code übernimmt, der einem bestimmten Quell-Repository sehr ähnlich ist, so könnte es sich um einen Lizenzverstoß handeln. Die Rechtslage ist hier tatsächlich ungeklärt. (Ein klärendes Verfahren dazu wird in den USA gerade vorbereitet).
- Sicherheitsprobleme: Der generierte Code von Copilot wird vom Tool selbst nicht weiter geprüft und kann Sicherheitslücken oder andere Fehler enthalten. Wird der Vorschlag ohne weitere Maßnahmen in Produktion überführt, kann es also das Risiko von erfolgreichen Cyberangriffen erhöhen. Es gibt auch Bedenken, dass Trainingsmaterial gezielt manipuliert werden kann, um damit die Häufigkeit bestimmter Sicherheitslücken zu erhöhen.
- Datenschutz: Der Kontext der Programmierung wird kontinuierlich zu GitHub übertragen. Ist dies mit den aktuellen Datenschutzbestimmungen vereinbar?
Alle Risiken sind erst einmal grundsätzlich valide. Wir wollen nun allerdings schauen, welche Fehler oft bei ihrer Bewertung gemacht werden.
1. Fehler: Ignorieren der aktuellen Situation
Hierbei wird nicht in Betracht gezogen, dass neue Technologien oder Prozesse in der Regel etwas Bestehendes ergänzen. Man muss also bewerten, wie sich ein Risiko verändert – Und das kann sowohl vergrößern als auch verkleinern.
Im konkreten Fall ist es ja auch nicht so, dass Programmierer ohne fremde Hilfe oder Inspiration arbeiten. Bei Blockaden oder auch kurzen Verzögerungen im Programmierfluss („Wie formatiere ich nochmal diesen Datentyp solide um?“) wird z.B. oft eine Quelle aus dem Internet wie Stack Overflow befragt. Hier können Programmierfragen gestellt, die von der Community dann beantwortet und bewertet werden. Meistens wurde die akute Frage schon auf Stack Overflow gestellt, sodass man sich nur die am besten bewertete Antwort durchlesen muss.
Genau betrachtet ist das Risiko bei der Nutzung von Stack Overflow in Bezug auf Copyright-Verletzungen ganz ähnlich wie bei Github Copilot – Man bekommt passende Vorschläge für sein Problem geliefert, aber weiß nicht, woher es kommt und unter welcher Lizenz es ursprünglich erstellt wurde. Wenn ich also Stack Overflow durch Copilot ersetze bzw. ergänze, erhöht sich mein Risiko wirklich?
Fairerweise wird Code auf Stack-Overflow mit offensichtlichen Sicherheitslücken i.d.R. nicht als gut bewertet (down-vote), tauchen daher weiter unten in der Liste der Vorschläge auf und werden sicherlich seltener verwendet. Das bringt uns zu Punkt 2.
Mitgehangen, mitgefangen? Was passiert mit meiner mit Copilot erstellten Software, wenn das Verfahren gegen Github Erfolg hat?
2. Fehler: Keine Abstrahierung des Problems
Worum geht es denn im Kern bei Risiko 1 und 2? Kein Programmierer auf der Welt schreibt seinen Code im stillen Kämmerlein. Jeder greift auf externe Quellen zu, und das ist auch gut so. Sonst würde kein Stück fertige Software in endlicher Zeit entstehen.
Also heißt die Frage: Wie gehe ich (als Unternehmen) damit um, dass fremde Quellen genutzt werden, um Software zu entwickeln. Es ist empfehlenswert, sich grundsätzlich mit der Thematik zu beschäftigen – Nur dann kann man vernünftig das Risiko einer neuen Technologie bewerten.
Es müssen also konkrete Maßnahmen ergriffen werden. Zum Glück sind dies ausnahmslos allgemein bekannte Best Practices:
Ernsthafte Code-Reviews, nicht erklärbarer Code darf nicht eingecheckt werden Bei sehr spezifischem Code (z.B. Algorithmen) sollte im Code-Review besprochen werden, woher der Code kommt – i.d.R. ist das Einbetten einer externen Bibliothek sowieso besser als das eigene Implementieren. Automatische Tools, die den eingecheckten Code auf potenzielle Sicherheitslücken überprüfen (SAST, DAST)
3. Fehler: Unkenntnis über die wahrscheinliche Auswirkung bei Eintritt des Risikos
Bei möglichen Copyright-Verletzungen heißt es oft „Dann müssen wir ja unseren ganzen Code Open-Source machen!“ , gern auch gepaart mit „Und dann ist unsere IP dahin!“ oder „Und dann sind wir im Eimer!“.
Das ist aus verschiedenen Gründen schlicht nicht zutreffend, bzw. extrem unwahrscheinlich.
Zum einen verlangen die meisten Open-Source-Lizenzen nur eine Würdigung/Benennung des genutzten Codes. Die bekannte (aber an Verbreitung abnehmende) GPL hingegen verlangt tatsächlich die Offenlegung des Codes bei Copyright-Verletzung, also Nutzung von unter GPL-stehenden Code in der eigenen Software.
In den in Deutschland tatsächlich verhandelten Verfahren wurde allerdings unserer Kenntnis nach nie ein Beklagter zur Offenlegung der Software verurteilt (siehe z.B. hier). Stattdessen musste der GPL-Code entfernt, ggf. auch eine Strafe gezahlt werden. Das erzeugt natürlich Kosten, was aber etwas ganz anderes ist als Offenlegung von kritischer IP.
4. Fehler: Keine Zusammenarbeit mit den Expertengremien
Zum Thema Datenschutz: Hier gibt es in jedem Unternehmen schon Experten, die hinzugezogen werden können oder sogar müssen. Ab 20 Mitarbeitern muss ein Datenschutzbeauftragter (DSB) beauftragt sein, und das Teilen von personenbezogenen Daten kann auch ein Thema für den Betriebsrat sein.
Unsere Empfehlung ist hier frühzeitig in die Kommunikation zu gehen, das Expertenwissen zu nutzen und das Risiko gemeinsam zu bewerten. Leider erleben wir auch das Gegenteil – So wird das Einbeziehen als lästig oder sinnfrei empfunden, nach dem Motto „Das bringt ja eh nix“. Letztlich ist das Wissen und Erfahrung dieser Gremien aber sehr hilfreich, und gerade der Datenschutzaspekt wird individuell sehr unterschiedlich gewichtet – Für den einen hat es absolute Priorität, für den anderen überhaupt nicht. Insofern ist es auch hier wichtig zu objektivieren, also mit den Experten zusammen den Rahmen zu klären (was ist überhaupt erlaubt) und das Risiko zu bewerten.
Fazit
Risikobewertung sollte immer möglichst neutral vorgenommen werden. Hier die Zusammenfassung, wie das besser gelingen kann:
Den aktuellen Prozess und die aktuellen Risiken dokumentieren. Dann die Änderung darstellen. Den Prozess abstrahieren und evaluieren, welche Maßnahmen zur Linderung der Risiken schon getroffen wurden bzw. angebracht sind. Die Auswirkung bei Eintritt der Risikos möglichst genau verstehen Frühzeitig Expertengremien mit ins Boot holen. Gern helfen wir Ihnen bei der konkreten, auf Sie zugeschnittenen Risikobewertung zu GitHub Copilot und anderen Technologien und Prozessen. Sprechen Sie mit uns!
