Diese Version von GitHub Enterprise Server wurde eingestellt am 2024-03-26. Es wird keine Patch-Freigabe vorgenommen, auch nicht für kritische Sicherheitsprobleme. Für bessere Leistung, verbesserte Sicherheit und neue Features aktualisiere auf die neueste Version von GitHub Enterprise Server. Wende dich an den GitHub Enterprise-Support, um Hilfe zum Upgrade zu erhalten.

Phase 3: Pilotprogramme

Es kann von Vorteil sein, wenn du mit einigen wenigen Projekten und Teams beginnst, die eine hohe Relevanz haben und mit denen du in einem Pilotprogramm einen ersten Rollout durchführst. Dies ermöglicht es einer ersten Gruppe in deinem Unternehmen, sich mit GHAS vertraut zu machen, zu erfahren, wie GHAS aktiviert und konfiguriert wird, und eine solide Grundlage für GHAS zu erstellen, bevor du den Rollout für den Rest deines Unternehmens durchführst.

In diesem Artikel

Dieser Artikel ist Teil einer Reihe zur Einführung von GitHub Advanced Security nach Maß. Den vorherigen Artikel dieser Reihe findest du unter Phase 2: Vorbereiten auf das Aktivieren im großen Stil.

Informationen zu Pilotprogrammen

Wir empfehlen dir, einige besonders relevante Projekte oder Teams für einen Pilotrollout von GHAS zu bestimmen. So kann sich eine erste Gruppe innerhalb deines Unternehmens mit GHAS vertraut machen und eine solide Grundlage für GHAS schaffen, ehe du den Rollout auf den Rest deines Unternehmens ausweitest.

Mit den Schritten in dieser Phase kannst du GHAS in deinem Unternehmen aktivieren, mit der Nutzung seiner Features beginnen und deine Ergebnisse überprüfen. Wenn du mit GitHub Expert Services arbeitest, können sie durch diesen Prozess zusätzliche Unterstützung durch Onboarding-Sitzungen, GHAS-Workshops und Problembehandlung bei Bedarf bereitstellen.

Bevor du mit deinen Pilotprojekten beginnst, empfehlen wir, einige Besprechungen mit deinen Teams zu planen, z. B. eine erste Besprechung, eine Überprüfung zur Projekthalbzeit und eine Abschlusssitzung, wenn der Pilot abgeschlossen ist. Diese Besprechungen helfen allen, bei Bedarf Anpassungen vorzunehmen und sicherzustellen, dass deine Teams vorbereitet sind und unterstützt werden, um den Piloten erfolgreich abzuschließen.

Wenn du GHAS noch nicht für deine GitHub Enterprise Server-Instanz aktiviert hast, findest unter Aktivieren von GitHub Advanced Security für dein Unternehmen weitere Informationen.

Du musst GHAS für jedes Pilotprojekt aktivieren, entweder durch Aktivieren des GHAS-Features für jedes Repository oder für alle Repositorys in allen Organisationen, die an dem Pilotprojekt teilnehmen. Weitere Informationen findest du unter Verwalten von Sicherheits- und Analyseeinstellungen für dein Repository oder Verwalten von Sicherheits- und Analyseeinstellungen für deine Organisation.

Pilotprojekt für code scanning

Informationen zum Aktivieren von code scanning für deine GitHub Enterprise Server-Instanz findest du unter Konfigurieren der Codeüberprüfung für Ihre Anwendung.

Sie können code scanning in einem Repository ausführen, indem Sie einen GitHub Actions erstellen, um die CodeQL-Aktion auszuführen. Weitere Informationen zu GitHub Actions findest du unter:

Wir empfehlen, code scanning im Rahmen deines Pilotprogramms für alle einzelnen Repositorys zu aktivieren. Weitere Informationen findest du unter Konfigurieren des Codescanning.

Wenn Sie code scanning für viele Repositorys aktivieren möchten, sollten Sie ein Skript für den Prozess schreiben.

Ein Beispiel für ein Skript, das Pull Requests öffnet, um einen GitHub Actions-Workflow zu mehreren Repositorys hinzuzufügen, findest du im jhutchings1/Create-ActionsPRs-Repository für ein Beispiel mit PowerShell oder nickliffen/ghas-enablement für Teams, die keine PowerShell haben und stattdessen NodeJS verwenden möchten.

Beim Ausführen der ersten Codeüberprüfungen kannst du feststellen, dass keine Ergebnisse gefunden werden oder dass eine ungewöhnliche Anzahl von Ergebnissen zurückgegeben wird. Es kann ratsam sein, das anzupassen, was in zukünftigen Überprüfungen gekennzeichnet wird. Weitere Informationen findest du unter Anpassen Codeüberprüfung.

Wenn Ihr Unternehmen andere Codeanalyse-Tools von Drittanbietern mit GitHub code scanning verwenden möchte, können Sie Aktionen verwenden, um diese Tools innerhalb von GitHub auszuführen. Alternativ kannst du Ergebnisse, die von Drittanbietertools als SARIF-Dateien generiert werden, in code scanning hochladen. Weitere Informationen findest du unter Integrieren der Codeüberprüfung.

Durchführen eines Pilotprojekts für secret scanning

GitHub überprüft Repositorys auf bekannte Geheimnistypen, um das betrügerische Verwenden von Geheimnissen zu verhindern, die aus Versehen committet wurden.

Informationen zum Aktivieren der Überprüfung von Geheimnissen für deine GitHub Enterprise Server-Instanz findest du unter Konfigurieren der Geheimnisüberprüfung für deine Appliance.

Du musst die Überprüfung von Geheimnissen für jedes Pilotprojekt aktivieren, entweder durch Aktivieren des Features für jedes Repository oder für alle Repositorys in allen Organisationen, die an dem Projekt teilnehmen. Weitere Informationen findest du unter Verwalten von Sicherheits- und Analyseeinstellungen für dein Repository oder Verwalten von Sicherheits- und Analyseeinstellungen für deine Organisation.

Aktiviere als Nächstes den Pushschutz für jedes Pilotprojekt.

Wenn du beabsichtigst, einen Link zu einer Ressource in der Nachricht zu konfigurieren, die angezeigt wird, wenn ein Entwickler versucht, ein blockiertes Geheimnis zu pushen, wäre jetzt ein guter Zeitpunkt, um die Anleitung zu testen und zu verfeinern, die du zur Verfügung stellen willst.

Wenn du benutzerdefinierte Muster für dein Unternehmen gesammelt hast, insbesondere solche, die mit den Pilotprojekten für secret scanning zusammenhängen, kannst du diese konfigurieren. Weitere Informationen findest du unter Definieren von benutzerdefinierten Mustern für die Geheimnisüberprüfung.

Informationen zum Anzeigen und Schließen von Warnungen für Geheimnisse, die in deinem Repository eingecheckt sind, findest du unter Verwalten von Warnungen aus der Geheimnisüberprüfung.

Den nächsten Artikel in dieser Reihe findest du unter Phase 4: Erstellen interner Dokumentation.