Phase 5: Rollout und Skalierung der Codeüberprüfung

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:

1. Aktiviere GHAS für das Repository. Weitere Informationen finden Sie unter Verwalten von Sicherheits- und Analyseeinstellungen für dein Repository.
2. 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 finden Sie unter Erstellen eines Pull Requests.
3. 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 finden Sie 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.

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.