Immer mehr Anbieter geben an, KI einzusetzen, um Software schneller zu entwickeln: Coding-Assistenten, Agenten, Testgeneratoren, Review-Tools, Pipeline-Automatisierungen. Für Softwarekäufer ist diese Information an sich nicht negativ – sie kann ein echter Vorteil sein, wenn der Anbieter Daten, Code, Abhängigkeiten, Tests und die Bereitstellung (Delivery) gut kontrolliert.
Das Risiko entsteht, wenn „wir nutzen KI“ zu einem kommerziellen Versprechen ohne Belege wird. Einkauf, CTO, CISO und Rechtsabteilung müssen Beweise fordern: Welche Tools werden verwendet, welche Daten fließen in den Prozess ein, welche Kontrollen überprüfen den Code und was passiert, wenn eine Schwachstelle auftritt? Die Due Diligence darf den Anbieter nicht blockieren: Sie muss diejenigen, die KI kontrolliert einsetzen, von denjenigen unterscheiden, die lediglich die Entwicklung beschleunigt haben, indem sie das Risiko auf den Kunden abwälzen.
Die richtige Frage lautet nicht: „Nutzen Sie KI?“
Nur zu fragen, ob der Anbieter KI nutzt, liefert eine wenig hilfreiche Antwort. Die korrekte Frage lautet: In welchen Phasen des Entwicklungszyklus wird KI eingesetzt und mit welchen Kontrollen? Die Anwendungsbereiche können sehr unterschiedlich sein – von der Generierung von Anwendungscode bis zum Refactoring, vom Schreiben von Tests bis zur Analyse von Logs und Bug-Reports, von der Generierung von Pipelines und IaC bis zur Empfehlung von Abhängigkeiten, bis hin zu assistierten Code-Reviews, Dokumentationen und Agenten, die Pull Requests öffnen oder Befehle ausführen.
Jede Nutzung hat ein anderes Risikoprofil. Ein Assistent, der Text für die Dokumentation vorschlägt, ist nicht gleichzusetzen mit einem Agenten, der Berechtigungen, Abfragen, Pipelines und Abhängigkeiten ändert: Sie gleich zu behandeln bedeutet, die realen Risiken zu unterschätzen.
Welche Kundendaten gelangen in die KI-Tools?
Der erste Bereich der Due Diligence betrifft den Datenumgang (Data Handling). Der Anbieter benötigt möglicherweise Logs, Tickets, Repositories, Dumps, Payloads, Screenshots oder Dokumentationen, um Probleme zu lösen. Wenn diese Elemente in Prompts, Chats, Agenten oder nicht autorisierte Tools gelangen, verliert der Kunde die Kontrolle über Daten und Geheimnisse.
Die zu stellenden Fragen betreffen: Kann der Anbieter Kundencode in KI-Tools eingeben? Darf er Logs, Tickets, personenbezogene Daten oder Produktionsdaten verwenden? Nutzt er Enterprise-Accounts oder persönliche Konten? Gibt es Regeln zur Schwärzung (Redaction)? Werden Prompts oder Transkripte gespeichert? Werden die Daten für das Training oder die Verbesserung des Dienstes verwendet? Gibt es vertragliche Beschränkungen für Unterauftragnehmer und Tools? Die Antwort muss dokumentiert sein und darf sich nicht auf mündliche Zusicherungen stützen.
Welche Kontrollen gibt es für KI-generierte oder -assistierte PRs?
Der Kunde muss nicht jedes operative Detail erfragen, aber er muss verstehen, ob KI-generierter Code blind akzeptiert wird. Nützliche Nachweise sind die interne Richtlinie des Anbieters zum KI-Coding, das Vorhandensein von Branch-Protection und obligatorischen Reviews, Beispiele für den PR-Workflow, CODEOWNERS oder Reviewer für sensible Bereiche, die Rückverfolgbarkeit von Commits und Releases, Code-Review-Berichte und Kriterien für Merge-Blockaden.
Bereiche, die eine strenge Überprüfung erfordern, sind Auth, Berechtigungen, APIs, Abfragen, Daten, Zahlungen, Geheimnisse, Abhängigkeiten, Pipelines, Cloud und Geschäftslogik. Wenn der Anbieter nicht erklären kann, wie er diese kontrolliert, verbleibt das Risiko beim Kunden.
Tests, Scanner und Remediation: Welche Beweise gibt es?
Ein Anbieter kann behaupten, SAST, SCA, Secret-Scanning und automatisierte Tests zu verwenden. Die nächste Frage ist, was mit den Ergebnissen (Findings) passiert: Welche Scanner werden wann ausgeführt, welche Schweregrade blockieren das Release, wer führt das Triage durch, wie werden False Positives und Ausnahmen gehandhabt, welche negativen Tests decken Rollen, Mandanten, Eingaben und Missbrauch ab, wie wird ein Fix verifiziert und welche Berichte werden mit dem Kunden geteilt?
Scanner und Tests ersetzen keine unabhängige Überprüfung, sind aber ein Indikator für den Prozess. Wenn der Anbieter keine Berichte erstellt oder keine SLAs für die Fehlerbehebung (Remediation) hat, laufen die Kontrollen Gefahr, nur formeller Natur zu sein.
Abhängigkeiten, Lizenzen und Lieferkette
KI kann Bibliotheken, Plugins, Actions, Basis-Container-Images und Build-Tools vorschlagen. Für den Kunden wirkt sich dies auf Schwachstellen, Lizenzen, Wartung, Audits und Lock-in-Effekte aus. Zu den anzufordernden Nachweisen gehören die Liste der Hauptabhängigkeiten, die Software Composition Analysis (SCA), der Lizenzbericht, die SBOM (Software Bill of Materials), wenn der Umfang dies erfordert, die Richtlinie für neue Abhängigkeiten, das Pinnen von Versionen und Actions, das CVE-Management sowie die Herkunft und Integrität der Artefakte.
Eine Abhängigkeit kann technisch bequem sein, aber aufgrund der Kundenrichtlinien nicht akzeptabel. Dies muss vor der Lieferung entdeckt werden, nicht während eines Audits.
Geheimnisse, Umgebungen und Zugriffe
Die Due Diligence muss überprüfen, wie der Anbieter Anmeldedaten, Umgebungen und Testdaten verwaltet. Zu klärende Punkte sind die Verwendung von synthetischen oder realen Daten, der Schutz von Konfigurationsdateien, API-Schlüsseln, Cloud-Tokens und Webhook-Secrets, ob Anmeldedaten persönlich oder projektbezogen sind, die Trennung zwischen Staging und Produktion, wer Zugriff auf die Kundenumgebungen hat, das Vorhandensein von Zugriffsprotokollen und Widerrufsverfahren sowie das Vorgehen, wenn ein Mitarbeiter das Projekt verlässt.
Wenn ein Kundenschlüssel in Prompts, Logs oder Repositories landet, muss der Vertrag Benachrichtigung, Rotation, Folgenabschätzung und klare Verantwortlichkeiten vorsehen.
Technische Klauseln zum Einfügen oder Überprüfen
Allgemeine Klauseln zu „Best Practices“ reichen nicht aus. Für Anbieter, die mit KI entwickeln, sind konkretere Anforderungen erforderlich. Diese sollten abdecken: zugelassene KI-Tools und Unterauftragnehmer, das Verbot oder die Einschränkung von Kundendaten in Prompts, die Verpflichtung zu Unternehmens-Accounts mit Enterprise-Kontrollen, die Trennung zwischen Kunden, die menschliche Überprüfung sensibler Bereiche, Mindeststandards für Scanning und Tests, das Management von Abhängigkeiten und Lizenzen, die Offenlegung von Schwachstellen und Vorfällen, SLAs für die Fehlerbehebung, das Recht auf Audits oder unabhängige Überprüfungen sowie die Bereitstellung von Berichten, SBOMs oder Nachweisen bei Bedarf.
Rechts- und Einkaufsabteilungen sollten technische Kontrollen nicht allein schreiben: Sie müssen technische Anforderungen in überprüfbare Verpflichtungen übersetzen.
Wann ist eine unabhängige Überprüfung erforderlich?
Die dokumentarische Due Diligence ist nützlich, aber nicht immer ausreichend. Wenn die Software kritisch, exponiert, mandantenfähig, in Unternehmenssysteme integriert ist oder reale Daten verarbeitet, ist eine technische Überprüfung erforderlich, die über die vom Anbieter selbst bereitgestellte Dokumentation hinausgeht.
Die unabhängige Überprüfung kann eine Code-Review des gelieferten Codes, der Auth, APIs, Geheimnisse, Abhängigkeiten und Pipelines beinhalten; einen Web Application Penetration Test für exponierte Apps oder APIs; sowie eine Prozessüberprüfung mit dem Software Assurance Lifecycle, wenn der Anbieter kontinuierlich arbeitet. Der Punkt ist nicht, die gesamte Arbeit des Anbieters zu duplizieren, sondern die Punkte zu überprüfen, an denen ein Fehler direkte Auswirkungen auf den Kunden hätte.
Checkliste für Fragen an den Anbieter
- Welche KI-Tools nutzen Sie bei der Entwicklung?
- In welchen Phasen: Code, Tests, Review, Pipeline, Dokumentation?
- Welche Kundendaten können in die Prompts oder den Kontext gelangen?
- Nutzen Sie Enterprise-Accounts, SSO, MFA und Logging?
- Können der Code oder die Prompts für das Training oder die Verbesserung des Dienstes verwendet werden?
- Wie trennen Sie Kunden, Repositories, Workspaces und Umgebungen?
- Welche Kontrollen blockieren Merges und Releases?
- Welche Bereiche erfordern eine obligatorische menschliche Überprüfung?
- Welche Scanner führen Sie aus und welche Berichte teilen Sie?
- Wie verwalten Sie Abhängigkeiten, Lizenzen, SBOMs und CVEs?
- Wie schützen Sie Geheimnisse und Anmeldedaten des Kunden?
- Welche SLAs haben Sie für Fehlerbehebung und Retests?
- Akzeptieren Sie eine unabhängige Überprüfung vor dem Go-Live oder der endgültigen Abnahme?
Warnsignale
- Der Anbieter spricht nur über Produktivität, nicht über Kontrollen.
- Er kann nicht sagen, welche KI-Tools er verwendet.
- Er nutzt persönliche Konten oder kostenlose Pläne für Kundencode.
- Er hat keine Regeln für Daten und Prompts.
- Er liefert keine Nachweise für Reviews, Tests oder Scanner.
- Er unterscheidet nicht zwischen generiertem und überprüftem Code.
- Er kontrolliert keine Lizenzen und Abhängigkeiten.
- Er akzeptiert keine unabhängigen Überprüfungen für kritische Bereiche.
- Er hat keine SLAs für die Fehlerbehebung.
- Er weiß nicht, wer im Falle einer Schwachstelle verantwortlich ist.
Wann Sie ISGroup hinzuziehen sollten
ISGroup kann die technische Due Diligence vor der Vertragsunterzeichnung, während der Abnahme eines Releases oder vor dem Go-Live unterstützen. Die beste Überprüfung ist verhältnismäßig: Es ist nicht dasselbe Kontrollniveau für ein internes Tool mit geringem Risiko erforderlich wie für eine exponierte Plattform mit personenbezogenen Daten, Rollen und APIs.
| Szenario | Hauptrisiko | Empfohlene Kontrolle |
|---|---|---|
| Gelieferter Code oder kritische PRs | Schwachstellen oder Regressionen im Code | Code-Review |
| Exponierte Web-App oder API | Anwendungsmissbrauch von außen | Web Application Penetration Testing |
| Kontinuierlicher Anbieter oder wiederkehrende Entwicklung | Prozess im Zeitverlauf nicht überprüfbar | Software Assurance Lifecycle |
FAQ
- Ist es riskant, einen Anbieter zu wählen, der KI einsetzt?
- Nicht unbedingt. Es ist riskant, einen Anbieter zu wählen, der KI ohne Richtlinien, Nachweise, Reviews, Tests, Datenmanagement und klare Verantwortlichkeiten einsetzt.
- Muss ich verlangen, alle Prompts zu sehen?
- Nicht immer. Die Prompts können sensible Informationen des Anbieters selbst enthalten. Normalerweise sind Richtlinien, Review-Berichte, Scanner-Ergebnisse, Tests, SBOMs, korrigierte Findings, Vertragsklauseln und das Recht auf Audits nützlicher.
- Welches Dokument sollte ich zuerst anfordern?
- Eine Richtlinie oder Beschreibung des KI-Coding-Prozesses des Anbieters: verwendete Tools, verbotene Daten, obligatorische Reviews, technische Kontrollen, Abhängigkeitsmanagement und SLAs für die Fehlerbehebung.
- Wann ist eine unabhängige Code-Review erforderlich?
- Wenn der gelieferte Code Auth, APIs, Daten, Geheimnisse, Abfragen, Abhängigkeiten, Pipelines, Cloud oder kritische Geschäftslogik berührt.
- Wann ist ein Web Application Penetration Testing erforderlich?
- Wenn die App oder API Benutzern, Kunden, Partnern oder dem Internet ausgesetzt ist und reale Daten, Rollen, Uploads, Zahlungen oder Integrationen verarbeitet.
[Callforaction-CR-Footer]
Leave a Reply