GitHub-Push-Schutz blockiert in der Vorschau Geheimnisse ohne vordefiniertes Format, standardmäßig aus

GitHub hat am 28. Oktober 2026 angekündigt, dass der Push-Schutz in einer öffentlichen Vorschau nun auch Geheimnisse ohne vordefiniertes Format blockieren kann. Ein eigens gebauter Klassifikator, entwickelt mit Microsoft Applied Sciences, betrachtet, wie ein mögliches Geheimnis im umgebenden Code verwendet wird. Bisher stützte sich der Push-Schutz auf vordefinierte Muster, um jede Geheimnisart zu erkennen. Die neue Prüfung läuft neben diesen Mustererkennern, ist standardmäßig aus und verbraucht kostenpflichtige KI-Guthaben.

Der ältere Ansatz hat eine klare Lücke. Ein Mustererkenner erkennt ein Token, weil es eine bekannte Form hat, etwa ein fester Präfix eines Diensteanbieters. Ein Passwort, ein interner Schlüssel oder das Token eines kleinen Anbieters hat diese Form womöglich nicht. Der neue Klassifikator liest stattdessen den Kontext: wie die Zeichenfolge in der Nähe im Code zugewiesen, übergeben oder verwendet wird. GitHub sagt, so könne er Geheimnisse ohne bekanntes, erkennbares Format blockieren. Die Seite beschreibt Modell, Trainingsdaten und das Verhalten bei Fehlalarmen nicht genauer.

Wenn der Klassifikator läuft, erfasst er neue Pushes, Commits in der GitHub-Weboberfläche und Datei-Uploads. Erkennt er ein Geheimnis, lehnt GitHub die Änderung ab und meldet, wo das Geheimnis steht. Um eine Sperre aufzulösen, entfernt der Entwickler das Geheimnis aus jedem Commit des Pushes und versucht es erneut. Bestehende Abläufe für Umgehung und delegierte Umgehung gelten weiter. GitHub nennt auch eine Regel für Automatisierung: Agenten müssen eine Genehmigung einholen, bevor sie eine Sperre umgehen oder umschiffen. Das ist wichtig, da Coding-Agenten Code pushen, und macht den Schritt der menschlichen Freigabe ausdrücklich.

GitHub formuliert die frühen Ergebnisse vorsichtig. Laut GitHub hat der Klassifikator die Zahl der Pushes, bei denen der Push-Schutz ein Geheimnis fing, mehr als verdoppelt. Das zählt Pushes, keine verschiedenen Geheimnisse; Vergleichsbedingungen und Beobachtungszeitraum legt die Seite nicht offen. GitHub nennt außerdem eine von Nutzern berichtete Präzision, die mit den von Ausstellern definierten Erkennern seiner Partner beim Secret Scanning mithalten soll. Die Seite nennt weder Stichprobengröße noch absolute Zahlen noch eine Fehlalarmrate; diese Aussagen stammen von GitHub selbst und lassen sich anhand der Seite nicht prüfen.

Die Aktivierung hat drei Voraussetzungen. Ein Repository muss KI-erkannte Geheimnisse und Push-Schutz bereits aktiviert haben. Die Funktion steht Organisationen mit GitHub Secret Protection oder GitHub Advanced Security auf github.com offen. Administratoren schalten dann das Blockieren KI-erkannter Geheimnisse ein. Ein Repository-Administrator tut das in den Repository-Einstellungen unter Advanced Security, Secret Protection, KI-erkannte Geheimnisse. Organisations- und Unternehmensadministratoren erstellen oder bearbeiten eine benutzerdefinierte Sicherheitskonfiguration mit drei aktivierten Einstellungen: KI-erkannte Geheimnisse, Push-Schutz und Blockieren KI-erkannter Geheimnisse. Die REST-API-Felder lauten secret_scanning_generic_secrets, secret_scanning_push_protection und secret_scanning_generic_secrets_push_protection. Die Konfiguration wird dann auf die zu schützenden Repositories angewendet.

Die Kosten verdienen Aufmerksamkeit. Die KI-Erkennung im Push-Schutz verbraucht KI-Guthaben, und die Abrechnung beginnt, sobald eine Organisation die Vorschau wählt und die Funktion aktiviert. Dagegen bleiben Warnungen zu KI-erkannten Geheimnissen aus dem Scan nach dem Push ohne Aufpreis in Secret Protection und Advanced Security enthalten. Die Vorschau ist auf github.com beschränkt; Teams mit anderen Bereitstellungen sollten sie noch nicht erwarten. Ein vernünftiger Test beginnt mit wenigen Repositories und einer Aufzeichnung blockierter Pushes und Fehlalarme, bevor man Kosten und Reibung eines breiteren Rollouts auf sich nimmt.