Credential-Leaks in Repositories verhindern – dank systematischer Absicherung mit GitLab

Nicht ganz neu, aber weiterhin sinnvoll: Best Practices für Secret-Schutz in GitLab-Repositories.

Das GitLab Security Team ist über einen Blogbeitrag von Sysdig informiert, der beschreibt, wie Angreifer öffentliche Repositories scannen, um exponierte Credentials in Git-Config-Dateien zu identifizieren. GitLab empfiehlt seinen Kunden und Nutzern konsequent mehrere Best Practices, um ihre öffentlichen GitLab-Projekte abzusichern und versehentliche Leaks von Credentials in Git-Config-Dateien oder anderswo in öffentlichen Projekten zu verhindern.

Die mehrschichtige Absicherung von Secrets reduziert das Risiko von Credential-Leaks systematisch: Push Protection verhindert Leaks beim Commit, Pipeline-Detection erkennt Secrets vor dem Merge in den Hauptbranch, und Client-seitige Erkennung schützt Beschreibungen in Issues und Merge Requests. Dieser dreistufige Ansatz adressiert verschiedene Eingabepunkte und minimiert die Wahrscheinlichkeit, dass Credentials in öffentlichen Repositories landen. Die Kombination aus präventiven Maßnahmen (Push-Blockierung) und reaktiven Kontrollen (Pipeline-Scanning) bietet umfassenden Schutz gegen versehentliche Credential-Exposition.

1. Öffentliche Sichtbarkeit von GitLab-Gruppen und -Projekten einschränken
   GitLab empfiehlt, die Standard-Sichtbarkeit für neue GitLab-Projekte und -Gruppen standardmäßig auf privat zu setzen. Die Konfiguration der Standard-Sichtbarkeitseinstellungen für Projekte und Gruppen auf privat für die GitLab-Instanz kann helfen, versehentliche Offenlegung von Informationen in einem öffentlichen Projekt zu verhindern, das als privat gedacht war.
2. CI-Secrets absichern
   Secrets, die Schutz erfordern, einschließlich Passwörter und Tokens, sollten niemals im Klartext gespeichert werden. Verschlüsselungs-Container-Technologien (Secrets Manager) sollten genutzt werden, um Secrets sicher zu speichern. Beispiele für Secrets-Manager-Tools sind GCP Secret Manager, AWS KMS und HashiCorp Vault.
3. GitLab Secret Detection nutzen
   GitLab setzt mehrere Secret-Detection-Funktionen ein, um potenzielle Secrets in GitLab-Repositories zu identifizieren, zu blockieren oder Nutzer zu warnen. Secret Detection überwacht Aktivitäten, um Leaks zu verhindern, und ermöglicht eine Reaktion, falls ein Secret geleakt wurde.

Secret-Detection-Methoden aktivieren

Alle verfügbaren GitLab-Secret-Detection-Methoden sollten aktiviert werden:

• Secret Push Protection scannt Commits beim Pushen von Änderungen zu GitLab. Der Push wird blockiert, falls Secrets erkannt werden, es sei denn, Secret Push Protection wird übersprungen. Diese Methode hilft, das Risiko von Secret-Leaks zu reduzieren.
• Pipeline Secret Detection läuft als Teil der CI/CD-Pipeline eines Projekts. Commits zum Default-Branch des Repositories werden auf Secrets gescannt. Falls Pipeline Secret Detection in Merge-Request-Pipelines aktiviert ist, werden Commits zum Development-Branch auf Secrets gescannt, was eine Reaktion ermöglicht, bevor sie in den Default-Branch committet werden.
• Client-seitige Secret Detection scannt Beschreibungen und Kommentare in Issues und Merge Requests auf Secrets, bevor sie in GitLab gespeichert werden. Falls ein Secret erkannt wird, lässt sich die Eingabe bearbeiten und das Secret entfernen, oder falls es sich um ein False-Positive handelt, die Beschreibung oder den Kommentar speichern.

Die systematische Secret-Erkennung unterstützt beispielsweise auch Compliance-Anforderungen: NIS2 Artikel 21.2(h) fordert angemessene Verschlüsselung, und Artikel 21.2(i) verlangt Zugriffskontroll-Richtlinien. Secret Detection verhindert, dass unverschlüsselte Credentials exponiert werden, und dokumentiert Erkennungen für Audit-Trails. Die automatisierte Überwachung reduziert das Risiko menschlicher Fehler bei der Verwaltung sensibler Zugangsdaten.

Vorgehen bei versehentlichem Leak von Credentials

Im Falle einer versehentlichen Secret-Exposition das exponierte Credential zurücksetzen und Zugriffslogs überprüfen, um Hinweise auf Credential-Missbrauch zu identifizieren. Falls das geleakte Secret ein GitLab Personal Access Token oder ein anderer Secret-Token-Typ war, das Token widerrufen und GitLab-Logs überprüfen auf nicht autorisierte Aktivitäten, die mit dem exponierten Token verbunden sind.