GitHub Advanced Security in der Vorschau auf Azure DevOps

Microsoft bringt einige der GitHub Advanced Security Tools zu Azure DevOps. Ich habe schon eine Weile damit gespielt und auf der Microsoft Build 2023 wurde der neueste Stand vorgestellt, der eine Public Preview! beinhaltet. Das heißt, Sie können es selbst ausprobieren, und ich kann endlich meine Erfahrungen mit Ihnen teilen! Da ich auf GitHub vielen Leuten beibringe, wie man es verwendet, finden Sie in diesem Beitrag auch einige der Unterschiede zwischen den beiden Implementierungen.

Was ist GitHub Advanced Security?

GitHub Advanced Security (GHAS) ist eine Reihe von Tools, die Ihnen helfen, Ihren Code und Ihre Pipelines zu sichern. Es umfasst die folgenden Tools:

• Code scannen
• Dependabot / Überprüfung von Abhängigkeiten
• Heimliches Scannen

Wenn Sie tiefer in diese Funktionalität eintauchen möchten, schauen Sie sich meinen LinkedIn Lernkurs hier an.

Dependabot / Überprüfung von Abhängigkeiten

Durchsucht Ihr Repository nach bekannten Manifestdateien wie package.json und prüft, ob die von Ihnen verwendeten Pakete eine Sicherheitslücke aufweisen. Es erstellt dann eine Pull-Anfrage, um das Paket auf eine neuere Version zu aktualisieren, die die Sicherheitslücke nicht aufweist. Es kann auch die Erstellung von Pull Requests für Versionsaktualisierungen automatisieren.

Heimliches Scannen

Durchsucht Ihr Repository nach bekannten Geheimnissen, wie z. B. Passwörtern, und benachrichtigt Sie, wenn es welche findet. Es benachrichtigt Sie auch, wenn Sie einen Commit veröffentlichen, der ein Geheimnis enthält. Es durchsucht auch Ihre Pull-Anfragen nach Geheimnissen und benachrichtigt Sie, wenn es welche findet.

Code scannen

Scannt Ihren Code mit CodeQL (oder einem anderen Static Application Security Tool, auch SAST genannt) auf bekannte Sicherheitslücken. Es kann auch Ihre Pull-Requests auf Sicherheitslücken scannen und Sie benachrichtigen, wenn es welche findet.

GitHub Erweiterte Sicherheit für Azure DevOps

Microsoft bringt die Funktionen von GHAS in Azure DevOps ein, da die Kunden schon seit einer Weile danach gefragt haben. Das ist ein Beispiel für die Art und Weise, wie beide Produkte jetzt betrieben werden, denn die neuen Funktionen werden zuerst für GitHub entwickelt. Wenn es sinnvoll ist, werden einige dieser Funktionen vielleicht auch in Azure DevOps integriert. Auch hier sehen Sie die Synergie: alle bekannten geheimen Scanmuster von GHAS können auch in Azure DevOps verwendet werden, da sie zwischen den Unternehmen ausgetauscht werden können.

So starten Sie mit GitHub Advanced Security für Azure DevOps

Zunächst müssen Sie die erweiterte Sicherheit auf Repository-Ebene aktivieren, wofür Sie natürlich Zugriff auf die Ebene des Projektadministrators benötigen: Nachdem Sie die Funktion aktiviert haben (für jedes Repository einzeln, da es Sie in Zukunft Lizenzsitze kosten wird), erhalten Sie eine neue Registerkarte 'Erweiterte Sicherheit' in Ihrem Repository-Menü. Hier sehen Sie die Ergebnisse der Scans, die in Ihrem Repository durchgeführt wurden. Nachdem Sie die Funktion aktiviert haben, erhalten Sie einige zusätzliche Menüoptionen links und rechts sowie zusätzliche Aufgaben für Ihre Azure Pipelines.

Heimliches Scannen einschalten

Das Scannen von Geheimnissen wird automatisch aktiviert, wenn Sie die erweiterte Sicherheit einschalten. Es wird ein Hintergrundjob gestartet, der Ihr Repository nach Geheimnissen durchsucht. Es wird auch die gesamte Historie Ihres Repositorys gescannt: alle Commits und Branches werden auf bekannte geheime Muster überprüft. Eine zusätzliche Funktion ist der "Push-Schutz". Damit wird verhindert, dass Sie einen Commit pushen, der ein Geheimnis enthält. Dies ist eine großartige Funktion, um zu verhindern, dass Geheimnisse in Ihr Repository gepusht werden und um den Zustrom neuer Alerts zu stoppen.

Scannen von Abhängigkeiten verwenden

Um mit dem Dependency Scanning zu beginnen, müssen Sie es in eine Pipeline einfügen. Dazu fügen Sie die folgende Aufgabe zu Ihrer Pipeline hinzu:

- Aufgabe: AdvancedSecurity-Abhängigkeits-Scanning@1

Wenn diese Pipeline das nächste Mal ausgeführt wird, durchsucht sie Ihr Repository nach bekannten Manifestdateien, wie .csproj für C#-Projekte oder package.json für NodeJS-Projekte. Anhand dieser Manifestdateien sammelt sie Informationen über die Pakete, die Sie einbinden, und kann das zugrunde liegende Ökosystem auch auf die Abhängigkeiten dieser Pakete überprüfen (Bibliotheken bauen auch auf anderen Bibliotheken auf). Es prüft dann, ob die von Ihnen verwendeten Pakete Sicherheitslücken aufweisen. Sie können jedes Paket, das Sie verwenden, und auch alle seine Abhängigkeiten mit ihren Versionsnummern in der National Vulnerability Database(NVD ) des NIST-Instituts überprüfen. In der NVD ist auch vermerkt, welche Version nicht mehr angreifbar ist (falls zutreffend). Auf GitHub werden diese Informationen verwendet, um eine Pull-Anfrage zu erstellen, um das Paket auf eine neuere Version zu aktualisieren, die die Sicherheitslücke nicht aufweist. Auch die Erstellung von Pull Requests für Versionsaktualisierungen kann automatisiert werden. Dies ist für GitHub Advanced Security für Azure DevOps nicht verfügbar. Ich gehe davon aus, dass dies später hinzugefügt wird, aber bis dahin müssen Sie die Pull Requests selbst erstellen. In der Meldung erhalten Sie Informationen über die von Ihnen verwendete Paketversion, die erste nicht verwundbare Version sowie die Art der Sicherheitslücke, so dass Sie sich über die Art des Angriffsvektors für diese Meldung informieren können.

Code Scanning verwenden

Um das Code-Scanning zu aktivieren, müssen Sie CodeQL auch in eine Azure-Pipeline injizieren (andere SAST-Tools funktionieren ebenfalls, solange sie eine SARIF-Datei hochladen):

- Aufgabe: AdvancedSecurity-Codeql-Init@1
  Eingaben:
  Sprachen: 'csharp'  

- Aufgabe: AdvancedSecurity-Codeql-Autobuild@1

- Aufgabe: AdvancedSecurity-Codeql-Analyze@1

- Aufgabe: AdvancedSecurity-Publish@1

Hier gibt es ein paar Schritte zu beachten:

1. Init erstellt eine lokale, leere Datenbank, die mit allen Codepfaden gefüllt wird, die Ihr Code einnimmt (zum Beispiel: Methode A ruft Methode B auf). Außerdem füttern Sie es mit einer der unterstützten Sprachen (C#, Java, C/C++, Python, JavaScript/TypeScript, Go oder Ruby).
2. Der Auto-Build-Schritt versucht, Ihre Anwendung auf der Grundlage bekannter Muster für die von Ihnen gewählte Sprache zu erstellen. Manchmal schlägt die automatische Erstellung bei bestimmten Projekten fehl. In diesem Fall können Sie Ihre eigenen Erstellungsschritte an deren Stelle setzen.
3. Mit Analyze führen Sie alle CodeQL-Abfragen gegen die Datenbank aus, die in Schritt 1 erstellt wurde. Dabei wird auch eine SARIF-Datei erstellt, die alle Ergebnisse der Abfragen enthält (wenn eine Abfrage ein Ergebnis hat, wird daraus ein Alert).
4. Mit dem Schritt Veröffentlichen wird die SARIF-Datei tatsächlich zum Advanced Security Service hochgeladen, der Ihnen dann die Ergebnisse in der Benutzeroberfläche anzeigt.

Die Abfragen, die ausgeführt werden, finden Sie im CodeQL-Repository auf github.com. Es gibt einen Standardsatz mit niedrigen Rauschverhältnissen, aber Sie können auch erweiterte Abfragen verwenden, indem Sie sie so konfigurieren:

- Aufgabe: AdvancedSecurity-Codeql-Analyze@1
  Eingaben:
  querysuite: 'Sicherheit und Qualität'

Beachten Sie, dass Sie dies in Azure DevOps in der Aufgabe Analyze konfigurieren, während Sie dies in GitHub in dem Schritt Init tun.

Seien Sie sich bewusst, dass das Hinzufügen von umfangreicheren Abfragen die Dauer der Pipeline sowie die Anzahl der Warnmeldungen erhöht: Die erweiterten Abfragen haben etwas mehr Rauschen und möglicherweise auch mehr Fehlalarme. In meiner Demoanwendung habe ich zum Beispiel von 4 normalen Warnmeldungen auf 7 zusätzliche Warnmeldungen erhöht, als ich die erweiterten Abfragen von security-and-quality hinzugefügt habe. Wir raten Ihnen, diese Abfragen zumindest auf eine Pull-Anfrage hin durchzuführen und einen Zeitplan zu erstellen: Die Community, die diese Abfragen erstellt, ist sehr aktiv (150 bis 200 Pull-Anfragen pro Monat in diesem Repository), so dass Sie neue Abfragen erhalten werden, die möglicherweise Schwachstellen in Ihrem Code finden. Wenn ein Ergebnis der Abfragen vorliegt, sehen Sie dies auch in den Protokollen: Nach dem Hochladen der SARIF-Datei erhalten Sie die generierten Warnmeldungen in der Übersicht Erweiterte Sicherheit: Wenn Sie eine Meldung öffnen, erhalten Sie auf der Detailseite weitere Informationen: Von hier aus können Sie wiederum mehr über die gefundene Schwachstelle erfahren, mit Links zurück zur Common Weakness Enumeration-Nummer (CWE) auf der Mitre-Website.

Umgang mit den Warnungen

Um die Warnungen zu beheben, müssen Sie den Fund selbst beheben. Es gibt noch keine Möglichkeit, die Warnungen in Azure DevOps zu deaktivieren (etwas, das wir auf der GitHub-Seite haben).

Behebung geheimer Scan-Warnungen

Beim Scannen von Geheimnissen zeigt die Benutzeroberfläche derzeit die Warnung an, dass Sie dieses Geheimnis als durchgesickerten Wert behandeln müssen, und dass eine Korrektur nur durch Widerruf des Geheimnisses möglich ist. Da es noch keine Möglichkeit gibt, diese Warnung über die Benutzeroberfläche zu deaktivieren, besteht die einzige Möglichkeit, diese Warnung loszuwerden, darin, den Verlauf des Repositorys umzuschreiben, so dass die Übergabe nicht mehr im Verlauf enthalten ist. Ich gehe davon aus, dass das Abstellen von Warnungen in der Zukunft hinzugefügt wird, aber im Moment ist dies die einzige Möglichkeit, die Warnung loszuwerden.

Behebung von Warnungen bei der Überprüfung von Abhängigkeiten

Um einen Alert für die Überprüfung von Abhängigkeiten loszuwerden, müssen Sie einen Pull Request erstellen, um die Abhängigkeit auf eine Version zu aktualisieren, die nicht mehr anfällig ist. Wenn die Erkennungsprüfung erneut läuft, wird die Warnung geschlossen. Sie haben einen Link zurück zu der Pipeline, die festgestellt hat, dass die verwundbare Abhängigkeit nicht mehr vorhanden ist:

Adressierung von Code-Scan-Warnungen

Die Behebung von Code-Scanning-Warnungen ist etwas aufwändiger, da Sie den Code, der die Warnung verursacht, tatsächlich beheben müssen. Nachdem Sie das Problem behoben haben, schließt der nächste Scan die Warnung und verweist auf den Scan, der die Warnung geschlossen hat. Von dort aus können Sie auch den Commit finden, der das Problem behoben hat, so dass Sie eine durchgängige Rückverfolgbarkeit haben. Beachten Sie, dass Sie derzeit keinen Code von der CodeQL-Überprüfung ausschließen können (auf GitHub können Sie das). Das bedeutet auch, dass z.B. Ihre Unit-Test-Suite ebenfalls gescannt wird. Mit etwas Glück werden auch dort Probleme gefunden (ich hatte das gleiche Problem mit meinem Testprojekt).

Dashboarding

Für einen Gesamtüberblick darüber, wie es um das gesamte Projekt oder die gesamte Organisation steht, müssen Sie sich Microsoft Defender for DevOps ansehen, ein Tool in Microsoft Azure. Da ich Defender noch nicht integriert habe (ich glaube, Sie brauchen ein Feature-Flag, um das zu aktivieren), habe ich noch keine Screenshots. Ich werde sie hinzufügen, sobald ich Zugang dazu habe! Die Integration macht aus der Azure-Perspektive durchaus Sinn und wird in die Tools integriert, die die Leute in der Azure Cloud verwenden. Aber wenn Sie nur Azure DevOps verwenden, dann würde ich eine Übersicht erwarten, um wiederkehrende Muster oder Abhängigkeiten auch in Ihrer Azure DevOps Organisation zu finden. Es würde mich nicht überraschen, wenn sie diese Übersicht in der Zukunft hinzufügen würden.

Zusammenfassend

Insgesamt sind die meisten der anfänglichen Funktionen bereits integriert, wobei definitiv einige andere Entscheidungen getroffen wurden als bei der Implementierung von GitHub (z.B. Dashboarding). Sie sehen, dass wir noch ganz am Anfang stehen, aber ich gehe davon aus, dass der Rest der Funktionen bzw. die Feinabstimmung schnell erfolgen wird, jetzt, wo der erste Teil integriert wurde (was oft die meiste Arbeit ist). Wir haben jetzt gute Sicherheitsfunktionen in Azure DevOps integriert, direkt in die Entwicklererfahrung, und genau dort muss dies meiner Meinung nach landen: bei den Leuten, die auf die Ergebnisse reagieren und sie frühzeitig in ihrem Prozess beheben können. Ich hoffe, dass als Nächstes das Äquivalent zur Überprüfung von Abhängigkeiten in Azure DevOps integriert wird, so dass auch Entwickler in die Lage versetzt werden, das Leck (von eingehenden anfälligen Abhängigkeiten) zu stoppen.