Monitoring von KI-generiertem Code — warum ein einmaliger Scan nicht reicht
Code, den niemand vollständig im Kopf hatte
Eine mit intensiver KI-Unterstützung zusammengesetzte Anwendung hat eine Eigenschaft, die ein handgeschriebenes Projekt in diesem Ausmaß nicht teilt: Niemand — weder der Mensch noch das Modell — hat alle Entscheidungen, die eingeflossen sind, gleichzeitig im Kopf. Das Modell schlägt eine Abhängigkeit in der Version vor, die es aus den Trainingsdaten kennt, nicht die neueste. Es generiert eine Konfigurationsdatei nach einem gängigen Muster, das nie Zeile für Zeile gelesen wird, weil es „funktioniert“. Es erstellt einen Test-Endpunkt, der vor dem Deployment verschwinden sollte und nicht verschwunden ist. Nichts davon ist individuelle Nachlässigkeit — es ist die Folge davon, dass Code schneller entsteht, als ihn jemand tatsächlich lesen und beurteilen kann.
Warum sich das anders verhält als ein handgeschriebenes Projekt
Ein paar Muster wiederholen sich in der KI-unterstützten Entwicklung:
- Abhängigkeiten festgenagelt auf das, was das Modell vorgeschlagen hat — Bibliotheksversionen spiegeln die Trainingsdaten des Modells wider, nicht den aktuellen Stand der Sicherheitspatches. Ohne explizite Prüfung bleiben diese Versionen monatelang im Projekt.
- Generierte Konfiguration ohne Review kopiert — CORS-Regeln, Sicherheits-Header, Beispiel-
.env-Dateien. Sie funktionieren, also schaut niemand noch einmal hin. - Preview- und Staging-Deployments, die weiterlaufen — schnellere Iteration bedeutet mehr Deployments, mehr Subdomains, mehr Dinge, die nach ein paar Wochen vergessen werden.
- Secrets und Debug-Endpunkte, die es in die Produktion schaffen — ein generiertes Debug-Panel oder ein Testschlüssel, der nur vorübergehend gedacht war.
- Änderungen gehen live, schneller als sie jemand reviewt — der Review-Zyklus, der früher jede Änderung ausgebremst hat, verkürzt sich mit KI-Unterstützung oder fällt ganz weg.
Nichts davon ist eine exotische Fehlerklasse. Es ist eine Folge von Geschwindigkeit — und Geschwindigkeit ist genau der Grund, warum Menschen überhaupt zu KI-Unterstützung greifen.
Warum ein einmaliger Scan nicht ausreicht
Ein einmaliger Sicherheitsscan ist eine Aussage über den Zustand des Codes zu einem einzigen Zeitpunkt. Bei einem Projekt, das sich wöchentlich ändert — oft mit mehr Deployments an einem Tag, als ein älteres Team in einem Monat geschafft hat — bleibt diese Aussage nur kurz gültig. Die relevante Frage ist nicht „ist es jetzt sicher?“, sondern „sobald es nicht mehr sicher ist, wie schnell erfahre ich es?“
Ein einmaliger Scan kann diese Frage nicht beantworten — ihm fehlt ein Vergleichspunkt. Die Lösung ist nicht „gründlicher scannen“, sondern wiederholt scannen und das Ergebnis mit dem von gestern vergleichen.
Was tägliches Beobachten konkret ändert
Beim ersten Scan speichert Watch den Zustand der Domain als Ausgangslinie — welche Header der Server sendet, ob HTTPS läuft, welche Dateien erreichbar sind, wie DNS- und E-Mail-Authentifizierungseinträge aussehen. Danach läuft derselbe Check jeden Tag erneut und vergleicht das Ergebnis mit dem vorherigen. Ändert sich etwas auf eine Weise, die Aufmerksamkeit verdient, geht sofort eine Warnung raus — nicht erst beim nächsten manuellen Scan, den vielleicht niemand startet. Einmal im Monat kommt zusätzlich eine Zusammenfassung, unabhängig davon, ob in diesem Monat etwas ausgelöst hat.
Der Unterschied zum einmaligen Scan liegt nicht darin, dass Watch mehr sieht. Er liegt darin, dass Watch dasselbe wiederholt sieht und sagen kann, wann es sich geändert hat.
Was das konkret abfängt
Ein paar realistische Beispiele dafür, was der tägliche Vergleich erkennen kann:
- Eine neu freigelegte Datei. Eine generierte
.env, ein vergessenes Konfigurations-Backup oder ein offenes Directory-Listing, das nach einem Deployment auftaucht und gestern noch nicht da war. - Ein durchgesickerter KI-Anbieter-API-Schlüssel im Client-Code. Ein OpenAI-, Anthropic- oder Google-API-Schlüssel, direkt ins Frontend eingefügt — ein typisches Artefakt schnellen Prototypings, bei dem der Schlüssel „vorübergehend“ clientseitig gesetzt wird und dort bleibt.
- Ein Zertifikat, das bald abläuft oder bereits abgelaufen ist. Häufig bei Preview- und Staging-Domains, die nach Ende der Iteration niemand mehr anfasst.
- Geschwächte E-Mail-Authentifizierung. Eine DNS-Änderung (auch eine beiläufige, im Zuge anderer Infrastrukturarbeiten) kann SPF/DMARC deaktivieren oder schwächen — Watch erkennt das als Regression gegenüber dem vorherigen Zustand.
- Ein eingeschleustes Schadskript. Landet fremder Code auf der Website, sieht der nächste tägliche Check das als neuen Fund — nicht erst einen Monat später.
- Ein Sprung in der Gesamtschwere der Funde, selbst wenn er sich keiner einzelnen Prüfung eindeutig zuordnen lässt.
Was Watch nicht tut
Watch ist eine passive, externe Black-Box-Beobachtung — sie liest nur, was der Server selbst einem gewöhnlichen Besucher preisgibt: HTTP-Header, den TLS-Handshake, öffentlich erreichbare Dateien, DNS- und E-Mail-Einträge. Watch loggt sich nicht ein, liest nicht den Quellcode, ist keine statische Analyse (SAST) und kein Code-Review. Watch sieht nicht ins Innere der Anwendung — sie kann die Logik, die das Modell geschrieben hat, nicht prüfen, ebenso wenig Abhängigkeiten, die von außen nicht sichtbar sind.
Das hat eine konkrete Konsequenz: Die heutige tägliche Prüfmenge deckt nicht alles ab, was bei KI-unterstützter Entwicklung am meisten wehtut. Veraltete JavaScript-Bibliotheken im Frontend, ein Anmeldeformular über unverschlüsseltes HTTP oder ein verwaister CNAME-Eintrag nach einem stillgelegten Preview-Deployment (Subdomain-Takeover) sind genau die Art von Risiko, für die kontinuierliches Monitoring gedacht ist — und derzeit gehören sie nicht zu Watchs täglichen Checks. Wir erweitern die Prüfmenge schrittweise; solange das noch nicht der Fall ist, sagen wir das lieber offen, statt den Eindruck zu erwecken, Watch würde mehr beobachten, als es tatsächlich tut.
Kurz gesagt
Der Wert von kontinuierlichem Monitoring für KI-generierten Code liegt nicht darin, Code-Review zu ersetzen oder jede Risikoklasse abzudecken. Er liegt darin, die diffuse Angst „ich weiß nicht, was da alles drinsteckt“ in eine begrenzte Frage zu verwandeln: Wie lange dauert es, bis ich erfahre, dass sich etwas, das Watch sehen kann, verschlechtert hat.