Am 9. November 2026 kündigte GitHub eine öffentliche Vorschau an, die Secrets in den Protokollen von GitHub-Actions-Workflow-Läufen erkennt. Bislang deckte das Secret Scanning den Quellcode und einige weitere Orte ab, ließ aber die von den Workflows selbst erzeugten Protokolle außen vor, ein häufiger Leck-Vektor, wenn ein Build-Schritt versehentlich einen sensiblen Wert ausgibt.
Warum dieser blinde Fleck zählte
Ein CI/CD-Workflow verarbeitet ständig Tokens, API-Schlüssel und Deployment-Zugangsdaten. Ein vergessener Debug-Befehl, eine stehen gebliebene Ausgabeanweisung oder ein unsauber behandelter Fehler genügen, um diese Werte in einem öffentlichen oder geteilten Protokoll offenzulegen, ohne dass eines der üblichen Scan-Werkzeuge sie erkennt, da sie nie ins Repository eingecheckt wurden.
Wie die Funktion arbeitet
Nach der Aktivierung durchsucht GitHub die Protokolle jedes Laufs, sobald dieser abgeschlossen ist; vergangene Läufe werden nicht rückwirkend durchsucht. Erkannte Secrets erscheinen in der Liste der Secret-Scanning-Warnungen des Repositorys, zusammen mit Warnungen aus dem Code, mit einem direkten Link zur Stelle im Protokoll. Für Secret-Typen, die dies zulassen, werden Gültigkeitsprüfungen durchgeführt, und Warnungen bleiben auch nach dem Löschen der zugrunde liegenden Protokolle verfügbar.
| Aspekt | Detail |
|---|---|
| Standardzustand | Deaktiviert |
| Wer aktiviert | Unternehmensinhaber, auf Organisationsebene |
| Erfasste Secret-Typen | Nur erkannte Anbietermuster |
| Nicht erfasst | Generische Muster, benutzerdefinierte Muster, von KI erkannte Secrets, bereits von Actions maskierte Werte |
| Benachrichtigungen | Keine während der Vorschau |
| Verfügbarkeit | GitHub Enterprise Cloud mit Secret Protection oder Advanced Security, einschließlich GHE.com |
Aktivierung
Die Einstellung befindet sich auf Unternehmensebene unter Policies, dann Advanced Security, wo Secret scanning for Actions workflow logs für die betreffenden Repositories auf Enabled gesetzt werden muss. Die Funktion gilt nur für Repositories, auf denen das klassische Secret Scanning bereits aktiv ist.
name: build
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build
env:
DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}
run: |
# ein Debug-Befehl, der diese Variable preisgibt, wuerde
# nun ebenfalls in der Liste der Secret-Scanning-Warnungen landen
./build.shBestehende Protokolle werden nicht rückwirkend neu durchsucht: Erfasst werden nur Läufe, die nach der Aktivierung abgeschlossen werden.
Grenzen dieser Vorschau
Die Abdeckung bleibt partiell: Erkannt werden nur bekannte Anbietermuster, generische oder benutzerdefinierte Muster sowie heuristisch erkannte Secrets bleiben außen vor. Das Fehlen von Benachrichtigungen während der Vorschauphase bedeutet zudem, dass Teams die Warnungsliste des Repositorys manuell prüfen müssen, statt sich auf einen automatischen Hinweis zu verlassen. Es handelt sich um dieselbe Disziplin, die bereits beim Thema galt, als GitHub pull_request_target standardmäßig zu blockieren begann: Eine Schutzmaßnahme vorab zu aktivieren zählt mehr als erst nach einem Vorfall zu reagieren.
Das Wichtigste in Kürze
Diese Erweiterung schließt einen bekannten blinden Fleck für Teams, die GitHub-Actions-Pipelines betreiben, ersetzt aber nicht die grundlegenden guten Praktiken: Secrets systematisch maskieren, regelmäßig rotieren und die in CI/CD verwendeten Tokens im Umfang begrenzen. Sie reiht sich ein in weitere jüngste Plattformänderungen, die die Angriffsfläche von Workflows verkleinern sollen.
Funktionen dieser Art kommen meist nach einer Reihe dokumentierter Vorfälle, und auch hier ist das nicht anders: Secret-Lecks über Ausführungsprotokolle sind ein klassischer Befund bei CI/CD-Sicherheitsaudits. Das aufschlussreichste Detail ist nicht das Werkzeug selbst, sondern sein standardmäßig deaktivierter Zustand, der viel über die weiterhin gebotene Vorsicht bei einer Funktion aussagt, die die gesamte Protokollhistorie einer Organisation liest — Simon Janvier.
Weiterführende Links
Primärquelle: das offizielle GitHub-Changelog, 9. November 2026.
