Konfigurieren von Codescans
Sie können konfigurieren, wie GitHub den Code in Ihrem Projekt auf Sicherheitsrisiken und Fehler scannt. Wenn Sie Ihre eigene Konfiguration auswählen, sparen Sie Zeit und entscheiden über die am besten geeignete Häufigkeit von Codescans für Ihr Projekt. In dieser Lerneinheit lernen Sie die Grundlagen der Codescankonfiguration kennen. Außerdem erfahren Sie, wie Sie die Häufigkeit von Scans konfigurieren und sie so planen, dass sie Ihren Repository- und Entwicklungsanforderungen am besten entsprechen.
Wie in den vorherigen Lerneinheiten erläutert wurde, können Sie Codescans auf GitHub, mit GitHub Actions oder über Ihr CI-System (Continuous Integration) ausführen. Wenn Sie die Option "Erweiterte Einrichtung" auf GitHub auswählen, wird eine anpassbare Workflowdatei generiert, die Sie dann direkt in Ihr Repository übernehmen können. In der Regel müssen Sie diesen Workflow nicht bearbeiten. Bei Bedarf können Sie jedoch einige der Einstellungen anpassen.
Sie können z. B. den CodeQL-Analyseworkflow von GitHub bearbeiten, um die Häufigkeit von Scans, die zu scannenden Sprachen oder Verzeichnisse und die in Ihrem Code durch CodeQL-Codescans zu suchenden Elemente anzugeben. Möglicherweise müssen Sie auch den CodeQL-Analyseworkflow bearbeiten, wenn Sie einen bestimmten Satz von Befehlen verwenden, um Ihren Code zu kompilieren. Die CodeQL-Analyse ist nur eine Art von Codescans, die Sie in GitHub ausführen können. GitHub Marketplace enthält mehrere andere Codescanworkflows.
Wechseln von Standard zu erweitertem Setup für die Codeüberprüfung
Wenn Sie bereits ein Repository für die Codeüberprüfung mit der Standardsetupmethode eingerichtet haben, können Sie in den Einstellungen zum erweiterten Setup wechseln. Navigieren Sie zum Abschnitt Codeüberprüfung unter Einstellungen > Erweiterte Sicherheit und wählen Sie dann das Symbol mit den drei Punkten (...) aus. Wählen Sie im Dropdownmenü Zu Erweitert wechseln aus. Folgen Sie dann den Anweisungen zum Deaktivieren von CodeQL, und aktivieren Sie sie erneut mit der generierten Workflowdatei des erweiterten Setups.
Bearbeiten des Codeüberprüfungsworkflows
GitHub speichert Workflowdateien im Github/Workflows-Verzeichnis Ihres Repositorys. Sie finden einen Workflow, den Sie hinzugefügt haben, indem Sie nach seinem Dateinamen suchen. Die Workflowdatei für das CodeQL-Code-Scanning heißt beispielsweise standardmäßig codeql-analysis.yml.
Führen Sie die folgenden Schritte aus, um eine Workflowdatei zu bearbeiten:
- Um den Workflow-Editor zu öffnen, wählen Sie das Symbol "Bearbeiten" in der oberen rechten Ecke der Dateiansicht aus.
Nehmen Sie Ihre Änderungen vor.
Nachdem Sie die Datei bearbeitet haben, wählen Sie Commit-Änderungen aus, und schließen Sie das Commit-Änderungsformular ab. Sie können einen Commit direkt in den aktuellen Branch committen oder einen neuen Branch erstellen und einen Pull Request starten.
In den folgenden Abschnitten werden einige gängige Konfigurationsoptionen für Codescans beschrieben.
Konfigurieren der Häufigkeit
Eine häufige Bearbeitung der Workflowdatei besteht darin, die Häufigkeit anzupassen, mit der Codescans durchgeführt werden. Sie können den CodeQL-Analyseworkflow so konfigurieren, dass Code nach einem Zeitplan überprüft wird oder wenn bestimmte Ereignisse in einem Repository auftreten. Sie können die Workflowdatei auch bearbeiten, um Code zu scannen, wenn jemand eine Änderung überträgt und wann immer eine Pullanforderung erstellt wird. Durch das Anpassen dieser Häufigkeit können Sie verhindern, dass Entwickler*innen neue Sicherheitsrisiken und Fehler im Code einführen. Das Überprüfen des Codes nach einem Zeitplan stellt sicher, dass Sie stets über die neuesten Sicherheitsrisiken und Fehler informiert sind, die GitHub, Sicherheitsexpert*innen und die Community entdecken – auch wenn das Repository nicht aktiv von Entwickler*innen verwaltet wird.
Scannen per Tastendruck
Standardmäßig verwendet der CodeQL-Analyseworkflow das on:push-Ereignis, um bei jedem Pushvorgang an den Standardbranch des Repositorys und an alle geschützten Branches einen Codescan auszulösen. Damit ein Codescan für einen angegebenen Branch ausgelöst wird, muss der Workflow in diesem Branch vorhanden sein. Wenn Sie auf Push scannen, werden die Ergebnisse auf der Registerkarte "Sicherheit " für Ihr Repository angezeigt.
Wenn eine on:push-Überprüfung ein Ergebnis zurückgibt, das einem offenen Pull Request zugeordnet werden kann, werden diese Warnungen zudem automatisch am gleichen Ort wie andere Pull Request-Warnungen für den Pull Request angezeigt. Die Warnungen werden identifiziert, indem die vorhandene Analyse des HEAD des Branch mit der Analyse für den Zielbranch verglichen wird.
Scannen bei Pull Request
Der CodeQL-Analysestandardworkflow verwendet das pull_request-Ereignis, um einen Codescan bei Pull Requests auszulösen, die sich auf den Standardbranch beziehen. Wenn ein Pull Request aus einem privaten Fork stammt, wird das pull_request-Ereignis nur ausgelöst, wenn Sie in den Repositoryeinstellungen die Option „Workflows aus Fork-Pull Requests ausführen“ ausgewählt haben. Wenn Sie Pull Requests überprüfen, werden die Ergebnisse als Warnungen in einer Pull Request-Überprüfung angezeigt.
Wenn Sie den pull_request-Trigger verwenden, der zum Überprüfen des Pull Request-Mergecommits anstelle des Headcommits konfiguriert ist, führt dies zu effizienteren und genaueren Ergebnissen als die Überprüfung des Head-Abschnitts des Branches bei jedem Pushvorgang. Wenn Sie ein CI/CD-System (Continuous Integration und Continuous Delivery) verwenden, das nicht für das Auslösen bei Pull Requests konfiguriert werden kann, können Sie trotzdem den on:push-Trigger verwenden. Die Codeüberprüfungen ordnen die Ergebnisse dann offenen Pull Requests für den Branch zu und fügen die Warnungen als Anmerkungen für einen Pull Request hinzu.
Definieren der Schweregrade, die einen Fehler bei der Pull Request-Überprüfung verursachen
Standardmäßig verursachen nur Warnungen mit dem Schweregrad Error oder dem Sicherheitsschweregrad Critical oder High einen Fehler bei der Pull Request-Überprüfung.
Diese Fehler blockieren die Ausführung der Codeüberprüfung nicht, aber sie können die Zusammenführung je nach Repositoryregeln blockieren. Sie können Details zu Pull-Anforderungsfehlern auf der Registerkarte "Codeüberprüfungsbenachrichtigungen" unter "Sicherheit" anzeigen.
Sie können in den Repository-Einstellungen konfigurieren, welche Schweregrade zu Fehlschlägen bei Pull-Request-Prüfungen führen, oder dies über Repository-Regelsätze mithilfe der Regel „Codeüberprüfungsergebnisse erforderlich“ festlegen. Beide Mechanismen funktionieren, Regeln sind jedoch die moderne und bevorzugte Konfigurationsmethode.
- Navigieren Sie auf GitHub.com zur Hauptseite des Repositorys. Wählen Sie unter Ihrem Repositorynamen "Einstellungen" aus.
- Wählen Sie in der linken Randleiste "Erweiterte Sicherheit" aus.
- Im Abschnitt „Code-Scanning“ unter „Schutzregeln“ verwenden Sie das Dropdown-Menü, um den Schweregrad auszuwählen, bei dem ein Pull-Request-Prüfungsfehler ausgelöst werden soll.
Warnungen der Codeanalyse verantwortungsvoll prüfen und verwerfen
Das Beheben des Problems im Code ist die bevorzugte Vorgehensweise, um eine Warnung bei der Codeüberprüfung zu beheben. Einige Warnungen erfordern jedoch möglicherweise keine Codeänderung. Beispielsweise kann es sich bei der Warnung um ein falsch positives Ergebnis handeln, nur im Testcode angezeigt werden oder ein Risiko darstellen, das das Team nicht beheben möchte.
Verwerfen Sie Warnmeldungen nur, nachdem Sie die Warnungsdetails geprüft und den Grund bestätigt haben. Wenn Sie eine Warnung schließen, zeichnet GitHub den Grund für die Kündigung auf, entfernt die Warnung aus der aktuellen Warnungsanzahl, verschiebt sie in die geschlossene Liste und verhindert, dass derselbe Code in zukünftigen Scans dieselbe Warnung generiert. Die Kündigung gilt für alle Zweigniederlassungen.
Wählen Sie den Grund für die Kündigung sorgfältig aus, da sie Teil des Sicherheitsdatensatzes für das Repository wird. Sie können auch einen Kündigungskommentar hinzufügen, um die Entscheidung zu erläutern. Dieser Kommentar wird der Warnungszeitleiste hinzugefügt und kann künftige Audits, die Berichterstellung und Compliance-Überprüfungen unterstützen.
Verwenden Sie Kommentare, um Details zu erfassen, z. B.:
Warum die Warnung keine Codeänderung benötigt
Wer hat die Entscheidung überprüft
Ob die Entscheidung vorübergehend oder dauerhaft ist
Alle Ausgleichskontrollen oder Nachverfolgungsarbeiten
Für eine strengere Governance können Organisationen die delegierte Aufhebung von Warnungen verwenden, um festzulegen, wer Warnungen der Codeüberprüfung aufheben darf. Dadurch wird verhindert, dass Entwickler Sicherheitsergebnisse ohne Überprüfung schließen und einen verantwortlicheren Triageprozess erstellen.
Vermeiden unnötiger Scans von Pull Requests
Möglicherweise möchten Sie verhindern, dass ein Codescan für bestimmte Pull Requests ausgelöst wird, die sich auf den Standardbranch beziehen, und zwar unabhängig davon, welche Dateien geändert wurden. Sie können diese Einstellung konfigurieren, indem Sie on:pull_request:paths-ignore oder on:pull_request:paths im Codeüberprüfungsworkflow angeben. Wenn die einzigen Änderungen in einem Pull Request z. B. Dateien mit den Dateierweiterungen .md oder .txt sind, können Sie das folgende paths-ignore-Array verwenden.
on:
push:
branches: [main, protected]
pull_request:
branches: [main]
paths-ignore:
- '**/*.md'
- '**/*.txt'
Anpassen des Scanzeitplans
Wenn Sie den standardmäßigen CodeQL-Analyseworkflow verwenden, überprüft der Workflow den Code in Ihrem Repository einmal pro Woche an einem zufällig generierten Tag und Uhrzeit zusätzlich zu den Überprüfungen, die durch Ereignisse ausgelöst werden. Um diesen Zeitplan anzupassen, bearbeiten Sie den cron-Wert im Workflow.
Das folgende Beispiel zeigt einen CodeQL-Analyseworkflow für ein Repository mit einem Standardbranch namens main und einem geschützten Branch namens protected:
on:
push:
branches: [main, protected]
pull_request:
branches: [main]
schedule:
- cron: '20 14 * * 1'
Dieser Workflow scannt Folgendes:
Jeden Pushvorgang in den Standardbranch und den geschützten Branch
Jeden Pull Request an den Standardbranch
Den Standardbranch jeden Montag um 14:20 UTC
Verwenden Sie Copilot-Autofix-Vorschläge
GitHub Copilot Autofix hilft Entwicklern, Warnungen beim Scannen von Code zu beheben, indem gezielte Codeänderungen vorgeschlagen werden. Autofix verwendet Informationen aus der Warnung, der Codebasis und der Pullanforderung, um einen potenziellen Fix zu generieren. Sie benötigen kein separates GitHub Copilot-Abonnement, um Copilot Autofix zu verwenden. Sie ist für öffentliche Repositorys auf GitHub.com und für organisationseigene Repositorys mit aktivierter GitHub Codesicherheit verfügbar.
AutoFix-Vorschläge sind keine automatischen Korrekturen. Sie sind vorgeschlagene Änderungen, die wie jede andere Codeänderung überprüft, getestet und genehmigt werden müssen.
Beim Prüfen eines Autofix-Vorschlags:
Lesen Sie die Warnung, und verstehen Sie das Sicherheitsproblem.
Überprüfen Sie die vorgeschlagenen Codeänderungen.
Vergewissern Sie sich, dass der Fix die Warnung adressiert, ohne das beabsichtigte Verhalten zu ändern.
Führen Sie die Tests des Projekts und alle erforderlichen Sicherheitsprüfungen aus.
Ändern Sie den Vorschlag bei Bedarf.
Übernehmen Sie die Korrektur in den Pull Request.
Vergewissern Sie sich, dass die Codeüberprüfungswarnung aufgelöst wird, nachdem die Überprüfungen erneut ausgeführt wurden.
Wenn ein Autofix-Vorschlag nicht angebracht ist, weisen Sie den Vorschlag zurück, anstatt ihn anzuwenden. Wenn der Alarm selbst nicht behoben werden muss, verwerfen Sie den Alarm mit dem richtigen Grund und einem klaren Kommentar.