Sichere Softwareentwicklung mit KI: So bleibt KI-generierter Code prüfbar

Die kurze Antwort

KI-generierter Code ist nicht grundsätzlich unsicherer als handgeschriebener. Er entsteht aber schneller, in größerer Menge und mit weniger menschlicher Aufmerksamkeit pro Zeile. Sichere Softwareentwicklung mit KI bedeutet daher, den Entwicklungsprozess so aufzusetzen, dass jede Änderung unabhängig von ihrer Herkunft dieselben Prüfungen durchläuft: verpflichtendes Review, automatisierte Tests und Security-Scans, kontrollierte Abhängigkeiten, sauberes Secrets-Management und eine Person, die das Ergebnis verantwortet. Teams mit diesem Prozess können KI-Werkzeuge gefahrlos nutzen. Teams ohne diesen Prozess hatten das Problem schon vorher, mit KI wird es nur schneller sichtbar.

Was sich durch KI am Sicherheitsrisiko ändert

Die klassischen Schwachstellen sind dieselben geblieben: fehlende Eingabeprüfung, unsichere Authentifizierung, falsch gesetzte Berechtigungen, veraltete Bibliotheken. Was sich ändert, ist die Dynamik.

• Volumen. Ein Team erzeugt mit KI-Unterstützung deutlich mehr Code in derselben Zeit. Die Review-Kapazität wächst nicht automatisch mit.
• Plausibilität statt Korrektheit. KI-generierter Code sieht fast immer richtig aus. Das senkt die Aufmerksamkeit im Review, obwohl sie gerade hier nötig wäre.
• Veraltete Muster. Modelle lernen aus bestehendem Code, auch aus Beispielen mit bekannten Schwächen oder abgelösten Verfahren.
• Erfundene Abhängigkeiten. KI-Werkzeuge schlagen gelegentlich Pakete vor, die nicht existieren oder nicht gepflegt sind. Wer sie ungeprüft installiert, öffnet eine Tür in die Lieferkette.
• Neue Angriffsfläche. Sobald die Software selbst KI-Funktionen enthält, kommen Themen wie Prompt Injection und unkontrollierter Datenabfluss dazu.
• Tempo als Versuchung. Wenn ein Feature in einer Stunde entsteht, wirkt ein Tag Review unverhältnismäßig. Die Folgekosten einer übersehenen Schwachstelle stehen aber in keinem Verhältnis zu dieser Stunde.

Secure SDLC: Der Prozess trägt die Sicherheit

Ein Secure Software Development Life Cycle verteilt Sicherheitsarbeit über alle Phasen, statt sie am Ende in einen Penetrationstest zu packen. Mit KI im Team ändert sich an den Phasen nichts, an der Ausgestaltung einiges:

• Anforderungen. Bleibt: Schutzbedarf und Bedrohungsmodell festlegen. Neu: klären, welche Daten in KI-Werkzeuge fließen dürfen.
• Design. Bleibt: Zugriffskonzept, Datenflüsse, Schnittstellen. Neu: Architekturentscheidungen nicht an die KI delegieren.
• Implementierung. Bleibt: Secure Coding, Vier-Augen-Prinzip. Neu: Review-Pflicht für jede Änderung, KI-Anteile kenntlich machen.
• Test. Bleibt: Unit-, Integrations- und Sicherheitstests. Neu: Tests prüfen gegen die Spezifikation, nicht gegen den generierten Code.
• Release. Bleibt: Freigabe, Dokumentation, Abnahme. Neu: Pro Release ist eine verantwortliche Person benannt.
• Betrieb. Bleibt: Monitoring, Patching, Incident-Handling. Neu: Abhängigkeiten laufend auf Herkunft und Pflege prüfen.

Wer sich an etablierten Rahmenwerken orientiert, etwa an der BSI-Richtlinie zum sicheren Software-Lebenszyklus (TR-03185) oder an den Anforderungen aus ISO 27001 an die Entwicklung, findet dort bereits die Struktur. KI-Werkzeuge müssen in diese Struktur aufgenommen werden, als Werkzeug mit eigenen Regeln.

Code-Review für KI-generierten Code

Das Review ist die wichtigste einzelne Maßnahme. Für KI-generierten Code gelten dieselben Regeln wie für jeden anderen, mit vier Ergänzungen:

1. Keine Ausnahme für KI. Jede Änderung wird von einer zweiten Person gelesen, bevor sie in den Hauptzweig gelangt. Dass ein Werkzeug den Code erzeugt hat, ist kein Grund, das Review zu verkürzen.
2. Fokus auf die kritischen Stellen. Authentifizierung, Autorisierung, Eingabeverarbeitung, Datenzugriff, Fehlerbehandlung und alles, was mit Zugangsdaten zu tun hat, werden mit besonderer Aufmerksamkeit gelesen.
3. Kleine Einheiten. KI verführt zu großen Änderungen auf einmal. Große Pull Requests werden schlecht reviewt. Kleine Schritte halten die Prüfung realistisch.
4. KI-Review als Ergänzung. Ein KI-gestütztes Review findet Muster, die Menschen übersehen. Es ersetzt die menschliche Prüfung nicht, weil es dieselben blinden Flecken haben kann wie das Werkzeug, das den Code geschrieben hat.

Hilfreich ist, KI-generierte Anteile im Commit oder Pull Request zu kennzeichnen, damit Reviewer:innen wissen, wo genaues Lesen besonders lohnt.

Tests und Security-Scans automatisieren

Was automatisiert prüfbar ist, gehört in die Pipeline. Das gilt mit KI mehr denn je, weil die Menge an Änderungen manuelle Prüfung allein überfordert:

• Tests. Unit- und Integrationstests laufen bei jeder Änderung. KI kann Tests schreiben, aber die Tests müssen die Spezifikation prüfen, nicht das Verhalten des gerade generierten Codes bestätigen. Diesen Unterschied muss ein Mensch sicherstellen. Ein Beispiel: Ein KI-Assistent ergänzt einen Login-Endpunkt und liefert gleich einen Testfall mit, der grün ist. Der Test prüft aber nur, dass der Endpunkt antwortet, und nicht, dass ein gesperrtes Konto abgewiesen wird. Das fällt nur auf, wenn jemand den Test gegen die Anforderung liest.
• Statische Analyse (SAST). Findet typische Schwachstellen im Code, bevor er läuft.
• Abhängigkeitsprüfung. Bekannte Schwachstellen in Bibliotheken werden automatisch gemeldet.
• Secret Scanning. Zugangsdaten, die versehentlich im Code landen, werden erkannt, bevor sie ins Repository gelangen.
• Dynamische Tests (DAST). Die laufende Anwendung wird auf Schwachstellen geprüft, regelmäßig und vor jedem größeren Release.

Der etablierte Begriff dafür ist DevSecOps: Sicherheit läuft in der Pipeline mit, statt als Prüfschritt am Ende zu warten. Für KI-gestützte Entwicklung ist das die Voraussetzung, um mit dem Tempo mitzuhalten.

Abhängigkeiten und Lizenzen kontrollieren

KI-Werkzeuge schlagen Bibliotheken vor, weil sie in den Trainingsdaten häufig vorkamen. Ob eine Bibliothek existiert, gepflegt wird, sicher ist und eine passende Lizenz hat, prüfen sie nicht zuverlässig. Deshalb:

• Jede neue Abhängigkeit wird vor der Aufnahme bewusst geprüft: Herkunft, Pflegezustand, bekannte Schwachstellen, Lizenz.
• Versionen werden festgeschrieben (Lockfiles), damit Builds reproduzierbar bleiben.
• Eine Stückliste der eingesetzten Komponenten (SBOM) macht sichtbar, was in der Software steckt, und erleichtert Reaktion bei neuen Schwachstellen.
• Lizenzprüfung ist Teil des Prozesses, nicht ein Thema für den Jahresabschluss. Eine ungeeignete Lizenz in einer kommerziellen App ist ein rechtliches Problem, kein technisches.

Secrets und Daten: Was nie in den Prompt gehört

Zwei Datenflüsse brauchen klare Regeln, bevor KI-Werkzeuge im Team genutzt werden.

Secrets im Code. API-Schlüssel, Passwörter und Zertifikate gehören in einen Secret-Manager, nicht in Quellcode, Konfigurationsdateien oder Prompts. KI-Werkzeuge erzeugen gerne Beispielcode mit eingetragenen Schlüsseln. Secret Scanning in der Pipeline ist die technische Absicherung, die Regel im Team die organisatorische.

Daten in den Werkzeugen. KI-Coding-Werkzeuge lesen Code, Konfigurationen und oft ganze Repositories, um Kontext zu haben. Es muss geklärt sein, welche Werkzeuge erlaubt sind, in welchem Betriebsmodell sie laufen, ob Eingaben zum Training verwendet werden und ob Kundendaten oder produktive Datenbestände überhaupt in Reichweite der Werkzeuge liegen dürfen. Ohne diese Klärung ist jeder Prompt ein potenzieller Datenabfluss.

Verantwortung für das Ergebnis

Für Software ist immer ein Mensch verantwortlich, nie ein Werkzeug. Damit das im Alltag gilt, muss es im Prozess verankert sein:

• Eine Definition of Done, die Review, Tests, Scans und Dokumentation einschließt, gilt für jede Änderung.
• Pro Release ist benannt, wer die Freigabe verantwortet.
• Governance-Regeln legen fest, welche KI-Werkzeuge mit welchen Daten genutzt werden dürfen und wer Ausnahmen genehmigt.
• Bei Vergabe an einen Dienstleister sollte der Vertrag regeln, dass Gewährleistung und Haftung für das Gesamtergebnis gelten, ohne Sonderregeln für KI-generierte Anteile.

Wie Guardrails, Tooling und Verantwortlichkeiten für KI-gestützte Entwicklung organisatorisch aufgesetzt werden, beschreibt unser Artikel zum Vibe Coding Setup für Unternehmen. Dieser Beitrag hier konzentriert sich auf den Sicherheitsprozess selbst.

Fazit

Sichere Softwareentwicklung mit KI folgt denselben Regeln wie bisher, nur konsequenter angewendet: Secure SDLC, Review-Pflicht, automatisierte Tests und Scans, kontrollierte Abhängigkeiten, Secrets außerhalb des Codes und klare Verantwortung. KI-Werkzeuge erhöhen das Tempo und damit den Druck auf jeden dieser Punkte. Mit diesem Prozess wird das Tempo zum Gewinn. Ohne ihn entsteht nur schneller ungeprüfter Code. Wir entwickeln in Wien Software für Branchen, in denen Sicherheit nicht verhandelbar ist, und setzen KI genau so ein: mit Prozess. Wie wir Sicherheit im Unternehmen organisieren, beschreibt die Seite Sicherheit bei allaboutapps. Mehr zu unserer Arbeit mit KI-gestützter Entwicklung und Backend- und API-Entwicklung.

FAQ

Ist KI-generierter Code unsicherer als handgeschriebener?

Nicht grundsätzlich. Er hat dieselben typischen Schwachstellen, entsteht aber schneller und wirkt plausibler, was die Prüfung erschwert. Entscheidend ist, dass jede Änderung unabhängig von ihrer Herkunft denselben Review- und Testprozess durchläuft.

Reicht ein KI-gestütztes Code-Review aus?

Nein. KI-Review ist eine sinnvolle Ergänzung, weil es Muster zuverlässig findet. Die Freigabe durch eine zweite Person bleibt, weil Werkzeug und Reviewer-Werkzeug dieselben blinden Flecken haben können.

Was ist der wichtigste erste Schritt für sichere Softwareentwicklung mit KI?

Regeln für den Werkzeugeinsatz: Welche Werkzeuge sind erlaubt, welche Daten dürfen hinein, und gilt die Review-Pflicht ausnahmslos. Danach kommt die Automatisierung von Tests und Scans in der Pipeline.

Wer steht dafür ein, wenn KI-generierter Code eine Sicherheitslücke enthält?

Aus unserer Sicht das Team oder der Dienstleister, der den Code ausliefert: KI-Einsatz ist eine Arbeitsmethode und kein Grund für eine Sonderregel. In welchem Umfang Gewährleistung und Haftung greifen, legt der Vertrag fest. Deshalb gehört die Frage vor der Beauftragung auf den Tisch.