GitHub erweitert Repository Rulesets um eine Sicherheitskontrolle, die Pull-Request-Merges blockieren kann, solange die Secret-Scanning-Prüfung für den aktuellen Head-Commit nicht abgeschlossen ist oder neu eingeführte Secret-Alarme offen sind. Für Unternehmen ist das mehr als eine zusätzliche Checkbox: Die Prüfung wandert an einen geschäftskritischen Übergang im Entwicklungsprozess. Damit sie Sicherheit erhöht, ohne Releases unnötig zu blockieren, braucht es klare Zuständigkeiten, begrenzte Ausnahmen und einen definierten Incident-Prozess.
Was GitHub bestätigt hat
Die Regel heißt „Require secret scanning alerts are resolved“. Ohne Bypass-Berechtigung kann ein Pull Request erst zusammengeführt werden, wenn zwei Bedingungen erfüllt sind: Der Secret Scan für den Head-Commit ist beendet und alle durch den Pull Request neu eingeführten Secret-Alarme sind gelöst. Nach Angaben von GitHub läuft die Prüfung standardmäßig für offene Pull Requests und berücksichtigt zunächst Geheimnisse, die über Provider-Muster erkannt werden.
Weitere Kategorien wie benutzerdefinierte oder generische Muster lassen sich ergänzen. Konfiguriert wird die Regel in Repository Rulesets auf Repository-, Organisations- oder Enterprise-Ebene und für ausgewählte Ziel-Branches. GitHub nennt außerdem den REST-API-Regeltyp „require_secret_scanning_alert_resolution“ mit „secret_types“ sowie das GraphQL-Enum „REQUIRE_SECRET_SCANNING_ALERT_RESOLUTION“. Die Funktion befindet sich in der Public Preview und ist für Kunden mit GitHub Secret Protection oder GitHub Advanced Security verfügbar. Das ist ein bestätigter Funktionsstand, aber noch kein Signal für einen flächendeckenden Rollout ohne Pilotphase.
Push Protection und Merge-Regel erfüllen unterschiedliche Aufgaben
Push Protection setzt früher an: Sie soll erkannte Geheimnisse bereits beim Push stoppen. Die neue Regel arbeitet später am Pull Request und verhindert den Merge, wenn die Prüfung noch läuft oder ein neuer Alarm ungelöst bleibt. Daraus folgt ein Defense-in-Depth-Modell. Die Merge-Regel ersetzt Push Protection nicht; sie bildet eine zweite Kontrollschicht für Fälle, die beim Push nicht verhindert wurden oder deren Muster dort nicht abgedeckt beziehungsweise anders konfiguriert waren.
Für den Einstieg sind Provider-Muster der pragmatische Umfang, weil GitHub sie standardmäßig einbezieht. Eigene und generische Muster können den Schutz erweitern, erhöhen aber voraussichtlich auch den Abstimmungsbedarf. Diese operative Ableitung sollte im Pilot überprüft werden: Erst wenn Teams Alarme zuverlässig bewerten und bearbeiten, ist eine breitere Musterabdeckung sinnvoll.
Was bei einem blockierten Pull Request passieren muss
Ein Merge-Gate ist nur so wirksam wie der Prozess dahinter. Bleibt unklar, wer einen Alarm bewertet, ein Secret rotiert oder eine Ausnahme freigibt, verlagert die Regel das Risiko lediglich in informelle Umgehungen. Eine schlanke Verantwortungsverteilung kann so aussehen:
- Entwickler: Fundstelle prüfen, Secret aus Code und Build-Artefakten entfernen und verhindern, dass es erneut verwendet wird.
- Repository-Verantwortliche oder AppSec: Alarm verifizieren, zulässigen Lösungsgrund dokumentieren und sicherstellen, dass der aktuelle Head-Commit geprüft wurde.
- Secret-Eigentümer: Bei einem echten Fund das Zugangsmittel widerrufen oder rotieren und abhängige Systeme kontrolliert aktualisieren.
- Security- oder Incident-Verantwortliche: Prüfen, ob das Secret bereits erreichbar oder verwendet war und ob weitere Maßnahmen erforderlich sind.
- Freigabeverantwortliche: Nur nachvollziehbare, dokumentierte Ausnahmen zulassen; ein schneller Merge ist kein ausreichender Bypass-Grund.
Die ersten beiden Punkte folgen direkt aus der Funktionsweise des Gates. Rotation, Nutzungsprüfung und Incident-Bewertung sind daraus abgeleitete betriebliche Schutzmaßnahmen. Diese Trennung ist wichtig: GitHub verhindert den Merge, übernimmt aber nicht automatisch die Wiederherstellung eines möglicherweise kompromittierten Zugangsmittels.
Bypass-Rechte als Notfallweg, nicht als Normalprozess
GitHub weist ausdrücklich darauf hin, dass Nutzer mit Bypass-Berechtigung die Sperre umgehen können. Deshalb ist die Rechtevergabe ein zentraler Teil des Designs. Unternehmen sollten den Kreis klein halten, Ausnahmen protokollieren und regelmäßig prüfen. Sinnvoll ist ein Notfallweg mit benanntem Freigabeverantwortlichen, dokumentierter Begründung und nachgelagerter Kontrolle. Dauerhafte Ausnahmen für einzelne Teams würden den Wert des zentralen Rulesets unterlaufen.
Rollout in fünf kontrollierten Schritten
- Voraussetzungen klären: Lizenzumfang, aktiviertes Secret Scanning, betroffene Organisationen und schützenswerte Ziel-Branches erfassen.
- Pilot begrenzen: Mit wenigen Repositories und Provider-Mustern beginnen, statt sofort alle Muster und Teams einzubeziehen.
- Reaktion definieren: Zuständigkeiten, zulässige Alarm-Lösungen, Rotationsweg, Incident-Eskalation und Bypass-Freigabe schriftlich festlegen.
- Betrieb beobachten: Blockierte Pull Requests, Scan-Dauer, bestätigte Funde, Fehlalarme, Bypässe und Zeit bis zur Rotation erfassen.
- Skalierung standardisieren: Nach dem Pilot Rulesets auf Organisations- oder Enterprise-Ebene ausrollen und API-Automatisierung erst bei stabilen Vorgaben einsetzen.
Für Release-Prozesse ist besonders die Scan-Dauer relevant. Solange die Prüfung nicht abgeschlossen ist, bleibt der Merge blockiert. Teams benötigen daher Sichtbarkeit über ausstehende Scans und einen Supportweg für ungewöhnlich lange Laufzeiten. Ein internes Serviceziel kann später aus Pilotdaten entstehen; eine belastbare allgemeine Vorgabe nennt GitHub in der Ankündigung nicht.
Welche Kennzahlen den Pilot aussagekräftig machen
Die reine Zahl blockierter Pull Requests ist kein Erfolgsnachweis. Aussagekräftiger ist die Kombination aus mittlerer Scan-Dauer, bestätigten Secrets, Fehlalarmen, Bypass-Nutzung und Zeit bis zum Widerruf oder zur Rotation. Ergänzend sollte sichtbar sein, welche Musterkategorien die Funde erzeugen. So lässt sich unterscheiden, ob das Gate echte Risiken stoppt oder vor allem Reibung produziert. Konkrete Zielwerte sollten Unternehmen aus ihrem eigenen Pilot ableiten und nicht erfinden oder ungeprüft übernehmen.
Fazit: Das Merge-Gate braucht einen Betriebsprozess
Die neue GitHub-Regel setzt eine klare technische Grenze: Kein regulärer Merge, solange der aktuelle Commit nicht geprüft oder ein neu eingeführter Secret-Alarm offen ist. Der geschäftliche Nutzen entsteht jedoch erst durch das Zusammenspiel mit Push Protection, begrenzten Bypass-Rechten und einer Reaktion, die echte Secrets konsequent rotiert. Wegen des Preview-Status ist ein messbarer Pilot auf ausgewählten Repositories der vernünftige Weg. Danach kann das Ruleset standardisiert und über die vorhandenen Schnittstellen skaliert werden.