Der Stand der Secrets: Warum 2025 28 Millionen Zugangsdaten auf GitHub geleakt wurden – und was Sie dagegen tun können

„Wie verwaltet Ihr Unternehmen API-Schlüssel?“

Diese Frage wurde der Entwickler-Community auf Hacker News gestellt. Eine der am höchsten bewerteten Antworten lautete schlicht: „schlecht.“

Die Daten bestätigen das: Der Bericht „2026 State of Secrets Sprawl“ von GitGuardian ergab, dass allein 2025 28,65 Millionen neue hartcodierte Secrets zu öffentlichen GitHub-Repositories hinzugefügt wurden – ein Anstieg von 34 % gegenüber dem Vorjahr. Der Sicherheitsbericht von GitHub selbst zählte 39 Millionen Secret-Leaks im Jahr 2024. Eine auf der IEEE S\&P 2025 veröffentlichte wissenschaftliche Studie, die über 80 Millionen Dateien analysierte, kam zu dem Ergebnis, dass bis zu 30 % der Projekte gefährdet sind.

Dieses Muster zeigt sich bei allen Erfahrungsstufen und Unternehmensgrößen. Wir sehen uns die rechtlichen und finanziellen Folgen an, die auf solche Zugangsdatendiebstähle folgten.

Dieser umfassende Leitfaden erklärt, warum Zugangsdaten geleakt werden, welche Tools Leaks erkennen und verhindern können und wie Sie eine praktische, mehrschichtige Verteidigung aufbauen. Ganz gleich, ob Sie als Entwickler allein Ihre .env-Dateien bereinigen oder als Sicherheitsteam Scans im gesamten Unternehmen einführen möchten – hier finden Sie hilfreiche Informationen.

Was gilt als „Secret“?

Ein Secret ist jede Art von Daten, die Zugriff auf ein System oder eine Ressource gewährt. Zu den offensichtlichen Beispielen zählen API-Schlüssel, Datenbankpasswörter und private SSH-Schlüssel. Die Definition hat sich jedoch erheblich erweitert:

• Cloud-IAM-Zugangsdaten (AWS-Zugriffsschlüssel, JSON-Dateien für GCP-Dienstkonten, Azure-Client-Secrets)

• OAuth-Tokens und Refresh-Tokens

• Webhook-URLs (die häufig eingebettete Authentifizierungsdaten enthalten)

• Verbindungszeichenfolgen (Datenbank, Nachrichtenwarteschlange, Cache)

• Verschlüsselungsschlüssel und Signaturzertifikate

• API-Schlüssel für KI-Dienste (OpenAI, Anthropic, Hugging Face, DeepSeek)

• Konfigurations-Tokens für MCP-Server (eine rasant wachsende Kategorie, mehr dazu weiter unten)

Das OWASP Secrets Management Cheat Sheet bietet eine umfassende Taxonomie. Entscheidend ist: Alles, womit sich eine Maschine authentifiziert, ist ein Secret. Und moderne Anwendungen umfassen zahlreiche Maschinen, die miteinander kommunizieren.

Wie Secrets geleakt werden

Zu verstehen, wie Secrets offengelegt werden, ist der erste Schritt, um dies zu verhindern. Auf Grundlage von Community-Diskussionen, wissenschaftlicher Forschung und Branchendaten sind dies die häufigsten Wege.

Versehentliche Commits

Dies ist das häufigste Szenario: Ein Entwickler fügt während der Entwicklung Zugangsdaten zum Quellcode hinzu („nur zum Testen“) und committet die Datei ins Versionskontrollsystem. Selbst wenn das Secret in einem späteren Commit entfernt wird, bleibt es dauerhaft im Git-Verlauf erhalten. Das Append-only-Datenmodell von Git bedeutet, dass ein git rm tatsächlich nichts entfernt. Angreifer können den vollständigen Verlauf öffentlicher Repositories scannen – und tun dies auch.

Ein Praxisbeispiel aus einem Thread auf r/aws: Ein Team hatte IAM-Zugriffsschlüssel mit vollständigen S3-Berechtigungen zum Delete direkt in JavaScript für das Frontend eingebettet. Unbekannte Angreifer löschten innerhalb weniger Tage die S3-Buckets.

Das Problem mit .env-Dateien

.env-Dateien sind eine praktische Hilfe bei der Entwicklung, werden aber häufig fälschlicherweise als Sicherheitsgrenze verstanden. Dafür waren sie nie gedacht. Die Risiken sind gut dokumentiert:

• .env-Dateien werden versehentlich committet, wenn Entwickler git add . verwenden, anstatt Dateien einzeln hinzuzufügen

• Sie werden über Slack-Nachrichten, Screenshots oder Notiz-Apps geteilt oder zur Unterstützung beim Debuggen in ChatGPT eingefügt

• Durch unbedachte COPY . .-Direktiven werden sie in Docker-Images eingebaut

Der SnykSec-Kanal von Snyk hat sich ausführlich mit diesem Thema befasst:

Play Video: YouTube Video: pcbRwwaCPUg

Warum Secrets nicht in .env-Dateien gehören. Zeigt praktische Alternativen mit Doppler und der 1Password CLI, um Secrets zur Laufzeit einzubinden.

Im Video werden Supply-Chain-Angriffe erläutert, die gezielt auf .env-Dateien abzielen (kompromittierte NPM-Pakete wie tinyColor und ngx-bootstrap). Anschließend wird gezeigt, wie Sie statische .env-Dateien durch das Einbinden von Secrets zur Laufzeit mit Doppler und dem Befehl op run der 1Password CLI ersetzen können.

Der Supply-Chain-Angriffsvektor

Schädliche Pakete, die Zugangsdaten aus Entwicklungsumgebungen stehlen, sind keine bloße Theorie. Snyk hat mehrere reale Vorfälle verfolgt:

• Der Shai-Hulud-NPM-Wurm war darauf ausgelegt, NPM- und GitHub-Tokens in großem Umfang aufzuspüren und zu exfiltrieren

• Bei der Kompromittierung von tinyColor/ngx-bootstrap wurde Malware zum Diebstahl von Zugangsdaten in Pakete mit Millionen wöchentlicher Downloads eingeschleust

• In einem besonders bemerkenswerten Fall setzten Angreifer TruffleHog selbst als Waffe ein und platzierten es als Payload in einem kompromittierten NPM-Paket (@ctrl/tinycolor, 2,2 Millionen wöchentliche Downloads). Dabei nutzten sie die Scan-Funktionen des Sicherheitstools selbst, um Secrets zu finden und zu exfiltrieren.

Angriffsflächen außerhalb des Codes

Laut Forschung von GitGuardian entstehen 28 % der Vorfälle mit Zugangsdaten vollständig außerhalb von Code-Repositories. Secrets werden geleakt über:

• Slack-Nachrichten (2,4 % der Channels enthalten mindestens ein geleaktes Secret)

• Jira-Tickets (6,1 % legen Zugangsdaten offen, oft in Protokollen von Fehlerberichten)

• Confluence-Seiten (Dokumentation mit Verbindungszeichenfolgen)

• Docker-Hub-Images (in über 10.000 Images wurden eingebettete Zugangsdaten gefunden)

• Plattformen zur Code-Formatierung (Entwickler fügen Code in Online-Formatierer ein)

• arXiv-Preprints (laut Dubniczky et al., 2025 wurden Tausende Cloud-API-Schlüssel in LaTeX-Quelldateien gefunden)

Der Einfluss KI-gestützter Entwicklung

Dies ist der am schnellsten wachsende Angriffsvektor für Leaks. Im Bericht von GitGuardian für 2026 wurde festgestellt, dass bei KI-gestützten Commits in 3,2 % der Fälle Secrets geleakt werden – etwa doppelt so häufig wie im Durchschnitt. Dazu tragen mehrere Faktoren bei:

• KI-Coding-Tools können funktionsfähigen Code mit hartcodierten Zugangsdaten generieren

• Codevervollständigungsfunktionen können Zugangsdaten aus Trainingsdaten memorieren und erneut ausgeben (Huang et al., 2023, 39 Zitate)

• Ein Vorfall aus dem Jahr 2024 enthüllte, dass Cursor (ein KI-Code-Editor) für die Tab-Vervollständigung Inhalte von .env-Dateien an seine Server sendete – selbst wenn die Dateien in .cursorignore aufgeführt waren

• Neuronale Tools zur Codevervollständigung verstehen nicht automatisch, was als Secret gilt.

Zugangsdaten für KI-Dienste sind die am schnellsten wachsende Kategorie geleakter Secrets. 2025 stieg ihre Zahl im Jahresvergleich um 81 %. Zu den am häufigsten geleakten Typen zählen Hugging-Face-Tokens, Azure-OpenAI-Schlüssel und Zugangsdaten für Weights & Biases. Allein 2025 wurden 113.000 DeepSeek-API-Schlüssel erkannt.

Das Problem mit MCP-Zugangsdaten

Wenn Sie mit Model Context Protocol (MCP)-Servern arbeiten, müssen Sie eine neue Angriffsfläche für Zugangsdaten kennen. GitGuardian fand 24.008 eindeutige Secrets in MCP-bezogenen Konfigurationsdateien auf öffentlichem GitHub, von denen 2.117 noch gültig sind.

Die Ursache ist aufschlussreich: In offiziellen MCP-Schnellstartanleitungen sind API-Schlüssel in Konfigurationsbeispielen häufig direkt hartcodiert. Entwickler übernehmen diese Muster, ersetzen die Platzhalter durch ihre tatsächlichen Schlüssel und committen die Konfigurationsdatei. Das MCP-Ökosystem wächst rasant, und dieses Muster verbreitet sich ebenso schnell.

Snyk hat ausführlich über die Absicherung von MCP-Servern und die Risiken der agentischen KI-Entwicklungslandschaft geschrieben. Die Forschung zu schädlichen MCP-Servern und Lecks von Zugangsdaten in Agent-Skills-Ökosystemen liefert weiteren Kontext: Die Tools, mit denen wir KI-Anwendungen entwickeln, werden selbst zu Angriffsvektoren für die Offenlegung von Zugangsdaten.

Play Video: YouTube Video: wIvoefvBpWE

Das Geheimnis sicheren KI-Codes. Wie Snyk sich in KI-Entwicklungsworkflows integrieren lässt, um Sicherheitsprobleme in generiertem Code zu erkennen.

SAST und Secret-Scanning: verwandt, aber nicht dasselbe

Eine der am häufigsten genannten Unklarheiten in Entwickler-Communities ist die Annahme, ein SAST-Tool (Static Application Security Testing) decke auch das Secret-Scanning ab. Es handelt sich um ergänzende, aber getrennte Disziplinen – ein Unterschied, den es zu verstehen lohnt.

SAST-Tools wie Snyk Code analysieren Ihren Quellcode auf Sicherheitslücken, darunter Injection-Schwachstellen, unsichere Deserialisierung, Authentifizierungsumgehungen und ähnliche Probleme auf Code-Ebene. In der Regel scannen sie den Arbeitsbaum (den aktuellen Stand der Dateien).

Spezielle Tools für Secret-Scanning haben einen anderen Umfang: Sie scannen den gesamten Git-Verlauf, einschließlich aller Commits, aller Branches und jeder gelöschten Datei, die noch im Objektspeicher vorhanden ist. Das ist wichtig, weil:

1. Ein in einem Commit hinzugefügtes und im nächsten entferntes Secret weiterhin im Git-Verlauf vorhanden ist

2. Das Zusammenführen von Commits „verwaiste“ Daten nicht beseitigt, die über den SHA-1-Hash zugänglich sind

3. Gelöschte Dateien in .pack-Dateien weiterhin gescannt werden können

4. Ein Bericht zu einem Bug-Bounty-Programm dokumentierte 64.000 US-Dollar, die allein durch das Scannen gelöschter Dateien und verwaister Blobs in öffentlichen Repositories verdient wurden.

In der Praxis profitieren Unternehmen sowohl von SAST für Sicherheitslücken auf Code-Ebene als auch von speziellen Scannern zum Aufspüren offengelegter Zugangsdaten. Sie decken unterschiedliche Risikoflächen ab. Wie ein Praktiker auf r/devsecops es formulierte: „Ein Secret-Scanning-Tool sucht auch im Git-Verlauf nach Secrets. Je nach Größe Ihrer Repositories kann das zeitaufwendig sein.“

Die Landschaft der Secret-Scanning-Tools

Das Open-Source-Ökosystem für Secret-Scanning ist deutlich ausgereifter geworden. So sieht die Landschaft 2026 aus – mit einer ehrlichen Einschätzung der Stärken und Einschränkungen der einzelnen Tools.

TruffleHog

TruffleHog (ca. 25.300 Stars, Go, AGPL-3.0) wurde 2016 von Dylan Ayrey entwickelt und wird inzwischen von Truffle Security Co. gepflegt, die im November 2025 eine Series-B-Finanzierungsrunde über 25 Millionen US-Dollar abschloss.

Ein besonderes Merkmal ist die Live-Verifizierung von Zugangsdaten. Zusätzlich zum Abgleich mit Regex-Regeln kann TruffleHog gefundene Zugangsdaten aktiv anhand von Provider-APIs überprüfen und bestätigen, ob sie noch gültig sind. Dadurch lassen sich falsch positive Ergebnisse deutlich reduzieren. Das Tool umfasst über 800 Erkennungsregeln und eine --only-verified-Option, die Ergebnisse auf nachweislich aktive Zugangsdaten beschränkt.

TruffleHog scannt den Git-Verlauf, S3-Buckets, GitHub-/GitLab-Organisationen (einschließlich Issues, PRs und Kommentaren), Docker-Images, Jira, Confluence, Slack und Syslog. Damit deckt es zahlreiche Bereiche ab, in denen Zugangsdaten auftauchen können.

Einschränkungen: Die AGPL-3.0-Lizenz ist nachweislich ein Hindernis für den Einsatz in Unternehmen; in mehreren Threads auf Hacker News und Reddit wird darauf hingewiesen, dass Rechtsteams sie möglicherweise ablehnen. Bei umfangreichen Scans ist TruffleHog außerdem ressourcenintensiv und langsamer als Alternativen, die ausschließlich Regex verwenden.

Gitleaks

Gitleaks (ca. 25.700 Stars, Go, MIT) zählt zu den am häufigsten verwendeten Open-Source-Scannern für Secrets. Das von Zach Rice entwickelte Tool ermöglicht schnelles, konfigurierbares Scanning mithilfe benutzerdefinierter Regeln auf TOML-Basis.

Gitleaks punktet vor allem mit Geschwindigkeit und Konfigurierbarkeit. Es eignet sich ideal für Pre-Commit-Hooks, bei denen es auf Millisekunden ankommt. Dank der MIT-Lizenz lässt es sich problemlos in Unternehmen einsetzen.

Der Kompromiss sind falsch positive Ergebnisse. Gitleaks verwendet Regex-Abgleiche ohne Live-Verifizierung und markiert daher auch Muster, die wie Secrets aussehen, aber keine sind. Praktiker auf r/devsecops empfehlen immer wieder, Gitleaks zunächst im Baseline-Modus auszuführen und falsch positive Ergebnisse offline anzupassen, bevor Sie es als blockierende Prüfung aktivieren. Die Regel generic-api-key verursacht besonders häufig unnötige Treffer.

Bemerkenswert ist, dass auch Zach Rice (u/Phorcez) diesen Kompromiss eingeräumt hat: „Gitleaks ist leichtgewichtig, schnell und hochgradig konfigurierbar, bietet aber keine Verifizierung. Dafür sollten Sie ein Tool wie TruffleHog oder, noch besser, TruffleHog Enterprise verwenden.“

Weitere erwähnenswerte Scanner

• Nosey Parker (2.300 Stars, Rust, Apache 2.0). Entwickelt von der Pentesting-Firma Praetorian. Verwendet einen Algorithmus zur Zeichenfolgenentropie, der bei der Erkennung allgemeiner Secrets als überlegen gegenüber reinen Regex-Verfahren gilt. Schnell und auf Rust-Basis.

• Kingfisher (876 Sterne, Rust, Apache 2.0). MongoDBs Beitrag von 2025, der eine 2- bis 5-mal höhere Geschwindigkeit als Gitleaks verspricht. Bietet Live-Verifizierung und Mapping des Schadensradius (auf welche Zugriffe hat ein geleakter Schlüssel tatsächlich Zugriff?). Als Fork von Nosey Parker entstanden. Nutzt tree-sitter für sprachsensitiven Kontext. Die Funktion zur Ermittlung des Schadensradius ist wirklich innovativ.

• git-secrets (13.200 Sterne, Shell, Apache 2.0). Der schlanke, Bash-basierte Hook von AWS Labs. Auf AWS-Zugangsdaten spezialisiert und für seinen Anwendungsbereich als „abgeschlossen“ betrachtet.

• ggshield (1.900 Sterne, Python, MIT). Die CLI von GitGuardian mit über 500 Geheimnistypen, unterstützt durch eine kommerzielle Plattform. Im März 2026 kamen Hooks für KI-Coding-Assistenten zur Unterstützung von Cursor und Claude hinzu.

• Talisman (2.100 Sterne, Go, MIT). Von ThoughtWorks. Wird als globaler Git-Hook für alle Repos installiert und eignet sich gut für die organisationsweite Durchsetzung.

• ripsecrets (900 Sterne, Rust, MIT). Ein fokussierter, schneller Pre-Commit-Hook mit wenigen Fehlalarmen dank konservativer Regeln.

Was akademische Benchmarks zeigen

Forschende der NC State University veröffentlichten die erste rigorose Vergleichsstudie zu Tools zur Erkennung von Geheimnissen auf Basis ihres SecretBench-Datensatzes (97.479 gekennzeichnete Instanzen aus 818 Repositories). Die Ergebnisse sind aufschlussreich:

• Gitleaks: 88 % Recall (am höchsten), 46 % Präzision

• GitHub Secret Scanner: 75 % Präzision (am höchsten), geringerer Recall

• TruffleHog: 52 % Recall, mittlere Präzision

• Überschneidung zwischen Tools: Nur 76 % zwischen den echten Treffern von ggshield und TruffleHog. Nur 18 % zwischen ggshield und Gitleaks.

Das Forschungsteam empfiehlt ausdrücklich, mehrere Tools miteinander zu kombinieren, da keines der untersuchten Tools alle Arten von Geheimnissen erkannte. Diese Daten sprechen für einen mehrschichtigen Ansatz.

Der neue LLM-basierte Ansatz

FuzzingLabs verglich die LLM-basierte Erkennung von Geheimnissen mit herkömmlichen Tools anhand realer Codebasen. Die Ergebnisse: GPT-5-mini erreichte einen Recall von 84,4 % gegenüber 37,5 % bei Gitleaks. Akademische Forschung bestätigt diesen Trend: Feinabgestimmte Open-Source-Modelle (LLaMA-3.1 8B, Mistral-7B) erzielten F1-Werte von 0,985 auf dem SecretBench-Datensatz.

LLMs erkennen Muster, die Regex-basierte Tools oft übersehen, etwa aufgeteilte Geheimnisse (bei denen ein Schlüssel über mehrere Variablen hinweg zusammengesetzt wird), verschleierte Tokens, dekodierte Variablen und auskommentierte Zugangsdaten. Das dürfte die nächste Generation von Erkennungstools prägen.

Ein Hinweis für Open-Source-Maintainer

Viele der in diesem Artikel besprochenen Tools sind selbst Open-Source-Projekte, und das Ökosystem für das Management von Zugangsdaten wächst stetig. Wenn Sie ein Open-Source-Projekt in diesem Bereich (oder einem anderen) betreuen, bietet das Snyk Secure Developer Program qualifizierenden Open-Source-Projekten kostenlose Sicherheitsprüfungen auf Enterprise-Niveau, darunter SAST-, SCA-, Container- und IaC-Scans. So lässt sich dieselbe Art von mehrschichtiger Sicherheit, über die wir hier sprechen, auch auf die Tools selbst anwenden.

Tools für das Secrets Management: Wo sollten Geheimnisse gespeichert werden?

Die Erkennung geleakter Geheimnisse deckt einen Teil des Problems ab. Der andere besteht darin, dafür zu sorgen, dass Geheimnisse von Anfang an sicher gespeichert und verteilt werden.

HashiCorp Vault

Vault (35.300 Sterne) gilt weiterhin als Enterprise-Standard für Secrets Management. Besonders hervorzuheben sind dynamische Geheimnisse, die bei Bedarf kurzlebige Zugangsdaten erzeugen, statt langfristig gültige zu speichern. Vault übernimmt außerdem Verschlüsselung als Dienst, PKI und die Signierung von SSH-Zertifikaten.

Zwei wichtige Aspekte zum Kontext: Vault wechselte 2023 seine Lizenz von MPL zu BSL 1.1, was das Interesse am Community-Fork OpenBao weckte. Außerdem übernahm IBM HashiCorp für rund 6,4 Milliarden US-Dollar, wodurch Vault Teil der IBM-Plattform wurde.

Praktiker weisen darauf hin, dass Vault leistungsstark, aber komplex ist. Eine aufschlussreiche Beobachtung aus r/devops: „Rund zwei Drittel der Kunden, die [Vault] selbst implementiert haben, haben es falsch gemacht und betreiben tatsächlich ein Secrets Management, das genauso unsicher oder sogar unsicherer ist, als wenn sie gar nichts verwenden würden.“ Vault funktioniert am besten, wenn es als Infrastrukturthema mit dediziertem Operations-Support behandelt wird.

Infisical

Infisical (25.600 Sterne, MIT) ist die am schnellsten wachsende Open-Source-Plattform für Secrets Management. Sie führt Secrets Management, Secret Scanning und PKI in einem einzigen Produkt zusammen und veröffentlicht täglich neue Versionen. YC W23. Selbst gehostet oder in der Cloud.

Seit Vaults Wechsel zur BSL-Lizenz zeigen Community-Diskussionen ein wachsendes Interesse an Alternativen mit MIT-Lizenz. Infisical bietet Enterprise-Funktionen (RBAC, Audit-Logs, Umgebungstrennung, Kubernetes-Operator) und bleibt dabei Open Source. In Community-Diskussionen von 2024 bis 2025 wird es häufig neben Vault und Doppler genannt.

SOPS

SOPS (21.300 Sterne, MPL 2.0) verfolgt einen anderen Ansatz: Es verschlüsselt Geheimnisse direkt in YAML-, JSON- oder ENV-Dateien und speichert die verschlüsselten Dateien in Git. Schlüssel bleiben lesbar (wichtig für Diffs und Linting), während Werte mit AWS KMS, GCP KMS, Azure Key Vault oder age verschlüsselt werden.

SOPS wird in Diskussionen über GitOps-Workflows häufig erwähnt und in Threads wie „Wie verwalten Sie Geheimnisse?“ oft empfohlen. In Verbindung mit direnv für die lokale Entwicklung ist es ein praktischer Ansatz für Teams, die Geheimnisse sicher in der Versionsverwaltung ablegen möchten.

Weitere Tools für das Management

• Doppler: Ein kommerzielles SaaS, das in aktuellen Community-Threads häufig empfohlen wird. Secrets Management ohne eigene Infrastruktur und mit getrennter Verwaltung der Umgebungen.

• 1Password CLI (op run): Fügt Geheimnisse zur Laufzeit ein, ohne sie auf die Festplatte zu schreiben. Die biometrische Authentifizierung (Touch-ID-Abfrage vor dem Einfügen eines Geheimnisses) ist eine deutliche Sicherheitsverbesserung gegenüber statischen Dateien.

• dotenvx (5.300 Sterne): Vom Entwickler des ursprünglichen dotenv. Verschlüsselte .env.vault-Dateien verbinden einfache Entwicklungsmuster mit professionellem Secrets Management.

• External Secrets Operator (6.500 Sterne): Der De-facto-Kubernetes-Standard für die Synchronisierung von Geheimnissen aus über 30 externen Backends.

Mehrschichtige Abwehr aufbauen: Der praktische Leitfaden

Kein einzelnes Tool und keine einzelne Maßnahme kann alle Leaks von Zugangsdaten verhindern. Der branchenweite Konsens, der sich in Reddit, Hacker News, OWASP und der akademischen Forschung zeigt, spricht für eine mehrschichtige Abwehr:

Ebene 1: Pre-Commit-Hooks (vor dem Commit erkennen)

Installieren Sie ein Tool zum Scannen von Geheimnissen (etwa Gitleaks, ggshield oder TruffleHog) als Pre-Commit-Hook. So erhalten Sie besonders schnell Feedback und erkennen die meisten versehentlichen Commits.

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.30.1
    hooks:
      - id: gitleaks

Wichtig: Clientseitige Pre-Commit-Hooks lassen sich umgehen (--no-verify). Für eine strengere Durchsetzung sollten Sie serverseitige Pre-Receive-Hooks implementieren, die Pushes mit Geheimnissen auf Repository-Ebene blockieren.

Wenn Sie Scans zum ersten Mal einführen, verwenden Sie den Baseline-Modus: Scannen Sie den gesamten Verlauf des Repos, bestätigen Sie vorhandene Funde und lassen Sie sich künftig nur über neue Geheimnisse benachrichtigen. So verhindern Sie, dass die Ermüdung durch Fehlalarme die Akzeptanz zunichtemacht.

Ebene 2: CI/CD-Scanning (erkennen, was Pre-Commit entgangen ist)

Fügen Sie Ihrer CI-Pipeline einen Scanschritt hinzu. Tools mit Verifizierung von Zugangsdaten (wie das Flag --only-verified von TruffleHog) reduzieren das Rauschen, indem sie prüfen, ob erkannte Zugangsdaten noch aktiv sind:

# Example using TruffleHog
trufflehog git file://. --only-verified --fail

Diese Ebene erkennt Geheimnisse, die Pre-Commit-Hooks umgangen haben (deaktivierte Hooks, Squash-Commits, Force-Pushes, Beiträge aus Forks).

Ebene 3: Zentralisierter Secrets Vault (Lecks an der Quelle verhindern)

Entfernen Sie Geheimnisse vollständig aus .env-Dateien, Umgebungsvariablen und Konfigurationsdateien. Verwenden Sie einen spezialisierten Secrets Manager, der Geheimnisse zur Laufzeit einfügt:

• Unternehmen mit AWS: AWS Secrets Manager oder SSM Parameter Store mit IAM-Rollen

• Multi-Cloud-Umgebungen: Vault, Infisical oder Doppler

• Kubernetes: External Secrets Operator zur Synchronisierung aus Ihrem bevorzugten Vault

• Kleine Teams: SOPS + age für verschlüsselte Konfigurationen oder dotenvx für verschlüsselte .env-Dateien

Der Secrets Manager sollte die einzige verlässliche Quelle sein – und keine zusätzliche Kopie neben Geheimnissen, die weiterhin in .env-Dateien, CI-Variablen und Team-Wikis liegen.

Ebene 4: OIDC für CI/CD (statische Zugangsdaten vollständig abschaffen)

Eine Architekturänderung, die Sie prüfen sollten: statische CI/CD-Zugangsdaten durch föderierte Identitäten auf Basis von OIDC ersetzen.

# GitHub Actions example - no stored AWS credentials
permissions:
  id-token: write
  contents: read

steps:
  - uses: aws-actions/configure-aws-credentials@v4
    with:
      role-to-arn: arn:aws:iam::123456789:role/deploy
      aws-region: us-east-1

Bei diesem Muster wird der OIDC-Provider von GitHub genutzt, um über AssumeRoleWithWebIdentity kurzlebige AWS-Zugangsdaten anzufordern. IAM-Zugriffsschlüssel werden nirgends gespeichert. Der Konsens in der Community auf Hacker News und r/devops ist eindeutig: Statische Zugangsdaten in GitHub Secrets gelten inzwischen als Anti-Pattern.

Play Video: YouTube Video: 5xngh29yx9A

Ebene 5: Regelmäßige Scans des gesamten Verlaufs (alte Lecks finden)

Planen Sie regelmäßige Scans des gesamten Repository-Verlaufs Ihrer Organisation ein. Damit erkennen Sie:

• Geheimnisse, die vor der Einführung von Scans committet wurden

• Geheimnisse in gelöschten Commits und verwaisten Git-Objekten

• Alte Repos, die von privat auf öffentlich umgestellt wurden

Mehrere Tools unterstützen organisationsweite Scans. TruffleHog kann zum Beispiel eine ganze GitHub-Organisation scannen:

trufflehog github --org=your-org --only-verified

Ebene 6: Token-Format gestalten (Geheimnisse eindeutig erkennbar machen)

Wenn Sie APIs entwickeln, gestalten Sie Ihre Tokens so, dass sie sich eindeutig erkennen lassen. GitHubs Neugestaltung des Token-Formats von 2021 (mit bekannten Präfixen wie ghp_ und eingebetteten Prüfsummen) verbesserte die Scan-Genauigkeit deutlich. Stripes Präfix sk_live_ ist das typische Beispiel.

Selbstidentifizierende Tokens steigern die Wirksamkeit aller Scanning-Tools im Ökosystem. Ein GitHub-PM empfahl ausdrücklich allen Service-Providern, dieses Muster zu übernehmen.

Wenn Geheimnisse leaken: Incident Response

Selbst wenn alle Schutzebenen eingerichtet sind, kommt es zu Lecks. Das Vorgehen im Ernstfall:

1. Sofort rotieren. Diskutieren Sie nicht und untersuchen Sie den Vorfall nicht zuerst. Sperren Sie die Zugangsdaten und stellen Sie neue aus. Automatisierte Erkennungs-Bots scannen die GitHub-API wenige Minuten nach einem öffentlichen Push.

2. Audit-Logs prüfen. Überprüfen Sie CloudTrail, GCP Audit Logs oder vergleichbare Protokolle auf unbefugte Verwendung der offengelegten Zugangsdaten.

3. Schadensradius ermitteln. Auf welche Ressourcen gewährten die Zugangsdaten Zugriff? Auf welche Daten konnte zugegriffen werden?

4. Das Bereinigen des Verlaufs ist zweitrangig. Verwenden Sie git filter-repo oder BFG Repo-Cleaner, um das Geheimnis aus dem Git-Verlauf zu entfernen, falls Compliance-Anforderungen dies verlangen. Durch die Rotation wird das Sicherheitsrisiko beseitigt, während die Bereinigung des Verlaufs Compliance und Ordnung dient. Sobald ein Geheimnis öffentlich ist – und sei es nur für kurze Zeit –, muss es als kompromittiert gelten, unabhängig davon, ob der Verlauf bereinigt wird.

Der Konsens unter Praktikern auf r/devsecops: Rotieren Sie das Geheimnis (damit der Verlauf harmlos wird) und bereinigen Sie den Verlauf nur, wenn Compliance-Anforderungen es verlangen. Manche Unternehmen lassen die rotierten Zugangsdaten sogar als Honeypot-Indikator im Verlauf stehen.

Die rechtliche Realität: Lecks bei Zugangsdaten haben Folgen

Die Rechtslage rund um die Sicherheit von Zugangsdaten hat sich erheblich verändert. Diese Fälle zeigen, warum das Management von Zugangsdaten geschäftskritisch ist:

United States v. Sullivan (9th Cir. 2025). Der Chief Security Officer von Uber wurde wegen Behinderung der Justiz und Verschweigens einer Straftat strafrechtlich verurteilt, weil er einen Sicherheitsverstoß vertuscht hatte, der durch fest im Code hinterlegte AWS-Zugangsdaten in GitHub-Repositories verursacht wurde. Angreifer fanden die Zugangsdaten und griffen auf S3-Speicher mit Daten von 57 Millionen Nutzern zu. Sullivans Team zahlte ihnen 100.000 US-Dollar über das Bug-Bounty-Programm, ohne den Sicherheitsverstoß offenzulegen. Der 9th Circuit bestätigte die Verurteilung und schuf damit einen Präzedenzfall: Führungskräfte können für die Vertuschung von Sicherheitsverstößen durch kompromittierte Zugangsdaten persönlich strafrechtlich haftbar gemacht werden.

Capital One (2022). Ein ehemaliger AWS-Ingenieur nutzte eine SSRF-Schwachstelle aus, um Cloud-IAM-Metadaten-Zugangsdaten zu stehlen und so auf Daten von rund 100 Millionen Kunden zuzugreifen. Der daraus entstandene zivilrechtliche Sammelklagevergleich belief sich auf 190 Millionen US-Dollar.

Durchsetzung durch die FTC. Seit FTC v. Wyndham (3d Cir. 2015) (73 Zitate) verlangen Vergleiche mit der FTC routinemäßig verpflichtende Programme zur Rotation von Zugangsdaten, das Scannen von Code-Repositories nach Secrets und ein Verbot, Zugangsdaten im Quellcode fest zu hinterlegen. Die FTC hat mit Uber, Meta und anderen Unternehmen Vergleiche wegen Sicherheitsmängeln beim Schutz von Zugangsdaten geschlossen.

SEC v. SolarWinds (S.D.N.Y., 2023). Die SEC erhob Anklage mit dem Vorwurf, SolarWinds habe Anlegern gegenüber seine tatsächlichen Praktiken zum Secrets-Management falsch dargestellt. Die zentralen Vorwürfe überstanden die teilweise Abweisung und weiteten die Haftung bei Sicherheitsverletzungen auf das Wertpapierrecht aus.

Der Equifax-Datenschutzverstoß, der auf Mängel bei Zugangsdaten und Zugriffskontrollen zurückzuführen war, führte zu einem Vergleich über 700 Millionen US-Dollar mit der FTC – dem größten Vergleich wegen Datensicherheit in der Geschichte der FTC.

6 zentrale Grundsätze

Diese Erkenntnisse stammen von OWASP, aus der akademischen Forschung und aus Diskussionen unter Praktikern:

1. Private Repositories enthalten mehr Secrets als öffentliche. GitGuardian stellte fest, dass private Repositories sechsmal häufiger fest hinterlegte Secrets enthalten als öffentliche. Private Repositories werden geklont, geforkt, von Auftragnehmern aufgerufen und gelegentlich öffentlich gemacht.

2. Commits mit Secrets bleiben im Git-Verlauf erhalten. Selbst wenn sie im nächsten Commit gelöscht werden oder das Repository privat ist. Das Append-only-Datenmodell von Git bedeutet, dass jedes committete Zugangsdaten als offengelegt gelten sollte.

3. Der Erkennungsumfang der Tools variiert. Akademische Benchmarks zeigen, dass sich die Mengen der von den Tools korrekt erkannten Schwachstellen nur zu 18–76 % überschneiden. Der Einsatz mehrerer Tools auf verschiedenen Ebenen erhöht die Abdeckung.

4. Die Rotation von Zugangsdaten mindert das Risiko; das Bereinigen des Verlaufs dient der Compliance. Wird das Zugangsdaten widerrufen, ist der Git-Verlauf unschädlich. Den Verlauf ohne Rotation zu bereinigen, reicht nicht aus.

5. Erkennung allein bringt ohne weitere Maßnahmen nur begrenzten Nutzen. 64 % der 2022 offengelegten Secrets waren 2026 noch aktiv. Unternehmen, die Vorfälle erkennen, aber nicht beheben, tragen dasselbe grundlegende Risiko.

6. Entwicklerarbeitsplätze werden zu einer immer größeren Angriffsfläche. Supply-Chain-Angriffe, KI-Coding-Tools mit Dateizugriff und Prompt-Injection-Angriffe auf MCP-Server schaffen allesamt Wege, Zugangsdaten von lokalen Rechnern abzugreifen. Die Forschung von Snyk zu als Waffen eingesetzten KI-Coding-Agenten beleuchtet diese neue Angriffsfläche.

Erste Schritte

Die oben beschriebene mehrschichtige Verteidigung kann auf einmal überwältigend wirken. Die gute Nachricht: Jede Ebene bietet für sich genommen einen Mehrwert, und Sie können sie schrittweise einführen.

• Beginnen Sie mit Transparenz – Bevor Sie Lecks bei Zugangsdaten beheben können, müssen Sie wissen, wo sie auftreten. Fügen Sie einen Pre-Commit-Scan-Hook hinzu (Tools wie Gitleaks, ggshield und TruffleHog unterstützen dies), um neue Lecks zu erkennen. Führen Sie anschließend einen organisationsweiten Scan mit Überprüfung der Zugangsdaten durch, um Ihre aktuelle Gefährdung zu ermitteln. Wenn Sie bereits Snyk Code für SAST einsetzen, decken Sie mit einem ergänzenden, spezialisierten Secrets-Scan sowohl Schwachstellen im Code als auch offengelegte Zugangsdaten ab.

• Prüfen Sie Ihre .env -Dateien und CI/CD-Secrets – Stellen Sie fest, ob echte Zugangsdaten in der Versionsverwaltung liegen – auch in privaten Repositories. Rotieren Sie alle committeten Zugangsdaten. Prüfen Sie Ihre CI/CD-Pipelines auf statische Zugangsdaten, die sich durch föderierte Identitäten auf Basis von OIDC ersetzen lassen.

• Bewerten Sie Ihren Ansatz für das Secrets-Management. – Wenn Ihr Team Zugangsdaten noch über .env-Dateien weitergibt oder Umgebungsvariablen manuell setzt, prüfen Sie zentrale Lösungen wie Infisical, Vault oder Doppler, die Secrets zur Laufzeit bereitstellen.

• Sichern Sie Ihre KI-Entwicklungsabläufe ab – Wenn Ihr Team KI-Coding-Assistenten oder MCP-Server verwendet, prüfen Sie deren Konfiguration auf fest hinterlegte Zugangsdaten. Die MCP-Server-Integration von Snyk kann KI-generierten Code in Echtzeit scannen, und Snyk Open Source hilft dabei, kompromittierte Abhängigkeiten zu erkennen, bevor sie in Ihre Codebasis gelangen (derselbe Supply-Chain-Angriffsweg, über den Malware zum Diebstahl von Zugangsdaten verbreitet wird).

• Schaffen Sie ein organisationsweites Bewusstsein – Sowohl Tools als auch Teampraktiken tragen zu einem wirksamen Umgang mit Zugangsdaten bei. Die Developer-Security-Plattform von Snyk integriert SAST, SCA, Containersicherheit und IaC-Scans in Entwickler-Workflows und bietet Teams einen einheitlichen Überblick über ihre Sicherheitslage. Wenn Entwickler Sicherheitsprobleme dort sehen, wo sie ohnehin arbeiten, setzt sich die Nutzung ganz natürlich durch.

Die meistgewählte Antwort auf HN war ehrlich. Viele Unternehmen gehen schlecht mit ihren Zugangsdaten um. Doch die Tools, Praktiken und das Wissen aus der Community, um es besser zu machen, waren noch nie so leicht zugänglich.

Sind Ihre Python-Anwendungen auf den Anstieg KI-gestützter Secret-Lecks und die oben beschriebenen Risiken offengelegter Zugangsdaten vorbereitet? Laden Sie das Whitepaper Die KI-Sicherheitskrise in Ihrer Python-Umgebung herunter und erfahren Sie, wie führende Teams KI-gestützte Entwicklungsabläufe absichern.