Hardcodierte Passwörter und API-Keys sind nach wie vor einer der häufigsten Wege, auf denen Credentials nach aussen gelangen. Sie werden versehentlich committet, bleiben für immer in der Git-History und tauchen meist erst dann auf, wenn sie schon ausgenutzt werden. In Teil 7 unserer GitLab DevSecOps Serie ergänzen Patrick Steger und ich die bestehende Pipeline um Secret Detection — eine Zeile YAML — und schauen dann ehrlich hin: Was findet GitLeaks tatsächlich, was übersieht es still, und was tun wir damit?
Wofür Secret Detection da ist#
Secret Detection scannt alle Source- und Konfigurationsdateien, die du ins Git-Repository committet hast, und sucht nach Dingen, die dort nichts verloren haben: Passwörter, API-Keys, Tokens — alles, was du als vertraulich betrachtest. Wenn etwas gefunden wird, “behebst” du das nicht, indem du die Datei änderst. Sobald ein Secret im Repo liegt, gilt es als kompromittiert. Die einzige echte Remediation ist, es überall zu widerrufen und zu rotieren. Die GitLab-Implementierung baut auf dem Open-Source-Projekt GitLeaks auf.
Patrick stellt die naheliegende Folgefrage: Wenn Secrets nicht in den Source Code gehören, wo dann hin? In einen externen Secret Store. GitLab unterstützt dafür HashiCorp Vault — den Vault musst du allerdings selbst hosten und betreiben. Eine integrierte, sichere Ablage für Secrets bietet GitLab aktuell nicht.
Eine Zeile YAML#
Secret Detection einzubinden funktioniert nach demselben Muster wie bei den vorherigen Tools: das GitLab-Template inkludieren. Wir öffnen .gitlab-ci.yml im Web-Editor und ergänzen das Template Secret-Detection.gitlab-ci.yml. Commit, GitLab startet die Pipeline, alles bleibt grün, und in der Pipeline-Übersicht erscheint ein neuer secret_detection-Job.
“Es hat nichts gefunden”#
Der erste Lauf von GitLeaks meldet null Funde. Das ist verdächtig, denn in der vorherigen SAST-Session hatten wir auf den Zeilen 19 und 20 des Controllers absichtlich hardcodierte Passwörter eingebaut. Die müssten doch auftauchen.
Tun sie aber nicht. Schaut man in die GitLeaks-Pattern-Datei, ist die Regex für “password” sehr spezifisch — sie matcht zum Beispiel nur Kleinbuchstaben. Ob das ein Bug oder Absicht ist: Die Konsequenz ist, dass gewöhnliche Password-Literale im Code nicht erkannt werden.
Wenn Secret Detection schon offensichtliche Passwörter übersieht — wozu dann das Ganze? Weil SAST sie ohnehin findet. Im Vulnerability Report nach SAST gefiltert, taucht dasselbe hardcodierte Passwort sofort auf. Secret Detection und SAST überlappen sich, und das ist gut so. Sie decken unterschiedliche Patterns ab.
Worin Secret Detection wirklich gut ist#
Der eigentliche Wert von Secret Detection ist die kuratierte Liste bekannter Secret-Formate: AWS Access Tokens, Cloud-Provider-Keys und Dutzende anderer Tokens mit klar definierter Struktur. Zum Beweis ergänze ich im Controller einen AWS-Style Access Key und committe. Die Pipeline läuft, der secret_detection-Job öffnet sich, und der Fund ist da: ein AWS Access Token, das widerrufen werden sollte.
Den Fund sieht man in der GitLab UI an zwei Stellen: im Security-Tab des Pipeline-Laufs (gefiltert nach Secret Detection) und im Security & Compliance → Vulnerability Report. Der Report zeigt Datei und Zeile — in unserem Fall Zeile 22 — und dass dort der Access Key entdeckt wurde.
Warum die ID gemeldet wird, nicht der Secret-Wert#
Patrick weist auf einen feinen Punkt hin: Das Tool meldet die AWS-Access-Key-ID, nicht den Secret-Wert daneben. Das liegt daran, dass die ID eine wohldefinierte Struktur hat, auf die GitLeaks matchen kann. Der Secret-Wert selbst ist zufällig — dafür gibt es kein Pattern. GitLeaks markiert die ID also als Hinweis darauf, dass in der Nähe wahrscheinlich ein Credential liegt, und überlässt es dir zu entscheiden, ob auch der Wert exponiert ist oder ob er sicher aus einem Vault gezogen wird.
Genau deshalb produziert Secret Detection auch False Positives. Wenn dein Code ein Credential sicher aus einem Vault holt, der Variablenname oder das umgebende Code-Stück aber einem bekannten Pattern entspricht, markiert GitLeaks das trotzdem. Plane das ein — ein realer Secret-Detection-Workflow umfasst Triage, das Markieren von False Positives und das Tracking der echten Funde im Vulnerability Management. Diesen Workflow zeigen wir in einer späteren Session.
Key Takeaways#
Eine Zeile YAML aktiviert Secret Detection. Das Template
Secret-Detection.gitlab-ci.ymlzu inkludieren ist alles. Die Kosten dafür sind praktisch null — keine Ausrede, es nicht einzuschalten.GitLeaks ist Pattern-basiert, und die Patterns sind konservativ. Hardcodierte Passwörter im eigenen Code rutschen durch. Verlass dich nicht allein auf Secret Detection — sorg dafür, dass SAST läuft, damit du überlappende Coverage hast.
Secret Detection ist stark bei wohlbekannten Token-Formaten. AWS Access Keys, Cloud-Provider-Tokens, strukturierte Credentials — alles mit vorhersagbarer Form. Hier verdient das Tool sein Geld.
Ein gefundenes Secret ist ein kompromittiertes Secret. Du flickst es nicht aus der Datei. Du widerrufst es im Zielsystem und rotierst es überall. Diesen Response-Prozess solltest du definieren, bevor der erste Fund kommt.
GitLab gibt dir den Scanner, nicht den Vault. Secrets gehören in einen externen Store wie HashiCorp Vault. GitLab unterstützt Vault, aber Hosting und Betrieb übernimmst du selbst. Eine integrierte sichere Secret-Ablage gibt es noch nicht.
Mit False Positives rechnen — Triage einplanen. Pattern Matching markiert alles, was nach einem Credential aussieht, einschliesslich legitimer Vault-Referenzen. Definier vor dem Rollout, wer Funde reviewt, wie sie markiert und wie sie verwaltet werden.