Anpassen der Codeüberprüfung

Informationen zum Konfigurieren von code scanning

Du kannst code scanning mit GitHub Actions in GitHub AE oder auf deinem Continuous Integration(CI)-System ausführen. Weitere Informationen findest du unter Informationen zu GitHub Actions oder Informationen zur CodeQL-Codeüberprüfung in deinem CI-System.

In diesem Artikel wird die Ausführung von code scanning in GitHub AE mithilfe von Aktionen behandelt.

Bevor du die code scanning für ein Repository anpassen kannst, musst du die code scanning konfigurieren, indem du dem Repository einen Workflow für GitHub Actions hinzufügst. Weitere Informationen findest du unter Konfigurieren der Codeüberprüfung für ein Repository.

Normalerweise musst du die generierte Workflowdatei für code scanning nicht bearbeiten. Falls erforderlich, kannst du den Workflow jedoch bearbeiten, um einige der Einstellungen anzupassen. Du kannst z. B. den CodeQL-Analyseworkflow von GitHub bearbeiten, um die Häufigkeit der Scans, die zu scannenden Sprachen oder Verzeichnisse und was CodeQL code scanning in deinem Code sucht anzugeben. Möglicherweise musst du auch den CodeQL-Analyseworkflow bearbeiten, wenn du bestimmte Befehle verwendest, um deinen Code zu kompilieren.

Die CodeQL-Analyse ist nur eine Art von code scanning, die du in GitHub durchführen kannst. GitHub Marketplace enthält andere code scanning-Workflows, die du verwenden kannst. Die in diesem Artikel angegebenen konkreten Beispiele beziehen sich auf die CodeQL-Analyseworkflow-Datei.

Bearbeiten eines code scanning-Workflows

In GitHub werden Workflowdateien im .github/workflows-Verzeichnis des Repositorys gespeichert. Du findest einen Workflow, den du hinzugefügt hast, indem du nach seinem Dateinamen suchst. Beispielsweise ist der Name der Workflowdatei für CodeQL code scanning standardmäßig auf codeql-analysis.yml festgelegt.

1. Navigiere in deinem Repository zu der Workflow-Datei, die du bearbeiten möchtest.
2. Klicke zum Öffnen des Workflow-Editors oben rechts in der Dateiansicht auf .
3. Nachdem du die Datei bearbeitet hast, klicke auf Starr commit (Commit starten), und fülle das Formular „Commit changes“ (Änderungen committen) aus. Du kannst einen Commit direkt in den aktuellen Branch committen oder einen neuen Branch erstellen und einen Pull Request starten.

Weitere Informationen zum Bearbeiten von Workflowdateien findest du unter Informationen zu GitHub Actions.

Konfigurieren der Häufigkeit

Du kannst den CodeQL-Analyseworkflow konfigurieren, um Code na Zeitplan zu überprüfen oder wenn bestimmte Ereignisse in einem Repository auftreten.

Scanning code on every push to the repository, and every time a pull request is created, prevents developers from introducing new vulnerabilities and errors into the code. Das Überprüfen von Code nach einem Zeitplan informiert dich über die neuesten Sicherheitsrisiken und Fehler, die GitHub, Sicherheitsexperten und die Community entdecken, auch wenn Entwickler das Repository nicht aktiv verwalten.

Überprüfen bei Push

Standardmäßig wird vom CodeQL-Analyseworkflow das on.push-Ereignis dazu verwendet, bei jeder Pushübertragung zum Standardbranch des Repositorys sowie zu geschützten Branches eine Codeüberprüfung auszulösen. Damit code scanning auf einem bestimmten Branch ausgelöst wird, muss der Workflow in diesem Branch vorhanden sein. Weitere Informationen findest du unter Workflowsyntax für GitHub Actions.

Wenn du beim Pushen eine Überprüfung durchführst, werden die Ergebnisse auf der Registerkarte Sicherheit für das Repository angezeigt. Weitere Informationen findest du unter Verwalten von Codescanwarnungen für dein Repository.

Wenn eine on:push-Überprüfung ein Ergebnis zurückgibt, das einem offenen Pull Request zugeordnet werden kann, werden diese Warnungen für den Pull Request automatisch am gleichen Ort wie andere Pull Request-Warnungen angezeigt. Die Warnungen werden identifiziert, indem die vorhandene Analyse des HEAD des Branch mit der Analyse für den Zielbranch verglichen wird. Weitere Informationen zu code scanning-Warnungen in Pull Requests findest du unter Filtern von Codescanbenachrichtigungen in Pull-Anforderungen.

Überprüfen von Pull Requests

Im Standard-CodeQL-Analyseworkflow wird das pull_request-Ereignis dazu verwendet, eine Codeüberprüfung bei Pull Requests auszulösen, die sich auf den Standardbranch beziehen. Wenn ein Pull Request von einem privaten Fork ausgeht, wird das pull_request-Ereignis nur ausgelöst, wenn du in den Repositoryeinstellungen die Option „Run workflows from fork pull requests“ (Workflows von forkbasierten Pull Requests ausführen) ausgewählt hast. Weitere Informationen findest du unter Verwalten von GitHub Actions-Einstellungen für ein Repository.

Weitere Informationen zum pull_request-Ereignis findest du unter Ereignisse zum Auslösen von Workflows.

Wenn du Pull Requests scannst, werden die Ergebnisse als Warnungen in einer Pull Request-Überprüfung angezeigt. Weitere Informationen findest du unter Filtern von Codescanbenachrichtigungen in Pull-Anforderungen.

Wenn du den pull_request-Trigger verwendest, der so konfiguriert ist, dass anstelle des HEAD-Commits der Mergecommit des Pull Requests überprüft wird, führt dies zu effizienteren und genaueren Ergebnissen als eine HEAD-Überprüfung für den Branch bei jedem Pushvorgang. Wenn du jedoch ein CI/CD-System verwendest, das nicht für das Auslösen bei Pull Requests konfiguriert werden kann, kannst du trotzdem den on:push-Trigger verwendest. Von code scanning werden die Ergebnisse dann offenen Pull Requests für den Branch zugeordnet. Die Warnungen werden als Anmerkungen für den Pull Request hinzugefügt. Weitere Informationen findest du unter Anpassen der Codeüberprüfung.

Vermeiden unnötiger Überprüfungen von Pull Requests

Möglicherweise möchtest du 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. Du kannst dies konfigurieren, indem du im code scanning-Workflow on:pull_request:paths-ignore oder on:pull_request:paths festlegst. Wenn die einzigen Änderungen in einem Pull Request z. B. Dateien mit den Dateierweiterungen .md oder .txt sind, kannst du das folgende paths-ignore-Array verwenden.

on:
  push:
    branches: [main, protected]
  pull_request:
    branches: [main]
    paths-ignore:
      - '**/*.md'
      - '**/*.txt'

Weitere Informationen dazu, wie mithilfe von on:pull_request:paths-ignore und on:pull_request:paths ermittelt wird, wann ein Workflow für einen Pull Request ausgeführt wird, findest du unter Workflowsyntax für GitHub Actions.

Scannen nach einem Zeitplan

Wenn du den standardmäßigen CodeQL-Analyseworkflow ausführst, überprüft der Workflow zusätzlich zu den von Ereignissen ausgelösten Überprüfungen einmal wöchentlich den Code in deinem Repository. Um diesen Zeitplan anzupassen, bearbeite den cron-Wert im Workflow. Weitere Informationen findest du unter Workflowsyntax für GitHub Actions.

Beispiel

Im folgenden Beispiel wird ein CodeQL-Analyseworkflow für ein bestimmtes Repository angezeigt, das einen Standardbranch mit der Bezeichnung main und einen geschützten Branch mit der Bezeichnung protected aufweist.

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

Angeben eines Betriebssystems

Wenn dein Code ein bestimmtes Betriebssystem zum Kompilieren benötigt, kannst du das Betriebssystem in deinem CodeQL-Analyseworkflow konfigurieren. Bearbeite den Wert jobs.analyze.runs-on, um das Betriebssystem für den Computer anzugeben, auf dem die code scanning-Aktionen ausgeführt werden.

jobs:
  analyze:
    name: Analyze
    runs-on: [ubuntu-latest]

Wenn du einen selbstgehosteten Runner für die Codeüberprüfung verwenden möchtest, kannst du ein Betriebssystem mithilfe einer geeigneten Bezeichnung als zweites Element in einem aus zwei Elementen bestehenden Array nach self-hosted angeben.

jobs:
  analyze:
    name: Analyze
    runs-on: [self-hosted, ubuntu-latest]

CodeQL code scanning unterstützt die neuesten Versionen von Ubuntu, Windows und macOS. Typische Werte für diese Einstellung sind daher: ubuntu-latest, windows-latestund macos-latest. Weitere Informationen findest du unter Auswählen des Runners für einen Auftrag und unter Verwenden von Bezeichnungen mit selbstgehosteten Runnern.

Wenn du einen selbstgehosteten Runner verwendest, musst du sicherstellen, dass Git in der Variable PATH enthalten ist. Weitere Informationen findest du unter Informationen zu selbstgehosteten Runnern und Selbst-gehostete Runner hinzufügen.

Empfohlene Spezifikationen (RAM, CPU-Kerne und Datenträger) für die Ausführung einer CodeQL-Analyse auf selbstgehosteten Computern findest du unter Empfohlene Hardwareressourcen zum Ausführen von CodeQL.

Angeben des Speicherorts für CodeQL-Datenbanken

Im Allgemeinen musst du dir keine Gedanken darüber machen, wo CodeQL-Analyseworkflow-Datenbanken vom CodeQL platziert werden, da in späteren Schritten automatisch Datenbanken ermittelt werden, die in vorherigen Schritten erstellt wurden. Wenn du jedoch einen benutzerdefinierten Workflowschritt schreibst, der es erforderlich macht, dass sich die CodeQL-Datenbank an einem bestimmten Speicherort des Datenträgers befindet, z. B. zum Hochladen der Datenbank als Workflowartefakt, kannst du diesen Speicherort mithilfe des Parameters db-location unter der Aktion init angeben.

- uses: github/codeql-action/init@v2
  with:
    db-location: '${{ github.workspace }}/codeql_dbs'

Vom CodeQL-Analyseworkflow wird erwartet, dass der im Parameter db-location angegebene Pfad beschreibbar ist und entweder nicht vorhanden oder ein leeres Verzeichnis ist. Wenn du diesen Parameter in einem Auftrag verwendest, der auf einem selbstgehosteten Runner ausgeführt oder für den ein Docker-Container verwendet wird, ist es die Verantwortung des Benutzers, sicherzustellen, dass das ausgewählte Verzeichnis zwischen den Ausführungen gelöscht wird oder dass die Datenbanken entfernt werden, sobald sie nicht mehr benötigt werden.

Wenn dieser Parameter nicht verwendet wird, werden vom CodeQL-Analyseworkflow-Datenbanken an einem eigenständig gewählten temporären Speicherort erstellt.

Ändern der analysierten Sprachen

Von CodeQL code scanning wird in den unterstützten Sprachen geschriebener Code automatisch erkannt.

• C/C++
• C#
• Go
• Java
• JavaScript/TypeScript
• Python
• Ruby

Weitere Informationen findest du in der Dokumentation zur CodeQL-Website: Unterstützte Sprachen und Frameworks.

Die CodeQL-Analyseworkflow-Standarddatei enthält eine Matrix namens language, in der die analysierten Sprachen in deinem Repository aufgeführt sind. Von CodeQL wird diese Matrix automatisch gefüllt, wenn du code scanning einem Repository hinzufügst. Mithilfe der language-Matrix wird CodeQL dahin gehend optimiert, dass die einzelnen Analysen parallel ausgeführt werden. Aufgrund der Leistungsvorteile der Parallelisierung von Builds wird empfohlen, dass alle Workflows diese Konfiguration übernehmen. Weitere Informationen zu Matrizen findest du unter Verwenden von Matrizen für deine Aufträge.

Wenn Ihr Repository Code in mehreren der unterstützten Sprachen enthält, können Sie auswählen, welche Sprachen Sie analysieren möchten. Es gibt mehrere Gründe, warum Sie verhindern möchten, dass eine Sprache analysiert wird. Das Projekt kann z. B. Abhängigkeiten in einer anderen Sprache als der Haupttextkörper des Codes aufweisen, und Sie möchten möglicherweise keine Warnungen für diese Abhängigkeiten anzeigen.

Wenn die language-Matrix vom Workflow verwendet wird, wird CodeQL hartcodiert, sodass nur die Sprachen in der Matrix analysiert werden. Um die Sprachen zu ändern, die du analysieren möchtest, bearbeite den Wert der Matrixvariablen. Du kannst eine Sprache entfernen, um zu verhindern, dass sie analysiert wird, oder du kannst eine Sprache hinzufügen, die beim Konfigurieren der code scanning nicht im Repository vorhanden war. Wenn das Repository beispielsweise anfänglich nur JavaScript enthielt, als die code scanning konfiguriert wurde, und du später Python-Code hinzugefügt hast, musst du der Matrix python hinzufügen.

jobs:
  analyze:
    name: Analyze
    ...
    strategy:
      fail-fast: false
      matrix:
        language: ['javascript', 'python']

Wenn dein Workflow keine Matrix mit der Bezeichnung language enthält, wird CodeQL so konfiguriert, dass die Analyse sequenziell ausgeführt wird. Wenn du keine Sprachen im Workflow angibst, erkennt CodeQL automatisch alle unterstützten Sprachen im Repository und versucht, diese zu analysieren. Wenn du ohne Verwendung einer Matrix auswählen möchtest, welche Sprachen analysiert werden sollen, kannst du den languages-Parameter unter der init-Aktion verwenden.

- uses: github/codeql-action/init@v2
  with:
    languages: cpp, csharp, python

Definieren der Warnungsschweregrade, die zu Überprüfungsfehlern bei Pull Requests führen

Standardmäßig führen bei der Überprüfung von Pull Requests nur Warnungen mit dem Schweregrad Error oder dem Sicherheitsschweregrad Critical oder High zu einem Fehler, und eine Überprüfung mit Warnungen mit niedrigeren Schweregraden ist weiterhin erfolgreich. Du kannst die Stufen von Warnungsschweregraden und Sicherheitsschweregraden in deinen Repositoryeinstellungen ändern, die bei der Überprüfung von Pull Requests zu einem Fehler führen. Weitere Informationen zu Schweregraden findest du unter Informationen zu Codeüberprüfungswarnungen.

1. Navigiere auf dein Unternehmen zur Hauptseite des Repositorys. 1. Wähle unter dem Namen deines Repositorys die Option Einstellungen aus. Wenn die Registerkarte „Einstellungen“ nicht angezeigt wird, wähle im Dropdownmenü die Option Einstellungen aus.

   

2. Klicke im Abschnitt „Sicherheit“ auf der Randleiste auf Codesicherheit und -analyse.

3. Verwende unter „Code scanning“ rechts neben „Überprüfungsfehler“ das Dropdownmenü, um den Schweregrad auszuwählen, den du als Auslöser für einen Pull-Request-Überprüfungsfehler festlegen möchtest.

Konfigurieren einer Kategorie für die Analyse

Verwende category, um zwischen mehreren Analysen für dasselbe Tool und denselben Commit zu unterscheiden, die jedoch für verschiedene Sprachen oder Teile des Codes ausgeführt werden. Die Kategorie, die du im Workflow angibst, wird in die SARIF-Ergebnisdatei aufgenommen.

Dieser Parameter ist besonders nützlich, wenn du mit Monorepos arbeitest und mehrere SARIF-Dateien für verschiedene Komponenten des Monorepo besitzen.

    - name: Perform CodeQL Analysis
      uses: github/codeql-action/analyze@v2
      with:
        # Optional. Specify a category to distinguish between multiple analyses
        # for the same tool and ref. If you don't use `category` in your workflow,
        # GitHub will generate a default category name for you
        category: "my_category"

Wenn du keinen category-Parameter im Workflow angibst, wird von GitHub AE ein Kategoriename für dich generiert, der auf dem Namen der Workflowdatei, die die Aktion auslöst, dem Aktionsnamen und allen Matrixvariablen basiert. Beispiel:

• Der Workflow .github/workflows/codeql-analysis.yml und die Aktion analyze erzeugen die Kategorie .github/workflows/codeql.yml:analyze.
• Der Workflow .github/workflows/codeql-analysis.yml, die Aktion analyze und die Matrixvariablen {language: javascript, os: linux} erzeugen die Kategorie .github/workflows/codeql-analysis.yml:analyze/language:javascript/os:linux.

Der category-Wert wird als Eigenschaft <run>.automationDetails.id in SARIF v2.1.0 angezeigt. Weitere Informationen findest du unter SARIF-Unterstützung für die Codeüberprüfung.

Die Details des runAutomationDetails-Objekts in der SARIF-Datei werden, sofern enthalten, von der angegebenen Kategorie nicht überschrieben.

Ausführen zusätzlicher Abfragen

Wenn du CodeQL zum Überprüfen von Code verwendest, generiert die CodeQL-Analyse-Engine eine Datenbank anhand des Codes und führt Abfragen darin aus. Die CodeQL-Analyse verwendet einen standardmäßigen Abfragesatz, aber du kannst zusätzlich zu den Standardabfragen weitere auszuführende Abfragen angeben.

Alle zusätzlichen Abfragen, die du ausführen möchtest, müssen zu einem QL-Paket in einem Repository gehören. Weitere Informationen findest du unter Informationen zu Codescans mit CodeQL.

Du kannst eine einzelne QL-Datei, ein Verzeichnis mit mehreren QL-Dateien, eine QLS-Definitionsdatei für eine Abfragesammlung oder eine beliebige Kombination angeben. Weitere Informationen zur Definition von Abfragesammlungen findest du unter Erstellen von CodeQL-Abfragesammlungen.

Füge zum Hinzufügen mindestens einer Abfrage innerhalb des Abschnitts uses: github/codeql-action/init@v2 des Workflows einen with: queries:-Eintrag hinzu. Wenn sich die Abfragen in einem privaten Repository befinden, verwende den Parameter external-repository-token, um ein Token anzugeben, das Zugriff zum Auschecken des privaten Repositorys hat.

Du kannst auch Abfragesammlungen im Wert von queries angeben. Abfragesammlungen sind Sammlungen von Abfragen, die in der Regel nach Zweck oder Sprache gruppiert sind.

- uses: github/codeql-action/init@v2
  with:
    # Comma-separated list of queries / packs / suites to run. 
    # This may include paths or a built in suite, for example:
    # security-extended or security-and-quality.
    queries: security-extended
    # Optional. Provide a token to access queries stored in private repositories.
    external-repository-token: ${{ secrets.ACCESS_TOKEN }}

Die folgenden Abfragesuiten sind in CodeQL code scanning integriert und stehen zur Verwendung zur Verfügung.

Jede dieser Abfragesammlungen enthält eine andere Teilmenge der Abfragen, die im integrierten CodeQL-Abfragepaket für diese Sprache enthalten sind. Die Abfragesammlungen werden automatisch mithilfe der Metadaten für jede Abfrage generiert. Weitere Informationen findest du unter Metadaten für CodeQL-Abfragen.

In der Hilfedokumentation zu CodeQL-Abfragen findest du Informationen dazu, wie du ermitteln kannst, in welchen Abfragesammlungen eine Abfrage enthalten ist. Für jede Abfrage werden alle Sammlungen, in denen sie enthalten ist, oben auf der Seite mit den Abfragemetadaten angezeigt. Beispiel: Arbiträrer Dateischreibvorgang während der ZIP-Extraktion („ZIP Slip“) und Clientseitige Anforderungsverfälschung.

Wenn du eine Abfragesuite angibst, wird das CodeQL-Analysemodul den Standardsatz von Abfragen und alle zusätzlichen Abfragen ausführen, die in der zusätzlichen Abfragesuite definiert sind.

Wenn du auch eine Konfigurationsdatei für benutzerdefinierte Einstellungen verwendest, werden alle in deinem Workflow angegebenen zusätzlichen Abfragen anstelle der in der Konfigurationsdatei angegebenen Komponenten verwendet. Wenn du eine Kombination zusätzlicher Abfragen ausführen möchtest, musst du den Wert von queries im Workflow mit dem Symbol + als Präfix versehen. Weitere Informationen findest du unter Erstellen einer benutzerdefinierten Konfigurationsdatei.

Im folgenden Beispiel wird mit dem Symbol + sichergestellt, dass die angegebenen zusätzlichen Abfragen zusammen mit allen angegebenen Komponenten in der Konfigurationsdatei verwendet werden, auf die verwiesen wird.

- uses: github/codeql-action/init@v2
  with:
    config-file: ./.github/codeql/codeql-config.yml
    queries: +security-and-quality,octo-org/python-qlpack/show_ifs.ql@main

Verwenden einer benutzerdefinierten Konfigurationsdatei

Eine benutzerdefinierte Konfigurationsdatei ist eine alternative Möglichkeit, zusätzliche Abfragen anzugeben, die ausgeführt werden sollen. Du kannst die Datei auch verwenden, um die Standardabfragen zu deaktivieren und um festzulegen, welche Verzeichnisse während der Analyse überprüft werden sollen.

Verwende in der Workflowdatei den config-file-Parameter der init-Aktion, um den Pfad zur Konfigurationsdatei anzugeben, die du verwenden möchtest. In diesem Beispiel wird die Konfigurationsdatei ./.github/codeql/codeql-config.yml geladen.

- uses: github/codeql-action/init@v2
  with:
    config-file: ./.github/codeql/codeql-config.yml

Die Konfigurationsdatei kann sich in dem Repository befinden, das du analysierst, oder in einem externen Repository. Mithilfe eines externen Repositorys können Sie Konfigurationsoptionen für mehrere Repositorys an einem zentralen Ort angeben. Wenn du auf eine Konfigurationsdatei verweist, die sich in einem externen Repository befindet, kannst du die OWNER/REPOSITORY/FILENAME@BRANCH -Syntax verwenden. Beispiel: octo-org/shared/codeql-config.yml@main

Wenn sich die Konfigurationsdatei in einem externen privaten Repository befindet, verwende den external-repository-token-Parameter der init-Aktion, um ein Token anzugeben, das Zugriff auf das private Repository besitzt.

- uses: github/codeql-action/init@v2
  with:
    external-repository-token: ${{ secrets.ACCESS_TOKEN }}

Die Einstellungen in der Konfigurationsdatei werden im YAML-Format geschrieben.

Angeben zusätzlicher Abfragen

Du gibst zusätzliche Abfragen in einem queries-Array an. Jedes Element des Arrays enthält einen uses-Parameter mit einem Wert, der eine einzelne Abfragedatei, ein Verzeichnis mit Abfragedateien oder eine Abfragesammlungs-Definitionsdatei identifiziert.

queries:
  - uses: ./my-basic-queries/example-query.ql
  - uses: ./my-advanced-queries
  - uses: ./query-suites/my-security-queries.qls

Optional kannst du jedem Arrayelement einen Namen geben, wie in den folgenden Beispielkonfigurationsdateien gezeigt. Weitere Informationen zu zusätzlichen Abfragen findest du oben unter Ausführen zusätzlicher Abfragen.

Deaktivieren der Standardabfragen

Wenn du nur benutzerdefinierte Abfragen ausführen möchtest, kannst du die Standardsicherheitsabfragen mit disable-default-queries: true deaktivieren.

Angeben der zu scannenden Verzeichnisse

Für die von CodeQL unterstützten interpretierten Sprachen (Python, Ruby, und JavaScript/TypeScript) kannst du die code scanning auf Dateien in bestimmten Verzeichnissen beschränken, indem du der Konfigurationsdatei ein paths-Array hinzufügst. Du kannst die Dateien in bestimmten Verzeichnissen von der Analyse ausschließen, indem du ein paths-ignore-Array hinzufügst.

paths:
  - src
paths-ignore:
  - src/node_modules
  - '**/*.test.js'

Wenn du bei kompilierten Sprachen code scanning auf bestimmte Verzeichnisse in deinem Projekt beschränken möchtest, musst du die entsprechenden Buildschritte im Workflow angeben. Welche Befehle du verwenden musst, um ein Verzeichnis aus dem Buildvorgang auszuschließen, hängt von deinem Buildsystem ab. Weitere Informationen findest du unter Konfigurieren des CodeQL-Workflows für kompilierte Sprachen.

Du kannst kleine Teile eines Monorepositorys schnell analysieren, wenn du Code in bestimmten Verzeichnissen änderst. Du musst sowohl Verzeichnisse in den Buildschritten ausschließen als auch die Schlüsselwörter paths-ignore und paths für on.<push|pull_request> in deinem Workflow verwenden.

Beispielkonfigurationsdateien

Diese Konfigurationsdatei fügt die Abfragesammlung security-and-quality zur Liste der Abfragen hinzu, die von CodeQL beim Scannen deines Codes ausgeführt werden. Weitere Informationen zu den verfügbaren Abfragesammlungen findest du unter Ausführen zusätzlicher Abfragen.

name: "My CodeQL config"

queries:
  - uses: security-and-quality

Die folgende Konfigurationsdatei deaktiviert die Standardabfragen und gibt stattdessen eine Reihe von benutzerdefinierten Abfragen an, die ausgeführt werden sollen. Außerdem wird CodeQL so konfiguriert, dass Dateien im Verzeichnis src (relativ zum Stammverzeichnis) überprüft werden. Ausgenommen davon sind das Verzeichnis src/node_modules und Dateien, deren Name auf .test.js endet. Dateien in src/node_modules und Dateien mit Namen, die auf .test.js enden, werden daher von der Analyse ausgeschlossen.

name: "My CodeQL config"

disable-default-queries: true

queries:
  - name: Use an in-repository QL pack (run queries in the my-queries directory)
    uses: ./my-queries
  - name: Use an external JavaScript QL pack (run queries from an external repo)
    uses: octo-org/javascript-qlpack@main
  - name: Use an external query (run a single query from an external QL pack)
    uses: octo-org/python-qlpack/show_ifs.ql@main
  - name: Use a query suite file (run queries from a query suite in this repo)
    uses: ./codeql-qlpacks/complex-python-qlpack/rootAndBar.qls

paths:
  - src 
paths-ignore: 
  - src/node_modules
  - '**/*.test.js'

Konfigurieren von code scanning für kompilierte Sprachen

Für die unterstützten kompilierten Sprachen kannst du den Code mithilfe der autobuild-Aktion im CodeQL-Analyseworkflow erstellen. So wird vermieden, dass du explizite Buildbefehle für C/C++, C#, und Java angeben musst. Für diese Sprachen analysiert CodeQL die Quelldateien in deinem Repository, die erstellt werden. Für jede dieser Sprachen kannst du autobuild deaktivieren und stattdessen benutzerdefinierte Buildbefehle verwenden, um nur die Dateien zu analysieren, die von diesen benutzerdefinierten Befehlen erstellt werden.

Wenn bei autobuild ein Fehler auftritt oder du andere Quelldateien als die durch den Prozess autobuild erstellten Dateien analysieren möchtest, musst du den Schritt autobuild aus dem Workflow entfernen und manuell Buildschritte hinzufügen. Für C/C++-, C#-, Go, und Java-Projekte analysiert CodeQL den Quellcode, der von den von dir angegebenen Buildschritten erstellt wird. Weitere Informationen zum Konfigurieren der code scanning in CodeQL für kompilierte Sprachen findest du unter Konfigurieren des CodeQL-Workflows für kompilierte Sprachen.

Hochladen von code scanning-Daten in GitHub

You can display code analysis from a third-party tool in GitHub by adding the upload-sarif action to your workflow. Du kannst Codeanalysedaten mit der Aktion upload-sarif hochladen. Weitere Informationen findest du unter Hochladen einer SARIF-Datei in GitHub.