Softwarehaus und KI-Coding: Wie man Sicherheit bei KI-generiertem Code gewährleistet

Für eine Softwarehaus ist KI-Coding nicht nur ein Thema der internen Produktivität, sondern eine Frage der Zuverlässigkeit gegenüber dem Kunden. Wenn ein Team Agenten für die Codegenerierung, Refactoring, Tests, Pipelines oder Konfigurationen einsetzt, muss es nachweisen können, dass die Geschwindigkeit nicht zu Lasten von Reviews, Datentrennung, Sicherheitskontrollen und der Verantwortung für die Bereitstellung geht.

Die Frage, die von Kunden, Einkauf und Audit gestellt wird, ist konkret: Woher wissen Sie, dass der mit KI generierte oder geänderte Code vor der Auslieferung geprüft wurde? Eine glaubwürdige Antwort kann nicht lauten: „Wir vertrauen unseren Entwicklern“ oder „Die Scanner zeigen grün“. Es bedarf eines Assurance-Programms: interne Regeln, Nachweise, Reviews, Tests, Pipeline-Gates, Berichte und Remediation.

Warum das Risiko für eine Softwarehaus anders ist

Ein internes Team kann ein Risiko akzeptieren und es innerhalb seines eigenen Entwicklungszyklus steuern. Eine Softwarehaus hingegen liefert Code an Dritte aus: Kunden, Auditoren, Einkaufsabteilungen, Rechtsabteilungen und Sicherheitsteams können jederzeit Beweise verlangen.

Der Einsatz von KI-Coding wirft neue Fragen auf, die nicht nur die technische Qualität betreffen. Welche Teile wurden von Agenten generiert oder geändert? Welche Kundendaten wurden im Prompt oder Kontext verwendet? Welche Abhängigkeiten wurden eingeführt und wer hat das Diff geprüft? Welche Tests decken Autorisierungen, Rollen und Missbrauch ab? Welche Findings wurden vor der Auslieferung korrigiert und welche Restrisiken wurden kommuniziert? Wenn diese Antworten fehlen, verliert die Softwarehaus nicht nur die technische, sondern auch die kommerzielle Kontrolle.

Interne Richtlinie für den Einsatz von KI in Kundenprojekten

Die Richtlinie muss festlegen, was in Kundenprojekten zulässig ist, nicht nur, was für das Team bequem ist. Sie muss autorisierte Tools, Firmenkonten, verbotene Daten, zulässige Repositories, Agenten-Modi, Terminal-Zugriffe, Cloud-Agenten, externe Tools, Reviews und das Ausnahmemanagement abdecken. Die Mindestpunkte, die enthalten sein sollten:

Keine privaten Konten für Kundencode oder -daten.
Keine Geheimnisse, echten Logs oder Kundendaten in nicht autorisierten Prompts.
Getrennte Workspaces pro Kunde.
Ausschluss sensibler Dateien aus dem Kontext des Agenten.
Genehmigung für Tools, die Kunden-Repositories lesen.
Obligatorische Reviews für Auth, APIs, Daten, Pipelines und Abhängigkeiten.
Rückverfolgbarkeit von KI-generierten Teilen, wenn dies vertraglich relevant ist.

Die Richtlinie muss einfach anzuwenden sein: Wenn sie zu abstrakt ist, wird jedes Team sie anders interpretieren und die Kontrollen verlieren ihre Konsistenz über Projekte hinweg.

Trennung von Kundendaten

Das heikelste Risiko ist nicht immer der Bug im Code, sondern der unkontrollierte Informationsfluss zwischen Kunden, Tools und Umgebungen. Eine Softwarehaus muss Repositories und Branches, IDE-Workspaces und Agenten, Cloud-Umgebungen, Anmeldedaten, Testdatensätze, Logs und Tickets, Kundendokumentation sowie Prompts und Transkripte (sofern gespeichert) strikt trennen.

Ein Agent, der an mehreren Projekten arbeitet, darf keinen unnötigen übergreifenden Kontext haben. Ein Kundendatensatz darf nicht zu einer wiederverwendeten Fixture in anderen Projekten werden, und ein Produktionsfehler darf nicht in einen allgemeinen Chat mit Tokens, E-Mails oder nicht anonymisierten Identifikatoren kopiert werden.

Rückverfolgbarkeit: Vom Prompt bis zum Release

Es ist nicht notwendig, jeden Prompt wahllos zu speichern, aber es ist notwendig zu wissen, welche Entscheidungen zum Release geführt haben. Nützliche Nachweise, die aufbewahrt werden sollten, umfassen: Ausgangs-Issues oder -Tasks, PRs und Commits, von KI geänderte Dateien, Reviewer und Genehmigungen, ausgeführte Scanner und Tests, neue Abhängigkeiten, Änderungen an CI/CD, IaC und Deployments, Findings und Fixes sowie akzeptierte Restrisiken.

Diese Rückverfolgbarkeit ist auch intern nützlich: Wenn eine Schwachstelle auftritt, der Kunde Erklärungen verlangt oder eine Regression in einem späteren Release wieder auftaucht, verkürzt ein dokumentierter Pfad die Reaktionszeiten erheblich.

Obligatorische Reviews für sensible Bereiche

Nicht jeder KI-generierte Code hat das gleiche Risikoprofil. Eine Textänderung erfordert nicht das gleiche Kontrollniveau wie eine Änderung an Middleware, Rollen, Abfragen, APIs, Pipelines oder Zahlungsfunktionen. Eine Softwarehaus sollte die Bereiche definieren, die immer eine technische Review erfordern:

Authentifizierung, Sitzungen, Passwort-Reset, MFA, OAuth.
Autorisierungen, Rollen, Mandantentrennung (Tenant Isolation), Richtlinien und Middleware.
APIs, Abfragen, Exporte, Uploads, Zahlungen und Webhooks.
Geheimnisse, Logs, Fehlerbehandlung und Konfigurationen.
Abhängigkeiten, Lockfiles, Lizenzen, Dockerfiles.
CI/CD, IaC, Cloud, IAM und Deployments.
Runtime-Prompts, Anwendungsagenten, RAG und Tool-Calling.

Die Code Review wird so zum Kontrollnachweis: nicht nur „wir haben den Code gelesen“, sondern „wir haben diese Bereiche mit diesem Umfang und diesen Ergebnissen geprüft“.

Tests und Scanner: Notwendig, aber nicht ausreichend

SAST, SCA, Secret Scanning, Unit-Tests und Integrationstests sind notwendig, beweisen aber allein nicht, dass die Anwendung Geschäftslogik, Autorisierungen, Mandantentrennung und Missbrauchsschutz einhält. Für Kundenprojekte sollte die Pipeline mindestens Folgendes liefern:

SAST mit Triage neuer Findings.
SCA und Lizenz-Scanning für Manifeste und Lockfiles.
Secret Scanning in Repositories, Logs und Artefakten.
Negative Tests für Rollen, Mandanten, Eingaben und Fehlermodi.
Kontrollen für IaC, Container und Konfigurationen.
Nachweise über Fixes und Retests.

Wenn die App oder die APIs für Benutzer, Partner oder das Internet erreichbar sind, muss auch das Laufzeitverhalten überprüft werden. In diesem Kontext ergänzt das Web Application Penetration Testing die Code Review: Die eine analysiert die Ursache im Code, die andere prüft, ob das exponierte Verhalten am realen System ausnutzbar ist.

Abhängigkeiten, Lizenzen und Lieferkette

Agenten können Pakete hinzufügen, um eine Funktion schnell abzuschließen, aber für eine Softwarehaus ist eine Abhängigkeit nicht nur ein technisches Risiko: Sie kann zu einem Problem mit Lizenzen, Wartung, bekannten Schwachstellen, Kundenrichtlinien oder Audits werden. Jede neue Abhängigkeit sollte hinsichtlich Motivation, Version und Lockfile, kompatibler Lizenz, Wartungsstatus, bekannter Schwachstellen, Installationsskripten und dem Vorhandensein von Alternativen im Projekt bewertet werden.

Für Enterprise-Kunden können SBOM, Provenance und SCA-Berichte zu vertraglichen Nachweisen werden. Auch wenn sie nicht explizit gefordert werden, reduziert die Kenntnis darüber, was in das Release einfließt, die Reaktionszeiten im Falle einer CVE.

Berichterstattung an den Kunden: Was ist vorzuzeigen?

Der Kunde sollte keine allgemeine Erzählung über KI erhalten, sondern Nachweise, die dem Projekt angemessen sind. Ein nützlicher Bericht kann den Umfang des Releases oder der Review, die KI-generierten oder -geänderten Teile (sofern relevant), die mit Scannern und Tests durchgeführten Kontrollen, die korrigierten blockierenden Findings, die planbaren Findings, die Restrisiken, neue Abhängigkeiten, Grenzen des Umfangs und Empfehlungen für zukünftige Releases enthalten.

Das bedeutet nicht, jeden Prompt oder jedes interne Detail offenzulegen, sondern nachweisbar zu machen, dass der gelieferte Code nicht blind akzeptiert wurde.

Vom Einzelprojekt zum Assurance-Programm

Der echte Qualitätssprung erfolgt, wenn die Kontrollen nicht vom einzelnen Projektmanager abhängen. Jedes Projekt mit KI-Coding sollte ähnliche Schwellenwerte, ähnliche Berichte, ähnliche Gates und klare Verantwortlichkeiten haben. Der Software Assurance Lifecycle dient genau dazu: Reviews, Tests, Pipelines, Remediation und Reporting in einen Prozess zu verwandeln, der über verschiedene Teams und Kunden hinweg wiederholbar ist.

Für eine Softwarehaus hat dies einen direkten kommerziellen Wert: Es hilft, auf Einkaufsanfragen, Audits, Sicherheitsfragebögen und Nachweisanforderungen zu antworten, ohne den Prozess jedes Mal von Grund auf neu aufbauen zu müssen.

Checkliste für Softwarehäuser, die KI-Coding nutzen

Interne Richtlinie zur KI-Nutzung in Kundenprojekten.
Autorisierte Tools, Firmenkonten und Mindestkonfigurationen.
Trennung von Repositories, Workspaces, Daten, Prompts und Anmeldedaten pro Kunde.
Verbot der Eingabe von Kundendaten, Geheimnissen oder sensiblen Logs in nicht autorisierte Tools.
Rückverfolgbarkeit von PRs, Commits, Reviews, Scannern, Tests und Findings.
Obligatorische Review für Auth, APIs, Daten, Pipelines, Cloud und Abhängigkeiten.
SAST, SCA, Secret Scanning und negative Tests mit definierten Schwellenwerten.
Kontrolle von Lizenzen und neuen Abhängigkeiten.
Überprüfung von CI/CD, IaC, Containern, Deployments und Rollbacks.
Kundenbericht mit Umfang, Nachweisen, Fixes und Restrisiko.
Remediation-Management mit Verantwortlichen, Schweregrad, SLAs und Retests.

Wann ISGroup hinzuziehen?

Eine Softwarehaus kann mit einer Prozessbewertung oder einer Überprüfung eines Pilotprojekts beginnen. Die Wahl hängt vom Risiko und dem aktuellen Reifegrad ab.

Szenario	Hauptrisiko	Empfohlene Kontrolle
KI-Coding-Einsatz über mehrere Teams/Kunden	Nicht wiederholbare Kontrollen und schwierige Audits	Software Assurance Lifecycle
KI-generierte PRs bei sensiblem Code	Schwachstellen oder Regressionen im Code	Code Review
Anwendung oder API für Benutzer/Kunden exponiert	Laufzeitmissbrauch und Anwendungsschwachstellen	Web Application Penetration Testing
Kunde verlangt Nachweise vor der Lieferung	Umfang und Restrisiko nicht nachweisbar	Assurance-Programm und technischer Bericht

Der Wert liegt nicht nur darin, Bugs zu finden: Es geht darum, den Lieferprozess verteidigbar zu machen, indem dokumentiert wird, was geprüft wurde, von wem, mit welchen Nachweisen und mit welchen erklärten Grenzen.

Häufig gestellte Fragen

Muss eine Softwarehaus den Einsatz von KI-Coding immer deklarieren?
Das hängt vom Vertrag, den Kundenanforderungen und internen Richtlinien ab. In der Praxis ist es ratsam, bereit zu sein zu erklären, welche Tools verwendet werden, welche Daten ausgeschlossen sind und welche Kontrollen das Ergebnis verifizieren.
Muss der Kunde die Prompts sehen?
Nicht unbedingt. Prompts können sensible Informationen enthalten. Oft sind Richtlinien, Umfang, Review-Nachweise, Tests, Scanner-Ergebnisse, korrigierte Findings und Restrisiken nützlicher.
Wie beweist man, dass KI-generierter Code geprüft wurde?
Mit konkreten Nachweisen: PRs, Commits, Reviews, Tests, SAST/SCA-Berichte, Secret Scanning, Abhängigkeitsberichte, Code Review, WAPT, Findings, Fixes und Retests.
Wann ist eine unabhängige Code Review erforderlich?
Wenn der mit KI generierte oder geänderte Code Auth, Rollen, APIs, Daten, Abfragen, Geheimnisse, Abhängigkeiten, Pipelines, Cloud oder kritische Geschäftslogik berührt.
Wann ist neben der Code Review ein WAPT erforderlich?
Wenn die App für Benutzer oder Kunden erreichbar ist. Die Code Review analysiert den Quellcode; das WAPT prüft, ob das exponierte Verhalten unter realen Bedingungen ausnutzbar ist.

[Callforaction-SAL-Footer]

ISGroup Cybersicherheitsberatung

AI Coding und Sicherheit für Softwarehäuser: Assurance-Programm