API-Keys, Tokens und Passwörter rutschen nach wie vor regelmässig in Repositories — manchmal aus Versehen, manchmal weil Entwickler es ehrlich nicht besser wussten. In Teil 7 unserer GitHub DevSecOps Serie schalten Patrick Steger und ich GitHubs eingebautes Secret Scanning ein, definieren ein eigenes Pattern, probieren Push Protection aus und schauen offen hin, wo die Funktion liefert und wo sie noch nicht hält, was sie verspricht.
Eingebaut, nicht angeflanscht#
Anders als bei allem, was wir bisher integriert haben, ist Secret Scanning kein separates Tool, das du zu GitHub bringst — es ist Funktionalität, die du in GitHub selbst einschaltest. Die Konfiguration liegt in den Repository-Einstellungen, nicht in einer Workflow-YAML.
Beim Lizenzmodell gibt es einen Haken: Für public Repositories ist Secret Scanning automatisch aktiv und kostenlos — und dort sogar verpflichtend. Für private Repositories brauchst du GitHub Enterprise mit dem Advanced-Security-Add-on. Gut zu wissen, bevor man es organisationsweit plant.
Was gescannt wird und was “gefunden” bedeutet#
Sobald aktiviert, scannt GitHub alle Source- und Konfigurationsdateien im Repository — und die Git-History — auf bekannte Secret-Patterns: API-Keys, Cloud-Tokens, alles, was auf einem der von GitHub gepflegten Patterns matcht. Wenn etwas gefunden wird, ist die einzige sinnvolle Reaktion: widerrufen und rotieren. Ein geleaktes Secret kannst du nicht “ungeleakt” machen, indem du die Datei löschst.
Patrick bringt den Punkt, den ich auch immer mache: In DevOps sagen wir, alles ist Source Code und gehört ins Repository — und genau dort dürfen Secrets nicht hin. Sie gehören an einen Ort, der für sie gebaut ist: in den Secrets-Bereich der Repository-Settings oder in einen externen Store wie Azure Key Vault, den GitHub out of the box unterstützt.
Aktivierung#
Secret Scanning einzuschalten sind ein paar Klicks. Unter Settings → Code security and analysis scrollst du zu GitHub Advanced Security und aktivierst Secret scanning. Wenn wir schon dabei sind, schalten wir auch Push protection ein — das soll Pushes mit neu hinzugefügten Secrets blockieren, bevor sie das Remote überhaupt erreichen.
GitHub scannt zuerst die Repository-History, was eine Weile dauern kann, und meldet Funde an zwei Stellen: im Security-Tab unter Secret scanning sowie per E-Mail an die Personen, die du als Empfänger konfigurierst.
Ein eigenes Pattern definieren#
GitHub bringt eine lange Liste unterstützter Secret-Formate von vielen Partnern mit, du kannst aber auch eigene Patterns hinzufügen. Wir klicken New pattern, geben ihm einen Namen und definieren das Format — bei uns alles, was mit pwd_ beginnt. Das UI lässt dich die Regex zuerst gegen Beispieldaten testen, und du kannst sie als Dry Run speichern, sodass die Ergebnisse ins E-Mail-Postfach gehen, ohne dass die Regel live ist.
Nachdem wir das Pattern publishen, fügen wir ein paar pwd_-Strings im Controller ein und committen. Zurück unter Security → Secret scanning sind beide Test-Secrets markiert. Custom Patterns funktionieren.
“Wo sind die anderen Secrets?”#
Wenn ich die Controller-Datei öffne, an der wir in dieser Serie arbeiten, sind dort noch mehrere hardcodierte Credentials — angezeigt werden aber nur die pwd_-Werte, die wir gerade ergänzt haben. Warum?
Weil der AKIA…-AWS-Identifier, den wir verwenden, nicht in GitHubs vordefinierter Pattern-Liste enthalten ist. Azure Storage Account Access Keys hingegen schon. Die Antwort auf “Was findet GitHub?” ist also schlicht: was die vordefinierte Liste plus deine eigenen Patterns abdecken. Alles andere ist für Secret Scanning unsichtbar.
Push Protection ausprobieren#
Um Push Protection zu testen, fügen wir einen Azure Storage Account Access Key und einen weiteren pwd_-Wert ein, committen und pushen. Erwartung: GitHub blockiert den Push, bevor er ankommt.
Tut es nicht. Der Commit landet im Repository. Wir recherchieren — und finden in GitHubs Doku den Grund: Zum Zeitpunkt der Aufnahme war Push Protection noch Beta, und obwohl der Toggle im UI vorhanden ist, hat sie schlicht noch nicht durchgesetzt. Die gute Nachricht: Secret Scanning erkennt beide Secrets im Nachgang. Im Security → Secret scanning-Tab stehen sie inklusive Hinweis, dass die Credentials kompromittiert sind und rotiert werden müssen. Den Azure Key haben wir natürlich anschliessend widerrufen.
Key Takeaways#
Secret Scanning ist ein Setting, kein Tool, das du installierst. Toggle in Settings → Code security and analysis. Keine Workflow-Datei, keine Marketplace-Action.
Public gratis, private kostenpflichtig. Public Repositories bekommen Secret Scanning automatisch. Private brauchen GitHub Enterprise mit Advanced Security. Das gehört in die Plattform-Planung.
Custom Patterns sind mächtig und einfach. Wenn GitHub kein Pattern für die Credentials deines Stacks mitbringt, definier dein eigenes, dry-run es per Mail, dann publish. Das UI lässt dich die Regex sogar inline testen.
Coverage ist nur so breit wie die Pattern-Liste. GitHub findet, was es kennt. Alles ausserhalb der vordefinierten Liste und deiner Custom Patterns bleibt unsichtbar. Auditiere die unterstützte Liste gegen die Credentials, die dein Code tatsächlich nutzt.
Secrets gehören in den Secrets-Bereich oder einen Key Vault. GitHub bietet einen geschützten Secrets-Bereich in den Repository-Settings und integriert Azure Key Vault out of the box. Dorthin gehören Credentials — nicht in Config-Dateien oder Konstanten.
Push Protection ist toll in der Theorie — verifizier, dass sie auch greift. Bei unserer Aufnahme war sie Beta und liess Pushes stillschweigend durch. Sicherheitsrelevante Controls immer prüfen, ob sie wirklich enforcen, nicht nur ob sie aktiviert sind.