Am 23. Oktober 2026 hat GitHub drei Funktionen zur öffentlichen Secrets-Überwachung (public monitoring) hinzugefügt, einer Funktion, die Enterprise-Cloud-Kunden vorbehalten ist: Alert-Triage, automatische Gültigkeitsprüfungen für offengelegte Token sowie eine REST-API mit Webhooks. Erklärtes Ziel ist es, aus einem reinen Erkennungs-Feed eine vollwertige Arbeitsoberfläche für Sicherheitsteams zu machen.
Eine im Juli gestartete, im Oktober erweiterte Funktion
Die öffentliche Secrets-Überwachung existiert seit dem 1. Juli 2026. Sie durchsucht fortlaufend öffentliche Repositories auf GitHub.com, einschließlich Issue- und Pull-Request-Kommentare, nach Token, die einem Kundenunternehmen gehören. Zwei Zuordnungsmethoden werden kombiniert: die Mitgliedschaft eines Kontos im Unternehmen und der Abgleich mit einer von diesem Unternehmen verifizierten E-Mail-Domain, selbst wenn das Konto kein Mitglied ist. Am 22. Oktober wurde die Vorschau auf Enterprise-Cloud-Mandanten mit Datenresidenz ausgeweitet. Am Tag darauf fügte GitHub Triage, Gültigkeitsprüfungen, die API und Webhooks hinzu, alles ohne Mehrkosten für Unternehmen mit GitHub Advanced Security oder GitHub Secret Protection.
Alerts triagieren, ohne Schließen mit Behebung zu verwechseln
Im Sicherheits-Dashboard des Unternehmens lässt sich ein Alert jetzt mit optionalem Kommentar als „Dismissed“ oder „Fixed“ markieren und bei Bedarf später wieder öffnen. Ein Verlauf protokolliert jede Statusänderung, und Alerts lassen sich nach Repository, Committer, Secret-Typ, Zuordnungsmethode oder Status filtern.
Das Schließen eines Alerts im Unternehmens-Dashboard widerruft das Secret weder, noch entfernt es es aus dem öffentlichen Repository: Es ist eine administrative Aktualisierung, keine Behebung.
Für Teams, die wöchentlich Dutzende Alerts erhalten, verhindert diese Unterscheidung ein trügerisches Sicherheitsgefühl: Die Triage organisiert die Arbeit des Teams, sie neutralisiert nicht das Leck selbst.
Gültigkeitsprüfungen: Lärm von Dringlichkeit trennen
Bei unterstützten Anbietern fragt GitHub nun regelmäßig beim Aussteller eines Token nach, ob es noch reagiert. Jeder Alert erhält einen von drei Status:
| Status | Bedeutung | Empfohlene Maßnahme |
|---|---|---|
| Active | Das Token antwortet beim Anbieter noch | Sofortiger Widerruf |
| Inactive | Das Token wurde bereits widerrufen oder ist abgelaufen | Schließen ohne weitere Maßnahme |
| Unknown | Der Anbieter wird von der Gültigkeitsprüfung nicht abgedeckt | Manuelle Behandlung, als wäre es aktiv |
REST-API und Webhooks: Alerts in die bestehende Werkzeugkette einbinden
Der Endpunkt GET /enterprises/{enterprise}/secret-scanning/public-monitoring-alerts liefert die Metadaten jedes Alerts: Secret-Typ, Zuordnungsmethode und Fundort der Offenlegung. Er steht Unternehmensadministratoren und Enterprise Security Managern zur Verfügung.
curl -s -H "Authorization: Bearer $GH_TOKEN" \
-H "Accept: application/vnd.github+json" \
https://api.github.com/enterprises/ACME-CORP/secret-scanning/public-monitoring-alertsAuf der Benachrichtigungsseite löst das Enterprise-Webhook-Ereignis secret_scanning_public_monitoring_alert nahezu in Echtzeit aus, sobald ein neues Leck der Organisation zugeordnet wird, und leitet es ohne wiederholtes API-Abfragen an ein SIEM oder einen Bereitschaftskanal weiter.
Wer die Funktion nutzen kann, und zu welchem Preis
Die Funktion bleibt eine öffentliche Vorschau, beschränkt auf GitHub Enterprise Cloud, Datenresidenz eingeschlossen. Sie ist ohne Mehrkosten in GitHub Advanced Security oder GitHub Secret Protection enthalten, und ihre Aktivierung sowie die Verwaltung der Alert-Einstellungen obliegen Unternehmensadministratoren und Enterprise Security Managern.
Was man sich merken sollte
Die öffentliche Secrets-Überwachung wandelt sich von einem reinen Erkennungs-Feed zu einer vollständigen Arbeitsoberfläche: Triage, Priorisierung nach Gültigkeit, API und Webhooks. Sie bleibt dennoch auf große Organisationen unter Enterprise Cloud beschränkt, befindet sich in der Vorschau und ersetzt nicht die Basis-Reflexe, die frühere Erweiterungen des Secret Scanning bereits abdecken — etwa für Anthropic- und Salesforce-Schlüssel oder für Lovable- und Supabase-Schlüssel: schnelles Rotieren der Token und Bereinigen der betroffenen Git-Historie.
Was mir am meisten auffällt, ist die gestaffelte Logik: GitHub liefert zuerst die Erkennung und erst Monate später die operative Ebene, die sie handlungsfähig macht. Bei meinen Kunden, die weder Advanced Security noch Enterprise-Größe haben, existiert dieses Sicherheitsnetz schlicht nicht, und ich empfehle weiterhin einen Secrets-Manager und Pre-Commit-Hooks, statt darauf zu warten, dass eine Plattform das Problem für mich löst. — Simon Janvier
Zum Weiterlesen: die offizielle Ankündigung im GitHub-Changelog.
