Leitfaden
KI-generierten Code auf geleakte Secrets scannen: so geht’s
Repository-Stand scannen, Frontend-Exposition prüfen, Git-Historie separat ansehen. Was vetkit erkennt und was zu tun ist, wenn Zugangsdaten geleakt wurden.
· 5 Min. Lesezeit · Vom vetkit-Team
Um KI-generierten Code auf geleakte Secrets zu scannen, führen Sie einen Secret-Scanner gegen die Repository-Version aus, die Sie ausliefern wollen, prüfen die Belege mit Datei und Zeile und widerrufen alle offengelegten Zugangsdaten. In vetkit enthält der Security Quick Scan die Secret-Erkennung im Repository; die Git-Historie und die Exposition von Schlüsseln im Browser erfordern separate Prüfungen. Ein sauberer Bericht gilt nur für die Dateien und Checks, die tatsächlich gelaufen sind.
1. Umfang des Scans festlegen
Generierter Code kann kopierte Zugangsdaten enthalten, einen realistisch aussehenden Platzhalter oder Code, der einen Schlüssel erst beim Build der App offenlegt. Das sind unterschiedliche Probleme. Legen Sie fest, welche Belege Sie brauchen, bevor Sie das Ergebnis interpretieren:
| Frage | Relevanter Check | Grenze |
|---|---|---|
| Sind Zugangsdaten in den gescannten Repository-Dateien vorhanden? | Secrets (gitleaks), im Security Quick Scan enthalten | Musterbasierte Erkennung im Checkout, kein Beweis, dass keinerlei Zugangsdaten vorhanden sind |
| Wurden Zugangsdaten aus den aktuellen Dateien gelöscht, stecken aber noch in Commits? | Der separate Analyzer für die Secrets-Historie, sofern im gewählten Audit-Umfang verfügbar | Begrenzte Historie; nicht Teil des Quick Scan |
| Könnte die Build-Konfiguration einen Anbieterschlüssel gegenüber Browsern offenlegen? | Checks für LLM-Apps bei unterstützten Codemustern, plus Ihre eigene Prüfung des Builds | Nicht Teil des Quick Scan; ein Quellcode-Audit prüft Ihre deployten Assets nicht |
2. Die beabsichtigte Repository-Version scannen
- Verbinden Sie das Repository in vetkit und wählen Sie dann den Security Quick Scan oder einen verfügbaren Audit-Umfang, der Secret-Erkennung enthält.
- Prüfen Sie Repository und Ziel-Ref. Scans von Remote-Repositorys sehen weder ungespeicherte Editor-Puffer noch lokale Dateien, die Sie nicht gepusht haben. Committen Sie kein vermutetes Secret, nur damit es scannbar wird.
- Warten Sie den Abschluss ab und prüfen Sie die Analyzer-Ergebnisse auf Fehler oder übersprungene Checks, bevor Sie die Befunde lesen. Ein nicht verfügbarer Scanner ist kein bestandener Check.
Wenn Sie über einen Assistenten arbeiten, erklärt der MCP-Leitfaden für Claude Code und Cursor, wie Sie ein Repository auswählen und Audit-Ergebnisse einsehen. Verwenden Sie in Prompts Platzhalter; fügen Sie nie echte Zugangsdaten in den Assistenten ein, um zu fragen, ob sie gültig sind.
3. Jeden Befund prüfen
Lesen Sie Regel, Schweregrad, Dateipfad und Zeile. Die Secret-Befunde von vetkit verwenden geschwärzte Ausschnitte; sehen Sie sich den Quellcode privat an, um echte Zugangsdaten von synthetischen Testdaten zu unterscheiden. Generische Muster können False Positives erzeugen, und unbekannte Formate können übersehen werden. Ein Treffer allein sagt nicht aus, ob die Zugangsdaten noch aktiv sind.
Priorisieren Sie Zugangsdaten, die Zugriff auf Cloud-Ressourcen, Repositorys, das Veröffentlichen von Paketen oder Produktionsdaten gewähren. Halten Sie den betroffenen Dienst und die verantwortliche Person für die Behebung fest, ohne das Secret in ein Ticket, einen Screenshot oder einen Chat zu kopieren. Verwerfen Sie einen Befund nicht nur deshalb, weil der Assistent den Wert als Beispiel bezeichnet.
4. Browser-Exposition und Historie prüfen
Ein Schlüssel kann außerhalb von Git bleiben und Nutzer trotzdem über einen Frontend-Build erreichen. Prüfen Sie die Verwendung öffentlicher Umgebungsvariablen, SDK-Aufrufe von Anbietern und die Bundler-Konfiguration, und sehen Sie sich dann die erzeugten Browser-Assets in Ihrer eigenen, kontrollierten Umgebung an. Beispiele finden Sie im Leitfaden zu API-Schlüsseln im Frontend. Der Repository-Scan baut Ihre App nicht automatisch mit den Secrets des Deployments und untersucht auch nicht die Bundles der Live-Website.
Wenn Zugangsdaten möglicherweise früher committet wurden, beziehen Sie die separate Prüfung der Historie ein, sofern Ihr Audit-Umfang das zulässt. Ihr Standardfenster umfasst höchstens 500 Commits und kann kleiner sein, wenn die Historie des Checkouts flacher ist. Es ist keine erschöpfende Suche über jeden Branch, jeden Fork oder jede Kopie des Repositorys.
5. Reagieren und erneut scannen
- Widerrufen oder rotieren Sie offengelegte Zugangsdaten beim jeweiligen Anbieter. Eine Zeile zu löschen oder einen Commit umzuschreiben, macht einen kopierten Schlüssel nicht ungültig.
- Legen Sie den Ersatz in einem geeigneten serverseitigen Secret-Speicher oder in der Laufzeitumgebung ab. Stellen Sie sicher, dass er weder in Browser-Code gebündelt noch in Logs ausgegeben werden kann.
- Prüfen Sie die Zugriffs- und Nutzungsprotokolle des Anbieters auf unerwartete Aktivität. Stimmen Sie eine Bereinigung der Historie mit den Mitwirkenden des Repositorys ab; die Rotation bleibt trotzdem notwendig.
- Führen Sie einen neuen Scan gegen die korrigierte Version aus und wiederholen Sie die relevanten Prüfungen von Build oder Historie. Bewahren Sie die Zielversion des Audits zusammen mit Ihrer Dokumentation der Behebung auf.
Quellen und Grenzen
Geprüft am 1. November 2026 anhand der Quick-Scan-Konfiguration von vetkit und der Implementierungen der Analyzer für gitleaks, Secrets-Historie und LLM-Apps. Der Quick Scan führt Posture, gitleaks und OSV aus; er enthält nicht jeden Analyzer eines vollständigen Audits. Die gitleaks-Integration überspringt standardmäßig Dateien größer als 5 MB, und Scans unterliegen Limits für Repository, Dateien und Laufzeit. Prüfen Sie Abdeckung und Warnungen des tatsächlichen Laufs.
Die Dokumentation beschreibt den Audit-Workflow, und der öffentliche Check-Katalog dokumentiert die eigenen Regeln. Dieser Katalog ist keine vollständige Liste der gitleaks-Signaturen von Drittanbietern. Dieser Leitfaden beschreibt Schritte zur Erkennung und Behebung; weder ein sauberer Scan noch ein hoher Score garantiert, dass eine App sicher ist.