API-Key gepusht: die ersten zehn Minuten, in der richtigen Reihenfolge

Du hast git push ausgeführt, dir den Diff auf GitHub angesehen und deinen API-Key im Klartext entdeckt. Der erste Impuls: Commit löschen, Force-Push, bevor es jemand merkt. Fang nicht dort an. Behandle den Key ab dem Moment des Pushs als kompromittiert und verbringe die erste Minute beim Anbieter, nicht in git.

Warum das Löschen des Commits nichts zurückholt

Ein Push kopiert deine Historie an Orte, die du nicht kontrollierst. Wer das Repository geklont oder geforkt hat, hat den Commit. Automatische Scraper beobachten öffentliche Pushes nach allem, was wie ein Key aussieht, und sie sind schnell. Caches und Mirrors können eine Kopie behalten, nachdem du deinen eigenen Branch umgeschrieben hast. Den Commit zu entfernen räumt genau eine Kopie auf, deine, und der Key bleibt überall sonst gültig. Die einzige Maßnahme, die alle Kopien auf einmal wertlos macht, ist das Widerrufen des Keys.

Die Reihenfolge, die den Schaden begrenzt

Das ist eine allgemeine Empfehlung, keine Regel eines bestimmten Anbieters, aber die Reihenfolge zählt mehr als das Tempo jedes einzelnen Schritts.

1. Widerrufe oder rotiere den Key beim Anbieter. Erstelle einen neuen, tausche ihn in deiner deployten Umgebung aus, lösche den alten. Bis das erledigt ist, ist alles andere Kosmetik.

2. Prüfe das Nutzungs- und Abrechnungs-Dashboard des Anbieters auf Aufrufe, die du nicht kennst, ab dem Zeitpunkt des Pushs. Gibt es welche, hast du jetzt einen Vorfall zu melden, nicht nur einen Fehler aufzuräumen.

3. Hol das Secret aus dem Code. In Laravel gehört der Key in die .env, wird über eine Config-Datei eingelesen, und der Code liest ihn mit config():

// config/services.php
'anthropic' => ['key' => env('ANTHROPIC_API_KEY')],

// anywhere in the app
$key = config('services.anthropic.key');

Ruf env() nie außerhalb einer Config-Datei auf. Nach php artisan config:cache, das die meisten Deployments ausführen, liefert env() außerhalb der Config null, und ein Key, der direkt im Controller gelesen wird, landet dann gern fest im Code, „damit es erst mal läuft“. Prüfe, dass .env in der .gitignore steht, und pflege eine .env.example mit Platzhalterwerten, damit niemand die echte Datei braucht, um die App zu starten.

4. Erst dann, wenn du willst, räum die Historie auf, mit git filter-repo oder BFG. Das ist Hygiene, keine Lösung: Es braucht einen Force-Push, alle müssen neu klonen, und an den Kopien aus dem ersten Diagramm ändert es nichts.

5. Verhindere den nächsten. Schalte Secret Scanning und Push Protection ein, ergänze einen Pre-Commit-Scanner und gib jeder Umgebung einen eigenen, eingeschränkten Key mit Ausgabenlimit, damit das nächste Leck klein bleibt. Dann schreib auf, was passiert ist, solange du es noch weißt.

Was GitHub jetzt für dich übernimmt

GitHub hat am 2026-10-13 angekündigt, dass Secret Scanning neue Secret-Typen von Salesforce, Anthropic und Cloudsmith erkennt und dass die beiden neuen Anthropic-Typen, anthropic_service_api_key und anthropic_user_api_key, standardmäßig von Push Protection blockiert werden. Laut GitHub werden in Repositories mit aktiviertem Secret Scanning, kostenlose öffentliche eingeschlossen, Commits mit diesen Keys automatisch blockiert. GitHub schreibt außerdem, dass Partner-Secrets in öffentlichen Repositories an den Aussteller weitergeleitet werden, damit er sie vor einem Missbrauch widerrufen kann, und dass User-Secrets in öffentlichen und privaten Repositories Warnungen auslösen. Dieses Sicherheitsnetz lohnt sich, aber es deckt nur die Typen ab, die GitHub kennt. Rutscht etwas durch, bleibt die Reihenfolge oben deine Aufgabe. Wenn du Secret Scanning in deinen Repositories noch nicht aktiviert hast, tu es heute, und ergänze danach einen Pre-Commit-Scanner, damit der Key deinen Rechner gar nicht erst verlässt.

Quelle: GitHub Changelog, 2026-10-13.