GitHub erweiterte Code-Sicherheitskonfiguration

GitHub Advanced Security hat in der öffentlichen Beta-Phase ein großes Update erhalten, das Ihnen bei der Einführung von Advanced Security-Funktionen in Ihrem Unternehmen hilft. Es heißt "Code-Sicherheitskonfigurationen" und ermöglicht es Ihnen, eine Standardkonfiguration für einige oder alle Repositories in Ihrer Organisation einzurichten.

Vorherige Situation

Bislang gab es bei der Einführung nur drei Optionen:

1. Aktivieren Sie Funktionen nur für neue Repos (Einstellung auf Organisationsebene).
2. Aktivieren Sie GHAS für ALLE Repos auf einen Schlag (dies ist ziemlich aufdringlich und erfordert eine umfassende Schulung aller Entwickler im Vorfeld).
3. Aktivieren Sie Funktionen pro Repo (langsamer und passend zu einem Onboarding-Plan für jedes einzelne Team).

Das bedeutet also, dass Sie entweder langsam vorgehen und jedes Team einzeln aktivieren oder schnell vorgehen und alles auf einmal aktivieren. Letzteres ist meiner Meinung nach nicht wirklich eine Option, es sei denn, Sie wollen viele Ingenieure vom Sicherheitsprozess entfremden. Ich empfehle immer, die Mitarbeiter zu schulen und mit ihnen zu besprechen, was sie tun bzw. ändern müssen, wenn Sie die erweiterte Sicherheit aktivieren. Funktionen wie das Secret Scanning mit Push-Schutz sind natürlich ein leichtes Spiel und können intern ohne große Schulung weitergegeben werden: Zeigen Sie in einem kurzen Video, was aktiviert wird, warum Sie das tun und welche Konsequenzen das hat (das Eindringen von Geheimnissen in die Codebasis verhindern). Erklären Sie dann, was Sie von Ihren Mitarbeitern erwarten, damit sie nicht einfach alles ignorieren, was hereinkommt, und es als "geschlossen mit späterer Korrektur" markieren und dann nichts unternehmen.

Neue Funktionen in der Beta-Version

Die neuen Funktionen sind auf Organisationsebene verfügbar (noch nicht auf Enterprise-Ebene) und werden "Code-Sicherheitskonfigurationen" genannt. Damit können Sie eine Standardkonfiguration für einige oder alle Repositories in Ihrer Organisation einrichten. Auf diese Weise können Sie eine Standardkonfiguration für alle Repositories in Ihrer Organisation einrichten und sie dann bei Bedarf für bestimmte Repositories anpassen.

Neue Richtlinien

Es beginnt mit 'Richtlinien', die Sie auf Repositories anwenden können. Das entspricht der administrativen Terminologie, die GitHub überall verwendet, macht also Sinn.

Da dies neu ist, haben Sie nur die "von GitHub empfohlenen" Richtlinien sowie eine "Legacy"-Richtlinie. Die Legacy-Richtlinie enthält nur die Einstellungen, die Sie zuvor als Standard für neue Repositorys festgelegt hatten.

Die von GitHub empfohlenen Richtlinien schalten die vorgeschlagenen Einstellungen für Dependabot, Secret scanning und Code scanning ein. Die Benutzeroberfläche zeigt Ihnen nicht wirklich, was das bedeutet, und ich bin sehr gespannt, was passiert, wenn sich diese Empfehlung in Zukunft ändert.

Beim Testen stellte sich heraus, dass die folgenden Einstellungen auf der Repo-Ebene aktiviert werden müssen:

• Diagramm der Abhängigkeiten
• Dependabot-Benachrichtigungen
• GitHub Advanced Security auf dem Repo (beansprucht Lizenzplätze)
• CodeQL-Analyse mit der Standardkonfiguration, also im Hintergrund laufend (nicht sichtbar in Actions) und nicht blockierend in einer Pull-Anfrage
• Autofix für CodeQL ist aktiviert (ich bin gespannt, wie das mit PR's funktioniert! Wahrscheinlich folgt es dem Schwellenwert von Check runs), basierend auf der generierten Warnung, aber ich würde auch gerne sehen, ob es den PR überhaupt kommentiert.
• Heimliches Scannen und Push-Schutz (Großartig! Meiner Meinung nach ein gefundenes Fressen)

Das scheint mir zumindest eine sehr vernünftige Voreinstellung zu sein, obwohl ich mir wünschte, dass dies in der Benutzeroberfläche besser sichtbar wäre. Ich würde gerne eine Liste sehen, in der aufgeführt ist, was aktiviert ist und was nicht, so dass Sie die Folgen der Aktivierung dieser Funktionen abschätzen können.

Eine Richtlinie erstellen

Der Bildschirm zum Erstellen einer neuen Police ist ein Traum. Er ist sehr übersichtlich und einfach zu bedienen. Die verschiedenen Funktionen (oder GHAS-'Säulen', wie ich sie gerne nenne) sind zum leichteren Verständnis gruppiert, und Sie können immer noch alle Funktionen aktivieren, die wir vorher hatten. Das Etikett "Erweiterte Sicherheit" zeigt auch sehr schön, welche dieser Funktionen GHAS-Lizenzen für diese Repos erfordern.

Beachten Sie unten auch die Markierung 'Als Standardkonfiguration für neu erstellte Repositorys verwenden'. Dies ist eine gute Möglichkeit, eine Standardkonfiguration für alle Repositorys in Ihrer Organisation einzurichten und sie dann bei Bedarf für bestimmte Repositorys anzupassen. In der Dropdown-Liste auf der rechten Seite haben Sie die Möglichkeit, dies nur für neue öffentliche Repositorys oder nur für neue private und interne Repositorys zu tun. Ich gehe davon aus, dass die Option 'privat und intern' auch 'öffentliche' Repos einschließt, aber ich war mir aufgrund der Benutzeroberfläche nicht sicher, so dass dies noch verbessert werden könnte. Nach dem Testen stellte sich heraus, dass dies tatsächlich der Fall ist!

Anwenden einer Richtlinie

Sie können Richtlinien anwenden, indem Sie die Repo-Übersicht nach den Repositories filtern, die Sie mit der neuen leistungsstarken Filterleiste, die an bestimmten Stellen in der GitHub-Benutzeroberfläche verfügbar ist, ansprechen möchten. Filtern Sie nach den Repos, auf die Sie die Richtlinie anwenden möchten, und klicken Sie dann auf die Schaltfläche 'Konfiguration anwenden'. Daraufhin werden Ihnen die verfügbaren Richtlinien angezeigt und Sie können diejenige auswählen, die Sie anwenden möchten.

Nachdem die Richtlinie auf ein Repository angewendet wurde, können die Repository-Admins sehen, dass es eine Richtlinie gibt, obwohl dies so subtil ist, dass ich es die ersten drei Male übersehen habe. Ich kann mir auch vorstellen, dass es später an dieser Stelle ein Update geben wird, mit dem Repository-Administratoren aus internen Richtlinien auswählen und diese während des Onboarding einfach übernehmen können.

Administratoren auf Repo-Ebene können immer noch Änderungen an ihren Repo-Einstellungen vornehmen und sogar die Sicherheitseinstellungen herabsetzen, wenn sie dies wünschen. Aus der Sicht der Organisationsverwaltung bin ich mir nicht sicher, ob mir das gefällt, da dies den Repo-Administratoren die Möglichkeit gibt, unseren Sicherheitsstandard zu senken. Ich würde gerne eine Möglichkeit sehen, die Einstellungen auf Organisationsebene zu sperren, aber ich sehe auch, dass dies bedeutet, dass Repo-Administratoren von bestimmten Optionen ausgeschlossen werden. Auf der Organisationsebene sehen Sie, wenn ein Projektarchiv mit einer angewandten Richtlinie Einstellungen entfernt hat, so dass das Projektarchiv nicht mehr der Richtlinie entspricht. Diese Information wird im Moment nicht im Audit-Protokoll angezeigt, so dass Sie die Einstellungen selbst im Auge behalten müssen. Ich gehe davon aus, dass dies noch hinzugefügt wird, bevor diese Funktion in die GA aufgenommen wird. Damit kann ich zumindest überwachen, ob die Einstellungen noch in Kraft sind, und bei Bedarf darauf reagieren.

Bitte beachten Sie, dass die Einstellung "Private Schwachstellenmeldung" nicht Teil der Richtlinieneinstellungen ist. Es handelt sich um eine Funktion außerhalb von GHAS, und ich denke, das ist der Grund dafür, dass sie nicht enthalten ist. Als Administrator würde ich diese Funktion gerne auch in den Richtlinieneinstellungen sehen, da ich sie gerne standardmäßig aktiviert hätte und überall fördern würde. Es hängt natürlich vom Reifegrad des Unternehmens ab, ob es eine Enterprise Cloud oder einen Server hat oder ob es vielleicht einen anderen internen Prozess für die Meldung von Sicherheitsschwachstellen gibt. Bisher habe ich gesehen, dass viele Unternehmen nicht einmal eine Richtlinie haben, so dass es meiner Meinung nach sehr sinnvoll ist, diese Funktion standardmäßig zu aktivieren.

Beschränkungen

Im Moment gibt es noch einige Einschränkungen bei der Verwendung der neuen Richtlinien. Dies ist sinnvoll, da es sich nur um eine Beta-Version handelt, so dass in Zukunft noch einige Aktualisierungen folgen könnten. Die Einschränkungen sind:

• Nicht im "Benutzerbereich" verfügbar, also nicht in Ihren eigenen Repos. Das macht Sinn, da dies wahrscheinlich (ich vermute hier) eine kostenpflichtige Funktion für Teams und höhere Pläne sein wird.
• Für kostenlose Organisationen ist es nur für öffentliche Repos verfügbar, aber nicht für private Repos. Es ist großartig, dass diese Funktion für öffentliche Repos kostenlos ist. Das macht es einfacher, diese Funktion auf alle Ihre Repos auszuweiten und Ihre Sicherheit zu verbessern!

Zusammenfassung

Insgesamt gefällt mir die neue Art und Weise, wie Sie die Einführung von Vorgaben in Ihrem Unternehmen beschleunigen können, sehr gut. Ich kann mir vorstellen, dass Sie in Ihrem Unternehmen mehrere Richtlinien in Form von Stufe 1 bis 3 erstellen und die Teams von Stufe zu Stufe abstufen:

Stufe 1: Grundlegende Sicherheitseinstellungen wie geheimes Scannen und Push-Schutz, zusammen mit dem Abhängigkeitsdiagramm und Warnmeldungen. Es ist sinnvoll, hier Code Scanning zu aktivieren, um zumindest die Warnungen zu erhalten, aber ein Kommunikationsplan mit Ihren Ingenieuren ist hier der Schlüssel, um sie wissen zu lassen, dass Warnungen gefunden werden und was wir erwarten, dass sie damit umgehen (oder nicht). Stufe 2: Binden Sie Dependabot-Sicherheitsupdates ein und beginnen Sie mit der Sperrung von PRs mit dem Abhängigkeit - Aktion überprüfen (die übrigens nicht zu den politischen Optionen gehören). Stufe 3: Beinhaltet auch Versionsaktualisierungen sowie die CodeQL-Analyse mit Sperrwarnungen in PR's.

Dies ist sehr hilfreich bei der Einführung von GHAS-Funktionen in der gesamten Organisation, da wir dies ganz einfach für jedes einzelne Team in einem Schritt einführen können, anstatt ein Repo nach dem anderen erstellen zu müssen.