Phase 6: Rollout und Skalierung der Geheimnisüberprüfung

Sie können schnell Sicherheitsfunktionen in großem Maßstab mit einem security configuration, einer Sammlung von Sicherheitsaktivierungseinstellungen, die Sie auf Repositorys in einer Organisation anwenden können, aktivieren. Sie können die Merkmale von Advanced Security auf Organisationsebene mit global settings anpassen. Weitere Informationen findest du unter Informationen zum Aktivieren von Sicherheitsfunktionen in großem Umfang.

In diesem Artikel wird der allgemeine Prozess zur Aktivierung der secret scanning für alle Repositorys in einer Organisation erklärt. Die in diesem Artikel beschriebenen Grundsätze können auch dann umgesetzt werden, wenn du einen gestaffelteren Ansatz für die Aktivierung der secret scanning für einzelne Repositorys wählst.

1. Auf neu committete Geheimnisse konzentrieren

Wenn du die secret scanning aktivierst, solltest du dich darauf konzentrieren, alle neu comitteten Anmeldeinformationen, die bei der Geheimnisüberprüfung entdeckt wurden, zu bereinigen. Wenn du dich darauf konzentrierst, committete Anmeldeinformationen zu bereinigen, könnten Entwickler weiterhin versehentlich neue Anmeldeinformationen pushen. Das bedeutet, dass deine Gesamtanzahl an Geheimnissen in etwa auf demselben Niveau bleibt und nicht wie beabsichtigt abnimmt. Deshalb muss das Kompromittieren neuer Anmeldeinformationen unbedingt verhindert werden, ehe es darum geht, bestehende Geheimnisse zu widerrufen.

Es gibt verschiedene Ansätze, um neu committete Anmeldeinformationen in Angriff zu nehmen, doch eine davon wäre zum Beispiel:

1.        **Benachrichtigen:** Verwende Webhooks, um sicherzustellen, dass alle neuen Secret Warnungen so schnell wie möglich von den richtigen Teams gesehen werden. Ein Webhook wird ausgelöst, wenn eine Geheimniswarnung entweder erstellt, behoben oder erneut geöffnet wird. Anschließend kannst du die Nutzdaten des Webhooks analysieren und in die von dir und deinem Team genutzten Tools wie Slack, Teams, Splunk oder E-Mail integrieren. Weitere Informationen findest du unter [AUTOTITLE](/webhooks-and-events/webhooks/about-webhooks) und [AUTOTITLE](/webhooks-and-events/webhooks/webhook-events-and-payloads#secret_scanning_alert).
   

2.        **Nachverfolgen:** Erstelle einen Korrekturprozess auf hoher Ebene, der für alle Secret-Typen funktioniert. Du kannst dich beispielsweise mit dem Entwickler, der das Geheimnis committet hat, und seinem technischen Leiter für dieses Projekt in Verbindung setzen und sie auf die Gefahren des Committens von Geheimnissen auf GitHub mit der Bitte hinweisen, das erkannte Geheimnis zu widerrufen und zu aktualisieren.
   

   Hinweis

   Dieser Schritt kann automatisiert werden. Bei großen Unternehmen und Organisationen mit Hunderten von Repositorys ist eine manuelle Nachverfolgung nicht praktikabel. Du kannst eine Automatisierung in den im ersten Schritt beschriebenen Webhookprozess einführen. Die Nutzdaten des Webhooks enthalten Repository- und Organisationsinformationen zum kompromittieren Geheimnis. Mithilfe dieser Informationen kannst du die aktuellen Maintainer des Repositorys kontaktieren und eine E-Mail/SMS an die verantwortlichen Personen richten oder ein Issue eröffnen.

3.        **Bildung:** Erstelle ein internes Training, das dem Entwickler zugewiesen wird, der das Secret erstellt hat. In diesem Schulungsdokument kannst du die Risiken erklären, die durch das Committen von Geheimnissen entstehen, und sie auf deine bewährten Methoden zur sicheren Verwendung von Geheimnissen in der Entwicklung verweisen. Wenn ein Entwickler nicht aus der Erfahrung lernt und weiterhin Geheimnisse committet, kannst du einen Eskalationsprozess einrichten, aber in der Regel funktioniert eine Schulung wie gewünscht.
   

Wiederhole die letzten beiden Schritte für alle neuen kompromittierten Geheimnisse. Dieser Prozess ermutigt Entwickler, die Verantwortung für das sichere Verwalten der in ihrem Code verwendeten Geheimnisse zu übernehmen, und ermöglicht es dir, die Reduzierung neu committeter Geheimnisse zu messen.

2. Aktivieren des Push-Schutzes

Nachdem du secret scanning aktiviert hast, solltest du auch den Push-Schutz aktivieren. Mit Push-Schutz überprüft secret scanning Pushes auf unterstützte geheime Schlüssel und blockiert Pusheingaben an GitHub, bevor die geheimen Daten anderen Benutzern offengelegt werden. Wie du den Push-Schutz aktivierst, erfährst du unter Aktivieren des Push-Schutzes für dein Repository.

Nach der Aktivierung kannst du folgende Aktionen ausführen:

1.        **Anleitung geben:** Konfiguriere einen angepassten Link in der Nachricht, den die Mitwirkenden sehen, wenn ihr Push durch secret scanning blockiert wird. Die verknüpfte Ressource kann Anleitungen für Mitwirkende zum Auflösen des blockierten Pushs bereitstellen. Weitere Informationen finden Sie unter [AUTOTITLE](/code-security/secret-scanning/enabling-secret-scanning-features/enabling-push-protection-for-your-repository).
   

2.        **Benachrichtigen:** Definiere einen Webhook, der speziell die Warnungen zur Geheimnisüberprüfung verfolgt, die erstellt werden, wenn jemand den Push-Schutz umgeht, indem er die Warnhinweis-Eigenschaft `"push_protection_bypassed": true` verwendet. Oder verwende die API, um zu erfahren, welche Warnungen zur Geheimnisüberprüfung das Ergebnis einer Umgehung des Push-Schutzes waren, indem du die Ergebnisliste nach `"push_protection_bypassed": true` filterst. Weitere Informationen finden Sie unter [AUTOTITLE](/code-security/getting-started/auditing-security-alerts).
   

3.        **Überwachung:** Mit der Sicherheitsübersicht kannst du dir Metriken zur Leistung des Push-Schutzes in den Repositories deiner Organisation anzeigen lassen, damit du schnell die Repositories identifizieren kannst, in denen du eventuell Maßnahmen ergreifen musst. Weitere Informationen finden Sie unter [AUTOTITLE](/code-security/concepts/secret-security/push-protection-metrics).
   

3. Zuvor committete Geheimnisse beginnend mit dem kritischsten bereinigen

Nachdem du einen Prozess eingerichtet hast, um das Hinzufügen von Geheimnissen zu deinen Codebasen einzudämmen, kannst du damit beginnen, Geheimnisse zu entfernen, die vor der Einführung von GitHub Advanced Security committet wurden.

Die Definition deiner wichtigsten Geheimnisse hängt von den Prozessen und Integrationen deiner Organisation ab. Ein Unternehmen macht sich z. B. wahrscheinlich keine Gedanken über ein Geheimnis des Typs „Slack Incoming Webhook“, wenn es Slack gar nicht nutzt. Es kann hilfreich sein, sich zunächst auf die fünf kritischsten Typen von Anmeldeinformationen für deine Organisation zu konzentrieren.

Sobald du die Entscheidung über die Geheimnistypen getroffen hast, kannst du Folgendes tun:

1. Einen Prozess zur Bereinigung jedes Geheimnistyps einrichten. Die tatsächlichen Verfahren für die einzelnen Geheimnistypen unterscheiden sich oft erheblich. Notiere den Prozess für jeden Geheimnistyp in einem Dokument oder einer internen Wissensdatenbank.

   Hinweis

   Wenn du den Prozess für den Entzug von Secrets erstellst, solltest du versuchen, die Verantwortung für den Entzug von Secrets dem Team zu übertragen, das das Repository verwaltet, und nicht einem zentralen Team. Einer der Grundsätze von GHAS ist, dass Entwickler die Verantwortung für Sicherheit übernehmen und für die Behebung von Sicherheitsproblemen zuständig sind, insbesondere wenn sie diese selbst verursacht haben.

2. Wenn du den Prozess eingerichtet hast, den Teams für das Widerrufen von Anmeldeinformationen befolgen sollen, kannst du Informationen über die Geheimnistypen und andere Metadaten, die den kompromittierten Geheimnissen zuzuordnen sind, zusammentragen, damit du erkennen kannst, wen du über den neuen Prozess informieren musst.

   Sie können diese Informationen in der Sicherheitsübersicht sammeln. Weitere Informationen zur Verwendung der Sicherheitsübersicht finden Sie unter Filtern von Warnungen in der Sicherheitsübersicht.

   Folgende Informationen möchtest du möglicherweise sammeln:

   • Organization

   • Repository

   • Geheimnistyp

   • Geheimer Wert

   • Maintainer des Repositorys zur Kontaktaufnahme

   Hinweis

   Verwende die Benutzeroberfläche, wenn du nur wenige Secrets dieser Art entzogen hast. Wenn es Hunderte kompromittierter Geheimnisse gibt, kannst du die Informationen mithilfe der API sammeln. Weitere Informationen finden Sie unter REST-API-Endpunkte für das Secret Scanning.

3. Nachdem du Informationen über kompromittierte Geheimnisse gesammelt hast, erstelle einen zielgerichteten Kommunikationsplan für die Benutzer, die die Repositorys mit den jeweiligen Geheimnistypen betreuen. Du kannst eine E-Mail oder SMS senden oder auch ein GitHub-Issue in den betroffenen Repositorys einrichten. Wenn du die von diesen Tools zur Verfügung gestellten APIs nutzen kannst, um die Mitteilungen automatisch zu senden, wird die Skalierung für mehrere Geheimnistypen einfacher.

4. Das Programm um weitere Geheimnistypen und benutzerdefinierte Muster erweitern

Du kannst jetzt über die fünf kritischsten Geheimnistypen hinaus eine umfassendere Liste erstellen, und zwar mit einem zusätzlichen Schwerpunkt auf Schulung. Du kannst den vorherigen Schritt wiederholen und zuvor committete Geheimnisse für die verschiedenen anvisierten Geheimnistypen bereinigen.

Du kannst auch weitere der benutzerdefinierten Muster einbeziehen, die in den früheren Phasen gesammelt wurden, und Sicherheits- und Entwicklerteams einladen, weitere Muster zu übermitteln, indem du einen Prozess zur Übermittlung neuer Muster einrichtest, sobald neue Geheimnistypen erstellt werden. Weitere Informationen finden Sie unter Definieren von benutzerdefinierten Mustern für die Geheimnisüberprüfung.

Während du deine Prozesse zur Bereinigung anderer Geheimnistypen weiterentwickelst, solltest du damit beginnen, proaktive Schulungsmaterialien zu erstellen, die in deiner Organisation für alle GitHub-Entwickler freigegeben werden können. Bis zu diesem Zeitpunkt lag der Schwerpunkt vor allem auf der Reaktion. Es ist eine ausgezeichnete Idee, den Fokus auf Proaktivität zu verlagern und Entwickler dazu zu ermutigen, Anmeldeinformationen gar nicht erst auf GitHub zu pushen. Dies kann auf verschiedene Weise geschehen, aber die Erstellung eines kurzen Dokuments, in dem die Risiken und Gründe erläutert werden, wäre ein guter Anfang.