Dieser Artikel ist Teil einer Reihe zur Einführung von GitHub Advanced Security nach Maß. Den vorherigen Artikel dieser Reihe findest du unter Phase 4: Erstellen interner Dokumentation.
Aktivieren der Codeüberprüfung
Mit den Daten, die du in Phase 2 gesammelt hast, kannst du zunächst GHAS und dann code scanning für deine Repositorys aktivieren, jeweils für eine bestimmte Sprache. Die Schritte im Prozess zur Aktivierung von GHAS sind wie folgt:
- Aktiviere GHAS für das Repository. Weitere Informationen findest du unter Verwalten von Sicherheits- und Analyseeinstellungen für dein Repository.
- Erstelle einen Pull Request für den Standardbranch des Repositorys mit einer
codeql-analysis.yml-Datei, die ein Beispiel für die Ausführung von CodeQL für diese Sprache enthält. Weitere Informationen findest du unter Erstellen eines Pull Requests. - Erstelle ein Issue im Repository, um zu erklären, warum ein Pull Request ausgelöst wurde. Das Issue, das du erstellst, kann einen Link zur vorherigen Mitteilung enthalten, die an alle Benutzer gesendet wurde. Es kann aber auch erklären, welche Änderungen der Pull Request einführt, welche nächsten Schritte das Team unternehmen muss, welche Zuständigkeiten das Team hat und wie das Team code scanning nutzen sollte. Weitere Informationen findest du unter Einen Issue erstellen.
Es gibt mit ghas-enablement ein öffentlich verfügbares Tool, mit dem die ersten beiden Schritte erledigt werden können. Du kannst das Tool ghas-enablement in Batches von Sprachen erneut ausführen, sofern dies sinnvoll ist. Beispielsweise weisen JavaScript, TypeScript, Python und Go wahrscheinlich ähnliche Buildprozesse auf und könnten daher eine ähnliche CodeQL-Analysedatei verwenden. Das Tool ghas-enablement kann auch für Sprachen wie Java, C und C++ verwendet werden. Da diese Sprachen jedoch sehr unterschiedliche Build- und Kompilierungsprozesse aufweisen, musst du möglicherweise spezifischere CodeQL-Analysedateien erstellen.
Hinweis: Wenn du vorhast, GitHub Actions mithilfe von code scanning zu steuern, ohne auf das Tool ghas-enablement zurückzugreifen, beachte, dass kein API-Zugriff auf das Verzeichnis .github/workflow möglich ist. Das bedeutet, dass du ein Skript nicht ohne einen Git-Client erstellen kannst, der der Automatisierung zugrunde liegt. Die Umgehung besteht darin, Bash-Skripts auf einem Computer oder in einem Container mit einem Git-Client zu nutzen. Der Git-Client kann Dateien in das Verzeichnis .github/workflows mit der Datei codeql-analysis.yml pushen und pullen.
Es ist wichtig, dass du die Datei codeql-analysis.yml nicht einfach in den Standardbranch des Repositorys pushst. Ein Pull Request überträgt dem Entwicklungsteam den Besitz für Review- und Mergeprozesse und ermöglicht dem Entwicklungsteam, code scanning kennenzulernen und das Team in den Prozess einzubeziehen.
Du solltest die URLs der Pull Requests erfassen, die per Automatisierung erstellt werden, und jede Woche überprüfen, ob es Aktivitäten gibt und welche geschlossen wurden. Nach ein paar Wochen kann es sich lohnen, ein weiteres Issue zu erstellen oder interne E-Mails zu senden, wenn der Pull Request weiterhin nicht gemergt wurde.
Aufbau von Fachkompetenz
Dann kannst du zur nächsten Phase der Implementierung übergehen, die darin besteht, interne fachliche Ansprechpartner zu bestimmen und Besprechungen im Unternehmen anzuberaumen. Das Öffnen von Pull Requests und Issues in Repositorys wird wahrscheinlich einen großen Teil deiner Akzeptanzprobleme lösen. Das gilt aber nicht für punktuelle Anwendungsfälle, bei denen ein bestimmter Prozess, ein bestimmtes Framework oder eine bestimmte Bibliothek die Aktivierung bestimmter Featureflags erfordert. Ein stärker personalisierter und praxisorientierter Ansatz ist erforderlich, um eine hohe Akzeptanz zu erreichen, insbesondere für Java, C und C++.
Regelmäßige Besprechungen zu bestimmten Themen sind eine gute Idee, um den Rollout in einer größeren Gruppe zu erörtern. Dieser Ansatz ist für ein Unternehmen mit Tausenden von Repositorys viel zeitsparender als das Arbeiten mit nur jeweils einem Team. Teams können zu Sitzungen kommen, die für sie relevant sind. Es folgen einige bereits durchgeführte Beispielsitzungen:
- Code scanning in einem Container
- Code scanning und Java Struts
- Code scanning und JSP
Du kannst die Daten, die du über die Verteilung verschiedener Sprachen auf Repositorys gesammelt hast, nutzen, um Besprechungen gezielt auszurichten.
Den nächsten Artikel in dieser Reihe findest du unter Phase 6: Rollout und Skalierung der Geheimnisüberprüfung.