AI-generierter Code als Lieferkettenrisiko: Kontrolle in der Softwareentwicklung

AI-generierter Code ist in vielen Entwicklungsteams nicht mehr nur ein Experiment, sondern Teil des Arbeitsalltags. Damit verschiebt sich eine zentrale Frage: Nicht mehr nur "Wer hat den Code geschrieben?", sondern "Wie ist dieser Code entstanden, geprüft und in die Lieferkette gelangt?". Die These dieses Beitrags: AI-generierter Code kann Delivery beschleunigen, aber nur dann verantwortbar skaliert werden, wenn Provenance, Reviews, Tests und Build-Kontrollen mitwachsen.

AI-generierter Code als Lieferkettenrisiko verstehen

AI-generierter Code bezeichnet Quellcode, Konfigurationen, Tests, Skripte oder Dokumentation, die ganz oder teilweise durch ein KI-System vorgeschlagen oder erzeugt wurden. Das kann ein einzelner Code-Snippet im Editor sein, ein generierter Unit-Test, eine Änderung an einer Pipeline-Datei oder ein größerer Pull Request, der aus einem Issue, Logfile oder Architekturhinweis abgeleitet wurde.

Das Lieferkettenrisiko entsteht nicht dadurch, dass KI grundsätzlich schlechteren Code schreibt als Menschen. Es entsteht, weil Herkunft, Kontext und Verantwortung unschärfer werden. Ein Entwickler kann einen Vorschlag übernehmen, ohne jede Annahme des Modells zu prüfen. Ein KI-Werkzeug kann eine veraltete Bibliothek vorschlagen, einen unsicheren Default verwenden oder eine Build-Konfiguration ändern, die im Review nur oberflächlich betrachtet wird.

Ein typisches Missverständnis ist die Annahme, AI-generierter Code sei nur ein Qualitätsproblem. Qualität ist wichtig, aber die Software-Lieferkette umfasst mehr: Abhängigkeiten, Build-Umgebungen, Artefakte, Signaturen, Secrets, Deployment-Pfade und Nachvollziehbarkeit. Wenn KI in diesen Prozess eingreift, muss sie wie jeder andere Einfluss auf die Lieferkette behandelt werden.

Ein zweites Missverständnis lautet, dass ein menschlicher Review automatisch ausreicht. Reviews bleiben zentral, aber sie müssen anders gestaltet werden. Wer AI-Code prüft, muss nicht nur Stil und Funktion bewerten, sondern auch Herkunft, Annahmen, Abhängigkeiten, Sicherheitsmuster und Testabdeckung.

Warum jetzt? Treiber und Kontext

Technisch werden KI-Werkzeuge besser darin, vorhandene Codebasen zu lesen, Änderungen vorzuschlagen und mehrere Dateien konsistent anzupassen. Gleichzeitig integrieren sie sich tiefer in Entwicklungsumgebungen, Repositories, Issue-Tracker, CI/CD-Systeme und Wissensdatenbanken. Dadurch steigt der Nutzen, aber auch die mögliche Wirkung eines ungeprüften Vorschlags.

Organisatorisch stehen Engineering-Teams unter Druck, schneller zu liefern. KI hilft bei Boilerplate, Tests, Migrationen, Refactorings, Dokumentation und Analyse von Fehlermeldungen. Genau diese Geschwindigkeit kann aber dazu führen, dass Review-Prozesse, Architekturentscheidungen und Security-Gates nicht mitziehen.

Ökonomisch ist AI-generierter Code attraktiv, weil er Routinearbeit reduziert und Wissen schneller verfügbar macht. Der Business Case kippt jedoch, wenn versteckte Folgekosten entstehen: unsichere Abhängigkeiten, schwer wartbare Änderungen, unklare Eigentümerschaft oder Builds, deren Herkunft nicht mehr sauber nachvollzogen werden kann.

Der Kontext ist deshalb nicht "KI ja oder nein", sondern "welche Entwicklungsanteile dürfen KI-gestützt entstehen, unter welchen Kontrollen und mit welcher Verantwortung?". Unternehmen brauchen dafür keine Sonderwelt neben DevSecOps. Sie müssen bestehende Prinzipien auf AI-generierten Code anwenden und dort ergänzen, wo KI neue Lücken erzeugt.

Wie AI-generierter Code in der Lieferkette wirkt

Aus Prozesssicht beginnt das Risiko früh. Ein Entwickler formuliert eine Aufgabe, ein KI-Werkzeug erhält Kontext aus Code, Tickets, Logs oder Dokumentation und erzeugt einen Vorschlag. Dieser Vorschlag wird angepasst, committet, gebaut, getestet, paketiert und später deployed. An jeder Station kann zusätzliche Kontrolle greifen oder fehlen.

Eine robuste Sicht auf AI-generierten Code betrachtet mindestens diese Komponenten:

• Eingabekontext: Welche Dateien, Tickets, Logs oder Dokumente wurden dem KI-System bereitgestellt?
• Erzeugter Vorschlag: Welche Dateien, Abhängigkeiten oder Konfigurationen wurden verändert?
• Menschliche Verantwortung: Wer übernimmt die Änderung fachlich und technisch?
• Prüfpfad: Welche Reviews, Tests, Scans und Architekturchecks wurden ausgeführt?
• Build-Provenance: Aus welcher Quelle, in welcher Umgebung und mit welchen Abhängigkeiten entstand das Artefakt?
• Deployment-Freigabe: Welche Policy entscheidet, ob die Änderung in höhere Umgebungen darf?

Wichtig ist die Trennung zwischen Assistenz und Autorität. Ein KI-Werkzeug kann Vorschläge liefern, Tests ergänzen oder Risiken markieren. Die Verantwortung für Merge, Release und Betrieb bleibt bei klar benannten Menschen und Teams. Wenn diese Grenze unklar wird, entsteht Verantwortungsdiffusion: Der Entwickler vertraut dem Tool, das Tool kennt den Betrieb nicht, und das System landet trotzdem in Produktion.

Technisch sollten AI-gestützte Änderungen deshalb in denselben Lieferkettenpfad wie menschlich geschriebener Code laufen. Das bedeutet: kein Direkt-Commit in geschützte Branches, keine Umgehung von CI, keine Sonderrechte für generierte Änderungen und keine automatischen Releases ohne Policy-Prüfung. KI kann Arbeit vorbereiten, aber sie sollte nicht die Kontrollpunkte ersetzen.

Praxis: Anwendungsfälle und Entscheidungslogik

Ein erster Use Case ist Testgenerierung. KI kann fehlende Unit-Tests vorschlagen, Grenzfälle ergänzen oder bestehende Tests verständlicher machen. Das ist sinnvoll, wenn Entwickler die erwartete Fachlogik prüfen und die Tests gegen echte Fehlerbilder laufen. Wenn Tests nur generiert werden, um Coverage zu erhöhen, entsteht Scheinsicherheit.

Ein zweiter Use Case sind Migrationen und Refactorings. KI kann veraltete APIs finden, wiederkehrende Muster anpassen oder Konfigurationsdateien aktualisieren. Das spart Zeit, setzt aber eine klare Strategie voraus: kleine Pull Requests, aussagekräftige Regressionstests, Codeowner-Review und Rollback-Fähigkeit. Je breiter die Änderung, desto wichtiger sind automatisierte Checks und ein erfahrener technischer Review.

Ein dritter Use Case liegt in CI/CD und Infrastructure as Code. KI kann Pipeline-Schritte erklären, Build-Fehler analysieren oder Deployment-Konfigurationen vorbereiten. Hier ist Vorsicht nötig, weil kleine Änderungen an Secrets, Berechtigungen, Container-Builds oder Deployment-Rechten große Wirkung haben. AI-generierte Pipeline-Änderungen sollten deshalb immer durch Security- oder Plattformregeln geprüft werden.

Ein vierter Use Case ist die Arbeit mit Abhängigkeiten. KI kann Bibliotheken vorschlagen oder Beispielcode mit Imports erzeugen. Das ist nützlich, wenn ein definierter Katalog erlaubter Komponenten existiert. Ohne Dependency-Policy können neue Pakete unbemerkt in die Lieferkette gelangen.

Die Entscheidungslogik sollte pragmatisch sein: Wenn KI nur lokalen Hilfscode oder Tests vorschlägt, reichen normale Reviews und Tests. Wenn produktiver Code, Abhängigkeiten oder Schnittstellen betroffen sind, braucht es zusätzliche Prüfungen. Wenn Build-, Release-, Security- oder Infrastrukturkonfigurationen verändert werden, sollten Policy-Gates und erfahrene Owner zwingend beteiligt sein.

Risiken, Grenzen, Kontrollmechanismen

Das erste Risiko ist unklare Herkunft. Wenn nicht erkennbar ist, ob Code manuell, KI-gestützt oder aus externen Beispielen entstanden ist, wird spätere Analyse schwer. Gegenmaßnahmen sind Pull-Request-Templates mit Herkunftshinweisen, klare Commit-Regeln, dokumentierte Tool-Nutzung und nachvollziehbare Review-Entscheidungen.

Das zweite Risiko sind unsichere Muster. AI-generierter Code kann schwache Authentifizierung, fehlende Eingabevalidierung, breite Berechtigungen oder unsichere Defaults vorschlagen. Gegenmaßnahmen sind statische Analyse, Dependency-Scanning, Secret-Scanning, Security-Reviews für kritische Bereiche und sichere interne Codebeispiele, an denen sich Teams orientieren.

Das dritte Risiko betrifft Abhängigkeiten. Ein KI-Vorschlag kann neue Pakete, Container-Images oder Build-Tools einführen, ohne deren Wartbarkeit, Lizenzlage oder Sicherheitsstatus zu bewerten. Gegenmaßnahmen sind erlaubte Paketquellen, Approval-Prozesse für neue Dependencies, SBOM-Erzeugung, Versions-Pinning und regelmäßige Rezertifizierung kritischer Komponenten.

Das vierte Risiko ist Review-Ermüdung. Wenn KI sehr viele Änderungen erzeugt, steigt die Menge an Code, die Menschen prüfen müssen. Große, gemischte Pull Requests sind besonders riskant. Gegenmaßnahmen sind kleine Änderungseinheiten, klare Review-Checklisten, Codeowner-Regeln, automatisierte Tests und ein Limit für automatisch erzeugte Änderungen pro Pull Request.

Das fünfte Risiko liegt in vertraulichem Kontext. KI-Werkzeuge können Quellcode, Fehlermeldungen, Kundendaten oder interne Architekturdetails verarbeiten. Gegenmaßnahmen sind Datenklassifizierung, freigegebene Tool-Konfigurationen, Ausschluss sensibler Dateien, Mandantentrennung, Protokollierung und klare Regeln für externe Dienste.

Die Grenze jeder Kontrolle ist, dass sie Verantwortung nicht vollständig automatisiert. Scans finden nicht jede Schwäche, Tests beweisen nicht jede fachliche Korrektheit, und ein Review kann Annahmen übersehen. Deshalb muss AI-generierter Code als Teil eines mehrschichtigen Kontrollsystems betrachtet werden: Policy, Technik, Prozess und Engineering-Urteil wirken zusammen.

Umsetzung: 30-60-90-Tage-Plan

In den ersten 30 Tagen sollte Transparenz entstehen. IT-Management, Engineering und Security sollten erfassen, welche KI-Werkzeuge in der Entwicklung genutzt werden, welche Repositories betroffen sind und welche Daten in diese Werkzeuge gelangen dürfen.

• KI-Werkzeuge und Nutzungsarten in Engineering-Teams inventarisieren
• Regeln für vertraulichen Code, Secrets, Kundendaten und Logs festlegen
• Pull-Request-Template um Herkunft, KI-Nutzung und neue Abhängigkeiten ergänzen
• Kritische Repositorys mit Codeowner-Regeln und Branch-Schutz abgleichen
• Bestehende Scans für Secrets, Dependencies und statische Analyse prüfen

Nach 60 Tagen sollte ein kontrollierter Standardprozess stehen. Ziel ist nicht Bürokratie, sondern ein wiederholbarer Weg, damit AI-generierter Code schnell und kontrolliert in Reviews gelangt.

• Review-Checkliste für AI-generierten Code einführen
• Policy für neue Dependencies und Build-Änderungen definieren
• SBOM-Erzeugung für priorisierte Artefakte aktivieren oder überprüfen
• CI-Gates für Tests, Security-Scans und Policy-Verstöße schärfen
• Zwei bis drei reale Pull Requests nachträglich analysieren und Lücken ableiten

Nach 90 Tagen sollte AI-Code-Governance Teil des normalen Delivery-Modells sein. Neue Werkzeuge, neue Integrationen und neue Automatisierungsgrade werden dann nicht mehr ad hoc entschieden, sondern über klare Kriterien bewertet.

• Referenzprozess für AI-gestützte Entwicklung dokumentieren
• Build-Provenance und Artefakt-Nachvollziehbarkeit in Release-Reviews aufnehmen
• Metriken für Review-Aufwand, Defekte, Security-Funde und Durchlaufzeit beobachten
• Schulung für Entwickler, Reviewer und Product Owner durchführen
• Regeln regelmäßig anhand echter Incidents, Befunde und Team-Erfahrungen anpassen

Fazit

AI-generierter Code ist weder automatisch riskant noch automatisch produktivitätssteigernd. Entscheidend ist, ob die Organisation seine Herkunft, Prüfung und Wirkung in der Software-Lieferkette kontrollieren kann. Wer KI-Vorschläge wie normale externe Beiträge behandelt, gewinnt Geschwindigkeit, ohne zentrale DevSecOps-Prinzipien aufzugeben. Besonders kritisch sind Änderungen an Abhängigkeiten, Build-Prozessen, Infrastruktur und sicherheitsrelevanten Komponenten. Der beste Einstieg ist ein pragmatischer Kontrollrahmen, der Reviews unterstützt, statt Entwicklung unnötig zu blockieren.

Wenn du AI-generierten Code in deiner Organisation nutzt, starte mit einem Review deiner Pull-Request-, Dependency- und CI/CD-Regeln, bevor du den Automatisierungsgrad erhöhst.