GitHub erweitert die Sicherheitsprüfung von GitHub Actions: In einer neuen öffentlichen Vorschau kann das Secret Scanning jetzt auch Ausführungsprotokolle von Workflows auf versehentlich ausgegebene Zugangsdaten untersuchen. Die bisherige Prüfung von Repositoryinhalten wird damit um eine weitere mögliche Leckquelle ergänzt. Das Unternehmen kündigte die Funktion am 9. November 2026 an.
Die Neuerung richtet sich zunächst an Unternehmen mit GitHub Enterprise Cloud und den passenden Sicherheitsprodukten. Sie ist standardmäßig deaktiviert und muss von einem Enterprise-Administrator ausdrücklich eingeschaltet werden. Für gewöhnliche kostenlose GitHub-Repositorys steht die neue Prüfung von Actions-Protokollen nicht allgemein zur Verfügung.
Prüfung beginnt nach Abschluss eines Workflows
Nach der Freischaltung untersucht GitHub die Protokolle neuer Workflow-Ausführungen, sobald der jeweilige Lauf beendet ist. Erkennt die Analyse eine unterstützte Zeichenfolge, erscheint ein Fund in der bestehenden Liste der Secret-Scanning-Warnungen des Repositories. Die Meldung kann auf die betreffende Workflow-Datei und die betroffene Protokollzeile verweisen. So lässt sich nachvollziehen, bei welcher automatisierten Aufgabe ein Geheimnis möglicherweise sichtbar wurde.
Die Warnung bleibt laut offizieller GitHub-Ankündigung auch dann erhalten, wenn die ursprüngliche Protokolldatei später gelöscht wird. Das ist für die Nachverfolgung nützlich, ersetzt jedoch nicht das Widerrufen möglicherweise offengelegter Zugangsdaten. Ein kompromittierter Token kann auch nach der Löschung des Protokolls weiter verwendbar sein.
Nur für bestimmte Enterprise-Konten und nicht rückwirkend
Vorausgesetzt wird GitHub Enterprise Cloud mit GitHub Secret Protection oder GitHub Advanced Security. Auch entsprechende Enterprise-Cloud-Umgebungen mit Datenresidenz können teilnehmen. Enterprise-Eigentümer aktivieren die Funktion in den Unternehmenseinstellungen unter Policies → Advanced Security. Zusätzlich muss Secret Scanning für die jeweiligen Repositories bereits aktiviert sein.
Wichtig ist die zeitliche Grenze: GitHub untersucht ausschließlich Workflow-Ausführungen, die nach der Aktivierung abgeschlossen werden. Frühere Actions-Protokolle werden nicht nachträglich verarbeitet. Wer vorhandene Logdateien auf versehentlich veröffentlichte Tokens überprüfen will, muss dies mit geeigneten eigenen Verfahren tun.
Erkennung bleibt auf bestimmte Geheimnismuster beschränkt
Die Vorschau unterstützt zunächst nur die sogenannten Provider Patterns, also Muster bestimmter Dienstanbieter. Generische Geheimnisformen, eigene Erkennungsmuster und KI-gestützte Geheimnissuche werden in Actions-Protokollen noch nicht berücksichtigt. Werte, die GitHub Actions bereits selbst unkenntlich gemacht hat, fallen ebenfalls nicht unter die zusätzliche Suche.
Eine weitere Einschränkung ist für den Betrieb entscheidend: Während der Vorschau lösen Logfunde keine automatischen Benachrichtigungen aus. Sicherheitsverantwortliche müssen die Secret-Scanning-Warnungen ihrer Repositories deshalb gezielt kontrollieren. Die offizielle deutschsprachige GitHub-Dokumentation beschreibt diese Einschränkungen und den Ablauf der Prüfung.
Was Administratoren in Build- und Deployment-Pipelines beachten sollten
Gerade Build-Prozesse, Deployment-Jobs und Fehlerprotokolle können unbeabsichtigt API-Schlüssel, Zugriffstokens oder andere Zugangsdaten ausgeben. Das geschieht beispielsweise, wenn Werkzeuge ihre Umgebungsvariablen oder ausführliche Diagnoseausgaben protokollieren. Secret Scanning kann einen Teil solcher Vorfälle nachträglich sichtbar machen. Die eigentliche Absicherung beginnt aber früher: Geheimnisse gehören nicht in Logausgaben und sollten nur mit den notwendigen Berechtigungen an einen Workflow übergeben werden.
Wird ein tatsächlich verwendbarer Schlüssel gefunden, sollten Verantwortliche ihn beim ausstellenden Dienst widerrufen beziehungsweise rotieren und anschließend prüfen, welche Workflows und Anwendungen ihn noch benötigen. Die deutsche GitHub-Referenz zu Actions-Geheimnissen erläutert die automatische Maskierung und deren Grenzen. Weil die neue Logprüfung nicht alle Geheimnistypen erkennt, sollte ein ausbleibender Warnhinweis nicht als Beleg für vollständig sichere Protokolle verstanden werden.
Offizielle Informationen
GitHub Changelog vom 9. November 2026 · GitHub-Dokumentation zur Geheimnisüberprüfung (Deutsch) · GitHub Actions: Referenz zu Geheimnissen (Deutsch). Die Ankündigung liegt auf Englisch vor; die ergänzende technische Dokumentation ist offiziell auch auf Deutsch verfügbar.
Werbung
(**) UVP: Unverbindliche Preisempfehlung
Preise inkl. MwSt., zzgl. Versandkosten