ChatGPT, Gemini, Claude und Microsoft Copilot beim Programmieren: Welche Sicherheitsrisiken birgt generierter Code?
Allgemeine Chatbots sind oft das erste Werkzeug, das beim Programmieren mit KI verwendet wird: Man fügt eine Fehlermeldung ein, bittet um einen Code-Schnipsel, lässt eine Funktion generieren oder beschreibt eine Architektur. Das Risiko entsteht gerade durch die Leichtigkeit des Kopierens und Einfügens: Das Modell kennt weder den vollständigen Anwendungskontext noch reale Daten, Unternehmensrichtlinien oder Produktionsvorgaben. Das Ergebnis mag korrekt erscheinen, ignoriert jedoch möglicherweise Berechtigungen, Bereinigungen (Sanitization), Fehlerbehandlung oder Bedrohungsmodelle.
Das Ziel dieses Artikels ist nicht zu beurteilen, ob KI für die Entwicklung nützlich oder gefährlich ist, sondern eine praktischere Frage zu beantworten: Welche Kontrollen sind erforderlich, wenn ein durch KI generiertes oder beschleunigtes Ergebnis in ein Produkt, einen Unternehmens-Workflow oder eine Umgebung mit echten Daten einfließt? Der Text richtet sich an Gründer, CTOs, Entwickler sowie IT- und Sicherheitsteams, die Chatbots für Prompts, Code-Schnipsel, Debugging und architektonische Planung nutzen.
Warum eine funktionierende App nicht zwangsläufig sicher ist
KI-Tools verkürzen die Zeit, die für die Erstellung von Code, Schnittstellen, Workflows, Tests und Konfigurationen benötigt wird. Diese Geschwindigkeit kann jedoch Schritte verkürzen, die Software normalerweise zuverlässig machen: Bedrohungsmodellierung (Threat Modeling), Reviews, Geheimnisverwaltung (Secret Management), Rollenkontrollen, Eingabevalidierung, Überprüfung von Abhängigkeiten und manuelle Tests kritischer Pfade.
Eine Demo funktioniert mit einem einzigen Benutzer, fiktiven Daten und impliziten Berechtigungen. Dieselbe Logik kann versagen, wenn echte Kunden, mehrere Mandanten (Multi-Tenancy), verschiedene Rollen, öffentliche APIs, Integrationen, personenbezogene Daten, Zahlungen oder Automatisierungen mit externen Auswirkungen hinzukommen. Deshalb muss die Sicherheit am tatsächlichen Verhalten der App bewertet werden und nicht am Versprechen des Tools, das sie generiert hat.
Das Problem ist nicht der Schnipsel, sondern der fehlende Kontext
Ein Code-Schnipsel kann korrekt aussehen und dennoch Berechtigungen, Bereinigung, Logging, Fehlerbehandlung, Nebenläufigkeit, Mandantentrennung, Geheimnisse oder Bedrohungsmodelle ignorieren. Der Chatbot antwortet auf die erhaltene Frage: Er überprüft nicht automatisch das System, in das der Code eingefügt wird, und kennt weder die Produktionsvorgaben noch die Sicherheitsrichtlinien der Organisation. Das macht den generierten Code nicht unbrauchbar, erfordert aber eine systematische Überprüfung, bevor er in die Produktion gelangt.
Daten und Code in Prompts
Bevor Sie Code, Protokolle oder Payloads in einen Chatbot einfügen, müssen Sie prüfen, ob diese Geheimnisse, personenbezogene Daten, Kundennamen, interne Konfigurationen oder Infrastrukturdetails enthalten. Enterprise-Konten, Datenkontrollen und interne Richtlinien verringern das Risiko, ersetzen aber nicht die Schwärzung (Redaction) und operative Regeln. Die Faustregel ist einfach: Wenn es nicht veröffentlicht werden darf, wird es nicht eingefügt.
Wie man von Chatbots generierten Code akzeptiert
Jeder Schnipsel, der Authentifizierung, Abfragen, APIs, Dateien, Shell-Befehle, Kryptografie, Zahlungen, Webhooks oder Berechtigungen betrifft, muss einen normalen Entwicklungsprozess durchlaufen: Review durch eine kompetente Person, negative Tests, Linting und Security-Scans, Secret-Scanning sowie manuelle Überprüfung der Logik. Code ohne diesen Schritt zu akzeptieren, kommt dem Überspringen eines Reviews bei jeder anderen kritischen Änderung gleich.
Wichtigste zu prüfende Risiken
Die häufigsten Risiken bei von Chatbots generiertem Code betreffen spezifische Bereiche, die eine Überprüfung von Nachweisen, Konfiguration, Laufzeitverhalten und Auswirkungen auf reale Daten erfordern:
- Kopieren von Code ohne Anwendungskontext: Das Modell kennt keine Rollen, Mandanten, echten Daten oder Produktionsvorgaben.
- Prompts mit Geheimnissen, Logs oder personenbezogenen Daten: Sensible Informationen können offengelegt oder außerhalb des Unternehmensperimeters gespeichert werden.
- Unsichere Muster, die als Best Practices präsentiert werden: Vereinfachte Beispiele können grundlegende Sicherheitskontrollen auslassen.
- Fixes, die den Fehler beheben, aber die Sicherheit schwächen: Eine schnelle Korrektur kann Schwachstellen in angrenzenden Bereichen einführen.
- Vorgeschlagene Abhängigkeiten ohne Bewertung: Vom Chatbot vorgeschlagene Pakete können veraltet, anfällig oder nicht gewartet sein.
- Übermäßig vereinfachte Authentifizierungs- oder Kryptografiebeispiele: Schemata, die zur didaktischen Klarheit reduziert wurden, sind nicht für die Produktion geeignet.
- Tests, die nur den “Happy Path” abdecken: Negative Fälle, Rollenmissbrauch und anomales Verhalten bleiben unentdeckt.
Diese Risiken müssen mit dem konkreten Perimeter verknüpft werden: Eine exponierte App erfordert manuelle Anwendungstests, eine kritische Codeänderung erfordert ein Review, ein interner Workflow erfordert die Kontrolle von Berechtigungen und Zugangsdaten, eine agentische App erfordert Tests von Prompts, Tools und Ausgaben. Die richtige Kombination hängt von der Auswirkung ab, nicht vom Namen des Tools.
Mindestkontrollen vor dem Go-Live
- Benutzer, Rollen, echte Daten, Integrationen, Umgebungen und Service-Eigentümer zuordnen.
- Identifizieren, welche Teile mit KI generiert oder geändert wurden und wer diese überprüft hat.
- Serverseitige Berechtigungen, Mandantentrennung und administrative Funktionen verifizieren.
- Nach Geheimnissen in Code, Prompts, Logs, Umgebungsvariablen, Builds und Repository-Historie suchen.
- Abhängigkeiten, Lizenzen, Pakete, Vorlagen, Plugins und generierte Komponenten prüfen.
- Feindliche Eingaben, Fehlerbehandlung, Logging, Rate-Limiting und nicht vorgesehene Pfade testen.
- Blockierende Fixes, geplante Sanierungen und akzeptierte Restrisiken trennen.
- Tests oder Retests nach Korrekturen durchführen, die kritische Abläufe betreffen.
Wann eine unabhängige Überprüfung erforderlich ist
Eine unabhängige Überprüfung ist erforderlich, wenn die App oder der Workflow echte Daten, externe Benutzer, Rollen, APIs, Unternehmensintegrationen, Zahlungen, Speicher, automatisierte Workflows oder kritischen, mit KI generierten Code verarbeitet. Sie ist auch dann notwendig, wenn das Team nicht nachweisen kann, welche Teile überprüft wurden und welche Kontrollen Regressionen oder Missbrauch verhindern.
Für diese Art von Kontext sind die relevantesten ISGroup-Dienste die Code Review und der Software Assurance Lifecycle. Das nützlichste Review ist nicht generisch: Es muss reproduzierbare Ergebnisse, Prioritäten für die Sanierung, Angaben zum Restrisiko und bei Bedarf Retests nach den Korrekturen liefern.
Operative Fragen für Gründer, CTOs und Sicherheitsteams
- Welche echten Daten gelangen in das System und wo werden sie gespeichert, protokolliert oder gesendet?
- Welche Rollen existieren und welche Aktionen sind serverseitig blockiert, nicht nur in der Benutzeroberfläche?
- Welche Geheimnisse, Token, Webhooks oder Zugangsdaten würden den Zugriff auf kritische Systeme ermöglichen?
- Welche Teile wurden von der KI generiert oder geändert und welche wurden von einer kompetenten Person überprüft?
- Welche Tests decken Missbrauch, Fehler, verschiedene Rollen und verschiedene Mandanten ab, nicht nur den “Happy Path”?
- Welche Nachweise können Kunden, Audits, dem Einkauf oder der Geschäftsführung vorgelegt werden?
Nützliche weiterführende Informationen
- ChatGPT und sicherer Code in der Produktion: Vertiefung dazu, wie man von Chatbots generierten Code unter Reduzierung operativer Risiken in die Produktion bringt.
- Sichere Code-Review für KI-Code: Leitfaden zur Sicherheitsüberprüfung speziell für Code, der mit KI-Tools generiert oder geändert wurde.
- Richtlinien und KI-Coding-Risiken: Wie man interne operative Regeln für den sicheren Einsatz von KI-Tools in der Entwicklung definiert.
FAQ
- Ist es sicher, ChatGPT oder andere Chatbots zum Programmieren zu verwenden?
- Es kann sicher sein, wenn der Code als Vorschlag behandelt wird, der überprüft werden muss, und nicht als maßgebliche Ausgabe. Das Risiko steigt, wenn sensible Daten eingefügt werden oder Fixes in kritischen Bereichen ohne Review akzeptiert werden.
- Darf ich Unternehmenscode in den Prompt einfügen?
- Nur wenn die Unternehmensrichtlinie und der Vertrag des Tools dies zulassen und nachdem Geheimnisse, personenbezogene Daten und unnötige Details entfernt wurden.
- Welche Schnipsel erfordern ein obligatorisches Review?
- Authentifizierung, Berechtigungen, Abfragen, Datei-Uploads, Shell-Befehle, Zahlungen, Webhooks, Kryptografie, Logging, Geheimnisverwaltung, Pipelines und Berechtigungen.
- Reichen die vom Chatbot generierten Tests aus?
- Nein. Sie sind als Basis nützlich, müssen aber durch negative Fälle, Rollenmissbrauch und Tests des tatsächlichen Anwendungsverhaltens ergänzt werden.
- Wann sollte man eine externe Code-Review hinzuziehen?
- Wenn relevante Teile des Codes von einem Chatbot akzeptiert wurden und die App echte Daten, APIs, Benutzer, Rollen oder Integrationen verarbeitet.
[Callforaction-SAL-Footer]
Leave a Reply