Zurück zur Startseite

Geleakte API-Keys in Git-Repositories erkennen und beheben

Veröffentlicht am 6. April 2026 · Lesezeit ca. 6 Minuten

Dr. Alexander Krause
Dr. Alexander Krause IT-Sicherheitsberater & Forscher am CISPA Helmholtz-Zentrum

API-Keys, Passwörter, kryptographische Schlüssel — sie landen regelmäßig in Git-Repositories. Meist unbemerkt. Und dort bleiben sie, abrufbar für jeden mit Zugriff auf die Historie. Dieser Artikel zeigt, wie Sie geleakte Secrets aufspüren, richtig reagieren und Leaks künftig verhindern. Die Empfehlungen stützen sich auf eine Studie mit 24 Interviews und einer Befragung von 365 Entwicklern, vorgestellt auf der USENIX Security 2023 (Krause et al.).

Was sind Code Secrets — und wie gelangen sie ins Repository?

Code Secrets sind Zugangsdaten im Quellcode oder in Konfigurationsdateien: API-Keys, Datenbankpasswörter, OAuth-Tokens, SSH-Schlüssel, Private Keys, Cloud-Credentials wie AWS Access Keys. Sie haben alle eines gemeinsam: Wer sie hat, hat Zugriff.

Wie sie ins Repository gelangen, ist fast immer banal. Ein .env-File ohne .gitignore-Eintrag. Ein Tutorial-Credential, das versehentlich durch ein echtes ersetzt wurde. Ein für lokale Tests eingefügtes Passwort, das niemand mehr entfernt hat. Kein böser Wille — einfach Alltag in der Softwareentwicklung.

Die Studie bestätigt: Die meisten Entwickler kennen das Risiko. Was fehlt, sind systematische Prozesse. Statt automatisierter Tools verlassen sich viele auf manuelle Reviews und Ad-hoc-Checks.

Wie konnten 39 Millionen Secrets in einem Jahr leaken?

GitHub hat 2024 über 39 Millionen Secrets in Repositories entdeckt. Pro Tag scannen die großen Plattformen Millionen von Commits — und finden ständig exponierte Zugangsdaten.

Was passiert nach einem Leak? Das hängt vom Secret ab. Ein Telemetrie-Key ist ärgerlich. Ein Datenbankpasswort mit Zugriff auf Kundendaten löst DSGVO-Meldepflichten aus. Geleakte Cloud-Credentials können innerhalb von Minuten fünfstellige Kosten verursachen — Crypto-Mining auf fremde Rechnung ist ein beliebtes Geschäftsmodell. Und kompromittierte CI/CD-Tokens? Die öffnen die Tür für Supply-Chain-Angriffe.

In unserer Befragung gab ein erheblicher Anteil der 365 Entwickler an, selbst schon Secrets committet zu haben — oder Fälle im Team miterlebt zu haben. Viele unterschätzen, wie oft das vorkommt.

Warum schlagen automatisierte Scanner manuelle Reviews?

Wer geleakte Secrets finden will, braucht Werkzeuge. Manuelles Durchsuchen reicht nicht — das zeigen auch die Studienergebnisse. Zum Zeitpunkt der Erhebung setzten die wenigsten Entwickler automatisierte Scanner ein, obwohl deren Trefferquote deutlich besser ist.

Automatisierte Scanner

  • git-secrets (AWS): Prüft Commits, Messages und Merges auf verbotene Muster.
  • TruffleHog: Durchsucht die gesamte Git-Historie nach hochentropischen Strings und bekannten Formaten.
  • GitHub Secret Scanning: Prüft automatisch gegen 200+ Token-Formate und benachrichtigt den Anbieter.
  • GitGuardian: Kommerzielles Echtzeit-Monitoring.
  • Gitleaks: Open Source, gut integrierbar in CI/CD-Pipelines.

Pre-Commit Hooks

Der beste Zeitpunkt, ein Secret abzufangen, ist bevor es in die Historie gelangt. Pre-Commit Hooks mit git-secrets, gitleaks oder dem pre-commit Framework machen genau das.

Code Reviews

Ergänzend — nicht als Ersatz. Reviewer sollten gezielt auf hartcodierte Credentials und verdächtige Strings achten, aber sich nicht darauf verlassen, jeden Leak zu entdecken.

Warum reicht Löschen nach einem Leak nicht aus?

Ein häufiger Fehler: Die Datei mit dem Secret wird gelöscht und ein neuer Commit erstellt. Problem erledigt? Nein. Das Secret steckt weiterhin in der Git-Historie und bleibt dort abrufbar.

Sofortmaßnahmen

  1. Secret sofort revoken. Beim Anbieter den Key deaktivieren oder rotieren. Das ist der dringendste Schritt — alles andere kann warten.
  2. Neues Secret erzeugen und sicher hinterlegen (Secret Manager, nicht Slack-Nachricht).
  3. Zugriffslogdateien prüfen: Wurde das Secret bereits missbraucht?

Die Studie hat gezeigt, dass viele Entwickler nach einem Leak lediglich die Datei löschen — ohne das Secret selbst zu widerrufen. Das eigentliche Risiko bleibt dann bestehen.

Git-Historie bereinigen

Zwei Tools haben sich etabliert:

  • BFG Repo-Cleaner: Schnell, einfach, entfernt sensible Daten aus der gesamten Historie.
  • git filter-repo: Nachfolger von git filter-branch, für gezielte Entfernung von Dateien oder Textmustern.

Danach müssen alle Teammitglieder ihren Klon neu fetchen. Bei öffentlichen Repositories gilt: Davon ausgehen, dass das Secret kopiert wurde. Revoken ist Pflicht.

Prävention

Secrets raus aus dem Code

Secrets gehören in Umgebungsvariablen oder in einen Secret Manager — nicht in den Quellcode. Gängige Optionen:

  • HashiCorp Vault: Zugriffskontrolle, Audit-Logging, automatische Rotation.
  • AWS Secrets Manager / Azure Key Vault / Google Secret Manager: Cloud-native Lösungen.
  • .env + .gitignore: Für lokale Entwicklung, solange die .env zuverlässig ausgeschlossen wird.

.gitignore richtig konfigurieren

Klingt trivial, wird trotzdem vergessen. .env, *.pem, *.key, credentials.json, *.p12 — alles rein. Templates von github/gitignore nutzen und bei jedem neuen Projekt prüfen.

Pre-Commit Scanning

Secret-Scanner als Pre-Commit Hook einrichten, zusätzlich server-seitige Checks in der CI/CD-Pipeline. Zwei Netze fangen besser als eins.

Sicherheitskultur

Technik allein löst das Problem nicht. Was hilft: regelmäßige Schulungen, klare Richtlinien, Security Champions in den Teams — und eine Kultur, in der das Melden eines Leaks kein Stigma ist. Unsere Studie zeigt: Organisationen mit etablierten Sicherheitsrichtlinien schneiden bei der Prävention deutlich besser ab.

Fazit

Secret Leakage ist kein Randproblem. Vier Punkte:

  1. Vorbeugen statt reagieren. Secret Manager, .gitignore, Pre-Commit Hooks.
  2. Automatisieren. TruffleHog, Gitleaks, GitHub Secret Scanning — nicht auf manuelle Reviews allein verlassen.
  3. Richtig reagieren. Revoken, Git-Historie bereinigen, Ausmaß prüfen. Löschen allein reicht nicht.
  4. Kultur bauen. Tools wirken nur dort, wo Secret Management als Teil der Sicherheitskultur verstanden wird.

Die vollständige Studie: Krause et al., „Pushed by Accident", USENIX Security 2023.

Dieser Artikel ist eine KI-generierte Zusammenfassung der wissenschaftlichen Publikation „Pushed by Accident: A Mixed-Methods Study on Strategies of Handling Secret Information in Source Code Repositories" (USENIX Security 2023). Die Inhalte wurden redaktionell geprüft.

Sie möchten Ihre Entwicklungsprozesse gegen Secret Leakage absichern? Kontaktieren Sie mich für eine individuelle Beratung — von der Analyse Ihrer aktuellen Prozesse bis zur Implementierung automatisierter Schutzmaßnahmen.