Dein Blog zum Thema digitales Business

Ein Token, das einmal committet wurde, ist nicht weg, wenn du es im nächsten Commit löschst. Es steht in der Historie, und die kann jeder auslesen, der Zugriff auf das Repo hat oder bekommt. Wie schnell ein Angreifer genau das findet, haben wir aus der Außensicht beschrieben. Dieser Beitrag dreht den Blick um. Es geht um die Werkzeuge, die verhindern, dass ein Secret überhaupt erst in die Historie kommt.

Was Secret Scanning macht

Secret Scanning durchsucht deinen Code nach Mustern, die nach Zugangsdaten aussehen. AWS-Keys, GitHub-Tokens, Stripe-Schlüssel, private SSH-Keys und dutzende weitere Anbieterformate haben eine erkennbare Struktur. Der Scanner prüft neue Commits und, einmal aktiviert, auch die komplette bestehende Historie. Findet er etwas, bekommst du eine Meldung, oft zusammen mit dem betroffenen Anbieter.

Bei vielen Anbietern geht GitHub noch einen Schritt weiter und informiert den Anbieter selbst. Ein geleakter Stripe-Key kann so automatisch als kompromittiert gemeldet und gesperrt werden, bevor du überhaupt reagierst. Das ist nützlich, ersetzt aber deine eigene Reaktion nicht.

Push Protection: der Schritt davor

Secret Scanning meldet ein Secret, das schon im Repo liegt. Push Protection setzt eine Stufe früher an. Sie prüft den Push, bevor er ankommt, und blockiert ihn, wenn sie ein Secret erkennt. Der Commit landet gar nicht erst auf dem Server, die Historie bleibt sauber.

Der Unterschied ist praktisch groß. Ohne Push Protection ist ein geleaktes Secret ein Vorfall, der Rotation und Aufräumen der Historie nach sich zieht. Mit Push Protection ist es eine Fehlermeldung im Terminal, die der Entwickler in dreißig Sekunden korrigiert. Wer wirklich weiß, dass der Treffer ein Fehlalarm ist, kann den Push mit einer dokumentierten Begründung freigeben. Diese Ausnahme wird protokolliert, das ist Absicht.

Warum das die Rotation nicht ersetzt

Ein Werkzeug, das erst nach dem Push greift, kommt manchmal zu spät. Wenn Secret Scanning einen Key in einem alten Commit findet, war dieser Key unter Umständen monatelang sichtbar. Ihn aus der Historie zu entfernen hilft wenig. Ein Secret, das einmal öffentlich war, gilt als verbrannt. Der einzige saubere Weg ist rotieren. Warum Zugänge grundsätzlich ein Ablaufdatum brauchen, steht in Pipeline-Secrets rotieren.

Die beiden Werkzeuge und die Rotation greifen ineinander. Push Protection verhindert die meisten Leaks. Secret Scanning fängt die, die trotzdem durchkommen oder aus der Vergangenheit stammen. Rotation ist das, was du tust, wenn ein Secret trotz allem draußen war.

Was du konkret aktivierst

• Secret Scanning auf Organisations-Ebene einschalten, nicht Repo für Repo. So gilt es auch für neu angelegte Repos automatisch.
• Push Protection zusätzlich aktivieren. Sie ist der Teil, der aktiv verhindert statt nur meldet.
• Zuständigkeit klären. Ein Alarm, den niemand liest, ist kein Schutz. Lege fest, wer Treffer prüft und wer eine Ausnahme freigeben darf.
• Bei Bedarf eigene Muster ergänzen. Interne Token-Formate erkennt der Standard-Scanner nicht, dafür gibt es benutzerdefinierte Muster.

Grenzen

Secret Scanning erkennt nur, was einem bekannten Muster folgt. Ein Passwort in einer Konfigurationsdatei ohne festes Format rutscht durch. Verschlüsselte oder base64-kodierte Secrets werden nicht zuverlässig gefunden. Die Werkzeuge senken das Risiko deutlich, sie ersetzen aber nicht die Grundregel, Secrets gar nicht erst in den Code zu schreiben, sondern über eine Umgebung oder einen Vault einzuspeisen.

Wenn Sie wissen wollen, ob in Ihren Repos schon Zugangsdaten liegen und ob Push Protection sinnvoll konfiguriert ist, findet der GitSecOps QuickCheck genau das. In drei Werktagen, für 1.990 Euro netto, mit konkreten Befunden statt einer Werkzeugliste. Kontakt: mm@crank.zone.