Phase 2: Vorbereiten auf das Aktivieren im großen Stil

Vorbereiten auf das Aktivieren der code scanning

Code scanning ist ein Feature, das du zum Analysieren des Codes in einem GitHub-Repository verwendest, um Sicherheitsrisiken und Codefehler zu finden. Alle von der Analyse ermittelten Probleme werden im Repository angezeigt. Weitere Informationen findest du unter Informationen zu Codescans.

Das Rollout der code scanning hunderte von Repositorys übergreifend kann eine Herausforderung darstellen, besonders dann, wenn es ineffizient erfolgt. Wenn Sie diese Schritte ausführen, stellen Sie sicher, dass Ihr Rollout sowohl effizient als auch erfolgreich ist. Im Rahmen Ihrer Vorbereitung arbeiten Sie mit Ihren Teams zusammen, verwenden die Automatisierung, um Daten zu Ihren Repositorys zu sammeln und code scanning zu aktivieren.

Vorbereiten von Teams auf die code scanning

Bereite deine Teams zunächst darauf vor, die code scanning zu verwenden. Je mehr Teams die code scanning nutzen, desto mehr Daten können für Wartungspläne und zum Überwachen des Fortschritts bei deinem Rollout verwendet werden. In dieser Phase müssen Sie sich auf das Nutzen von APIs und das Ausführen von internen Aktivierungen konzentrieren.

Dein Hauptfokus sollte auf dem Vorbereiten möglichst vieler Teams auf das Verwenden der code scanning liegen. Du kannst die Teams auch dazu ermutigen, entsprechende Wartungen vorzunehmen. Es wird jedoch empfohlen, in dieser Phase das Aktivieren und Verwenden der code scanning gegenüber dem Lösen von Problemen zu priorisieren.

Sammeln von Informationen zu deinen Repositorys

Du kannst programmgesteuert Informationen zu verschiedenen Programmiersprachen sammeln, die in deinen Repositorys verwendet werden, und diese Daten zum Aktivieren der code scanning mithilfe der GraphQL-API von GitHub Enterprise Server in allen Repositorys nutzen, die dieselbe Sprache verwenden.

Wenn du Informationen aus Repositorys sammeln möchtest, die mehreren Organisationen in deinem Unternehmen gehören, kannst du die untenstehende Abfrage zum Abrufen der Namen deiner Organisation verwenden und sie dann in die Repositoryabfrage eingeben. Ersetze „OCTO-ENTERPRISE“ durch deinen Unternehmensnamen.

query {
  enterprise(slug: "OCTO-ENTERPRISE") {
    organizations(first: 100) {
      totalCount
      nodes {
        name
      }
      pageInfo {
        endCursor
        hasNextPage
      }
    }
  }
}

Indem du die Repositorys auf Organisationsebene nach Sprache sortierst, kannst du ermitteln, welche Repositorys welche Sprachen verwenden. Du kannst die nachstehende Beispiel-GraphQL-Abfrage ändern, indem du „OCTO-ORG“ durch den Namen der Organisation ersetzt.

query {
  organization(login: "OCTO-ORG") {
    repositories(first: 100) {
      totalCount
      nodes {
        nameWithOwner
        languages(first: 100) {
          totalCount
          nodes {
            name
          }
        }
      }
      pageInfo {
        endCursor
        hasNextPage
      }
    }
  }
}

Weitere Informationen zum Ausführen von GraphQL-Abfragen findest du unter Erstellen von Aufrufen mit GraphQL.

Konvertiere dann die Daten aus der GraphQL-Abfrage in ein lesbares Format, z. B. eine Tabelle.

Sprache	Anzahl der Repositorys	Name der Repositorys
JavaScript (TypeScript)	4212	org/repo org/repo
Python	2012	org/repo org/repo
Go	983	org/repo org/repo
Java	412	org/repo org/repo
Swift	111	org/repo org/repo
Kotlin	82	org/repo org/repo
C	12	org/repo org/repo

Du kannst die aktuell nicht von GitHub Advanced Security unterstützten Sprachen aus dieser Tabelle herausfiltern.

Wenn du über Repositorys mit mehreren Sprachen verfügst, kannst du die GraphQL-Ergebnisse wie in der nachstehenden Tabelle dargestellt formatieren. Filtere Sprachen heraus, die nicht unterstützt werden, behalte jedoch alle Repositorys mit mindestens einer unterstützten Sprache. Du kannst die code scanning für diese Repositorys aktivieren, und alle unterstützten Sprachen werden überprüft.

Sprache(n)	Anzahl der Repositorys	Name der Repositorys
JavaScript/Python/Go	16	org/repo org/repo
Rust/TypeScript/Python	12	org/repo org/repo

Wenn du weißt, welche Repositorys welche Sprachen verwenden, kannst du mögliche Repositorys für Pilotprogramme in Phase 3 leichter ermitteln und dich besser auf das repositoryübergreifende Aktivieren der code scanning in Phase 5 vorbereiten, das eine Sprache nach der anderen erfolgt.

Aktivieren der code scanning für deine Appliance

Bevor du mit Pilotprogrammen und dem Rollout der code scanning in deinem Unternehmen fortfahren kannst, musst du zuerst die code scanning für deine Appliance aktivieren. Weitere Informationen findest du unter Konfigurieren der Codeüberprüfung für Ihre Anwendung.

Vorbereiten auf das Aktivieren der secret scanning

Bei der Kommunikation zwischen einem Projekt und einem externen Dienst wird ein Token oder ein privater Schlüssel zur Authentifizierung verwendet. Wenn du ein Geheimnis in ein Repository einfügst, kann jedermann mit Lesezugriff auf das Repository das Geheimnis verwenden, um mit deinen Privilegien auf den externen Dienst zuzugreifen. Die Secret scanning überprüft deinen gesamten Gitverlauf auf allen vorhandenen Branches in deinen Repositorys von GitHub auf Geheimnisse und warnt dich oder blockiert den Push mit dem Geheimnis. Weitere Informationen findest du unter Informationen zur Geheimnisüberprüfung.

Überlegungen beim Aktivieren der secret scanning

Das secret scanning-Funktion von GitHub Enterprise Server unterscheidet sich etwas von der code scanning, da sie keine besondere Konfiguration nach Programmiersprache oder Repository bzw. allgemein weniger Konfigurationen benötigt. Dies bedeutet, dass das Aktivieren der secret scanning auf Organisationsebene leicht sein kann. Alle aktivieren auf Organisationsebene anzuklicken und die Option secret scanning für jedes neue Repository automatisch aktivieren anzuwählen, hat einige Downstream-Auswirkungen, denen Sie sich bewusst sein sollten:

Lizenzverbrauch

Wenn du secret scanning für alle Repositorys aktivierst, maximierst du die Nutzung von GitHub Advanced Security-Lizenzen. Dies ist in Ordnung, wenn du über genügend Lizenzen für die aktuellen Committer für alle diese Repositorys verfügst. Wenn die Anzahl der aktiven Entwickler*innen in den nächsten Monaten wahrscheinlich ansteigt, könntest du deine Lizenzgrenze überschreiten, sodass du dann GitHub Advanced Security nicht mehr für neu erstellte Repositorys verwenden kannst.

Anfängliches hohes Volumen erkannter Geheimnisse

Wenn du die secret scanning für eine große Organisation aktivierst, findest du eine hohe Anzahl an Geheimnissen. Manchmal sind Organisationen damit überfordert, und der Alarm wird ausgelöst. Wenn du die secret scanning für alle Repositorys gleichzeitig aktivieren möchtest, solltest du planen, wie du auf mehrere Warnungen in der Organisation reagieren wirst.

Secret scanning können für einzelne Repositorys aktiviert werden. Weitere Informationen findest du unter Aktivieren der Überprüfung auf geheime Schlüssel für Ihr Repository. Secret scanning können, wie oben beschrieben, auch für alle Repositorys in deiner Organisation aktiviert werden. Weitere Informationen zur Aktivierung für alle Repositorys findest du unter Verwalten von Sicherheits- und Analyseeinstellungen für deine Organisation.

Benutzerdefinierte Muster für die secret scanning

Secret scanning erkennen eine große Anzahl an Standardmustern, können jedoch auch so konfiguriert werden, dass sie benutzerdefinierte Muster finden. Dazu gehören z. B. Geheimnisformate, die nur in deiner Infrastruktur zu finden sind, oder von Integratoren verwendet werden, die die secret scanning von GitHub Enterprise Server aktuell nicht erkennt. Weitere Informationen zu unterstützten Geheimnissen für Partnermuster findest du unter Unterstützte Scanmuster für geheime Schlüssel.

Erstelle eine Liste mit Geheimnistypen, wenn du Repositorys überwachst und mit Sicherheits- und Entwicklerteams sprichst, die du später zum Konfigurieren von benutzerdefinierten Mustern für die secret scanning verwenden kannst. Weitere Informationen findest du unter Definieren von benutzerdefinierten Mustern für die Geheimnisüberprüfung.

Pushschutz für secret scanning

Der Pushschutz für Organisationen und Repositorys weist secret scanning an, Pushs auf unterstützte Geheimnisse zu prüfen, bevor Geheimnisse in die Codebasis übertragen werden. Informationen darüber, welche Geheimnisse unterstützt werden, findest du unter Unterstützte Scanmuster für geheime Schlüssel.

Wenn ein Geheimnis in einem Push erkannt wird, wird dieser Push blockiert. Secret scanning listet alle erkannten Geheimnisse auf, sodass der Autor die Geheimnisse überprüfen und entfernen oder, falls erforderlich, die Weitergabe dieser Geheimnisse per Push erlauben kann. Secret scanning kann auch Pushvorgänge auf benutzerdefinierte Muster überprüfen.

Entwickler haben die Möglichkeit, den Pushschutz zu umgehen, indem sie melden, dass ein Geheimnis falsch positiv ist, dass es in Tests verwendet wird oder dass es später behoben wird.

Wenn Mitwirkende einen Pushschutzblock für ein Geheimnis umgehen, werden in GitHub folgende Schritte ausgeführt:

• Erstellen einer Warnung auf der Registerkarte Sicherheit des Repositorys.
• Hinzufügen des Umgehungsereignisses zum Überwachungsprotokoll
• Senden einer E-Mail-Warnung an Besitzerinnen eines Organisationskontos oder eines persönlichen Kontos, Sicherheitsmanagerinnen und Repositoryadministrator*innen, die das Repository beobachten, die einen Link zum Geheimnis und den Grund enthält, warum es zugelassen wurde

Bevor du den Push-Schutz aktivierst, solltest du überlegen, ob du eine Anleitung für Entwicklerteams erstellen musst, unter welchen Bedingungen der Push-Schutz umgangen werden kann. Du kannst einen Link zu dieser Ressource in der Nachricht konfigurieren, die angezeigt wird, wenn ein Entwickler versucht, ein blockiertes Geheimnis zu veröffentlichen.

Mach dich als Nächstes mit den verschiedenen Optionen für die Verwaltung und Überwachung von Warnmeldungen vertraut, die auf die Umgehung des Push-Schutzes durch einen Mitarbeiter zurückzuführen sind.

Weitere Informationen findest du unter Informationen zum Pushschutz.