ドキュメントには頻繁に更新が加えられ、その都度公開されています。本ページの翻訳はまだ未完成な部分があることをご了承ください。最新の情報については、英語のドキュメンテーションをご参照ください。本ページの翻訳に問題がある場合はこちらまでご連絡ください。

コードスキャンを設定する

GitHub がプロジェクトのコードをスキャンして脆弱性やエラーを検出する方法を設定できます。

People with write permissions to a repository can configure code scanning for the repository.

Code scanning is available for all public repositories, and for private repositories owned by organizations where GitHub Advanced Security is enabled. 詳しい情報については、「GitHub Advanced Security について」を参照してください。

code scanning の設定について

GitHub Actionsを使って、あるいは継続的インテグレーション(CI)システムから、GitHub上でcode scanningを実行できます。 詳しい情報については「GitHub Actionsについて」あるいは 「CIシステムでのCodeQL code scanningについて」を参照してください。

この記事は、Actionsを使ってGitHub 上で code scanning を実行することについて説明しています。

リポジトリに code scanning を設定する前に、リポジトリに GitHub Actions ワークフローを追加して code scanning をセットアップする必要があります。 詳しい情報については、「リポジトリに対する code scanning をセットアップする」を参照してください。

通常、code scanning のデフォルトのワークフローを編集する必要はありません。 ただし、必要な場合にはワークフローを編集して設定の一部をカスタマイズできます。 たとえば、GitHubのCodeQL分析ワークフローを編集して、スキャンの頻度、スキャンする言語やディレクトリ、CodeQL code scanningがコード中で探すものを指定できます。 コードのコンパイルに特定のコマンドセットを使っている場合にも、CodeQL分析ワークフローを編集する必要があるかもしれません。

CodeQL 解析は、GitHub で実行できる code scanning のほんの一例に過ぎません。 GitHub Marketplaceは、使用可能な他のcode scanningワークフローを含みます。 セキュリティタブからアクセスできる"Get started with code scanning"ページ上には、それらの選択肢があります。この記事で示されている例は、CodeQL分析ワークフローファイルに関連しています。

Editing a code scanning workflow

GitHub は、リポジトリの .github/workflows ディレクトリにワークフローファイルを保存します。 ファイル名を検索して、追加済みのワークフローを見つけることができます。 For example, the default workflow file for CodeQL code scanning is called codeql-analysis.yml.

  1. リポジトリで、編集したいワークフローファイルにアクセスします。
  2. ファイルビューの右上隅の をクリックしてワークフローエディタを開きます。 ワークフローファイルの編集ボタン
  3. ファイルを編集したら、[Start commit] をクリックして、[Commit changes] フォームに入力します。 現在のブランチに直接コミットするか、新しいブランチを作成してプルリクエストを開始するかを選択できます。 codeql.yml ワークフローの更新をコミットする

ワークフローファイルの編集に関する詳しい情報については、「GitHub Actions を学ぶ」を参照してください。

頻度を設定する

スケジュール設定されているときや、リポジトリで特定のイベントが発生したときに、コードをスキャンできます。

リポジトリへのプッシュごと、およびプルリクエストが作成されるたびにコードをスキャンすることで、開発者がコードに新しい脆弱性やエラーをもたらすことを防ぎます。 スケジュールに従ってコードをスキャンすると、開発者がリポジトリを積極的に維持していない場合でも、GitHub、セキュリティ研究者、コミュニティが発見した最新の脆弱性とエラーが通知されます。

プッシュ時にスキャンする

デフォルトのワークフローを使用する場合、code scanning は、イベントによってトリガーされるスキャンに加えて、リポジトリ内のコードを週に1回スキャンします。 このスケジュールを調整するには、ワークフローで cron 値を編集します。 詳細については、「GitHub Actionsのワークフロー構文」を参照してください。

プッシュ時にスキャンするなら、結果はリポジトリの Security(セキュリティ)タブに表示されます。 詳しい情報については、「リポジトリの コードスキャンアラートを管理する」を参照してください。

Additionally, when an on:push scan returns results that can be mapped to an open pull request, these alerts will automatically appear on the pull request in the same places as other pull request alerts. The alerts are identified by comparing the existing analysis of the head of the branch to the analysis for the target branch. For more information on code scanning alerts in pull requests, see "Triaging code scanning alerts in pull requests."

プルリクエストをスキャンする

デフォルトの CodeQL分析ワークフロー は、pull_request イベントを使用して、デフォルトブランチに対するプルリクエストのコードスキャンをトリガーします。 Pull Requestがプライベートフォークからのものであれば、リポジトリの設定で"Run workflows from fork pull requests(フォークのPull Requestからワークフローを実行)"オプションを選択している場合にのみpull_requestイベントはトリガーされます。 For more information, see "Managing GitHub Actions settings for a repository."

pull_request イベントに関する詳しい情報については、「"GitHub Actionsのためのワークフローの構文」を参照してください。

Pull Requestをスキャンすると、その結果はPull Requestチェック内のアラートとして表示されます。 詳しい情報については、「プルリクエストでコードスキャンアラートをトリアージする」を参照してください。

Using the pull_request trigger, configured to scan the pull request's merge commit rather than the head commit, will produce more efficient and accurate results than scanning the head of the branch on each push. However, if you use a CI/CD system that cannot be configured to trigger on pull requests, you can still use the on:push trigger and code scanning will map the results to open pull requests on the branch and add the alerts as annotations on the pull request. For more information, see "Scanning on push."

Defining the severities causing pull request check failure

By default, only alerts with the severity level of Error or security severity level of Critical or High will cause a pull request check failure, and a check will still succeed with alerts of lower severities. You can change the levels of alert severities and of security severities that will cause a pull request check failure in your repository settings. For more information about severity levels, see "Managing code scanning alerts for your repository."

  1. GitHub.comで、リポジトリのメインページにアクセスしてください。
  2. リポジトリ名の下で Settings(設定)をクリックしてください。 リポジトリの設定ボタン
  3. 左のサイドバーで、Security & analysis(セキュリティと分析)をクリックしてください。 リポジトリ設定の"セキュリティと分析"タブ
  4. Under "Code scanning", to the right of "Check Failure", use the drop-down menu to select the level of severity you would like to cause a pull request check failure.

チェック失敗の設定

プルリクエストの不要なスキャンを回避する

どのファイルが変更されたかに関わらず、デフォルトブランチに対する特定のプルリクエストにコードスキャンがトリガーされることを避けたい場合もあるでしょう。 これを設定するには、code scanning ワークフローで on:pull_request:paths-ignore または on:pull_request:paths を指定します。 たとえば、プルリクエストにおける変更が、.md または .txt のファイル拡張子を持つファイルである場合、次の paths-ignore 配列を使用できます。

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

注釈

  • on:pull_request:paths-ignoreon:pull_request:paths は、ワークフローのアクションがプルリクエストで実行されるかどうかを決定する条件を設定します。 アクションが実行されたときにどのファイルが解析__されるかは決定しません。 プルリクエストに、on:pull_request:paths-ignore または on:pull_request:paths にマッチしないファイルが含まれている場合、ワークフローはそのアクションを実行し、on:pull_request:paths-ignore または on:pull_request:paths にマッチするものを含む、プルリクエストにおいて変更されたすべてのファイルをスキャンします。ただし、除外されているファイルは除きます。 ファイルを解析から除外する方法については、「スキャンするディレクトリを指定する」を参照してください。
  • For CodeQL code scanning ワークフローファイルに対しては、on:push イベントで paths-ignorepaths といったキーワードは使用しないでください。解析に漏れが生じる恐れがあります。 正確な結果を得るには、CodeQL code scanning が新しい変更を前回のコミットの解析と比較できる必要があります。

on:pull_request:paths-ignoreon:pull_request:paths を使用して、プルリクエストに対していつワークフローを実行するかを決定することに関する詳しい情報については、「GitHub Actions のワークフロー構文」を参照してください。

スケジュールに従ってスキャンする

デフォルトの code scanning ワークフローは、pull_request イベントを使用して、プルリクエストの HEAD コミットでコードスキャンをトリガーします。 このスケジュールを調整するには、ワークフローで cron 値を編集します。 詳しい情報については、「GitHub Actions のワークフロー構文」を参照してください。

注釈: GitHub は、デフォルトのブランチのワークフローにあるスケジュール設定されたジョブのみを実行します。 他のブランチのワークフローでスケジュールを変更しても、ブランチをデフォルトブランチにマージするまで影響はありません。

サンプル

以下の例は、デフォルトブランチの名前が main で、protected という保護されたブランチがある特定のリポジトリに対する CodeQL分析ワークフロー を示しています。

on:
  push:
    branches: [main, protected]
  pull_request:
    branches: [main]
  schedule:
    - cron: '20 14 * * 1'

このワークフローは、次をスキャンします。

  • デフォルトブランチと保護されたブランチに対する全てのプッシュ
  • デフォルトブランチに対する全てのプルリクエスト
  • 毎週月曜の14:20 UTCにデフォルトブランチ

オペレーティングシステムを指定する

コードのコンパイルに特定のオペレーティングシステムが必要な場合は、そのオペレーティングシステムを CodeQL分析ワークフロー で設定できます。 jobs.analyze.runs-on の値を編集して、code scanning のアクションを実行するマシンのオペレーティングシステムを指定します。

Code Scanningにセルフホストランナーを使うことにしたなら、self-hosted の後に、2 つの要素がある配列の 2 番目の要素として適切なラベルを使用し、オペレーティングシステムを指定できます。

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

詳しい情報については、「セルフホストランナーについて」および「セルフホストランナーを追加する」を参照してください。

Code scanning は、macOS、Ubuntu、Windows の最新バージョンをサポートしています。 したがって、この設定の典型的な値はubuntu-latestwindows-latestmacos-latestになります。 詳しい情報については、「GitHub Actionsのワークフロー構文」を参照してください。

セルフホストランナーを使っているなら、GitがPATH変数内にあるようにしなければなりません。

CodeQLデータベースの場所の指定

一般に、CodeQL分析ワークフローがCodeQLデータベースを置く場所について気にする必要はありません。これは、以前のステップで作成されたデータベースを後のステップは自動的に見つけるからです。 ただし、たとえばこのデータベースをワークフローの成果物としてアップロードするといったような、CodeQLデータベースが特定のディスク上の場所にあることを必要とするカスタムのワークフローステップを書いているなら、initアクションの下でdb-locationを使って場所を指定することもできます。

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

CodeQL分析ワークフローは、db-locationで提供されたパスが書き込み可能であり、存在しないか空のディレクトリであることを期待します。 セルフホストランナー上で動作するか、Dockerコンテナを使うジョブでこのパラメータを使う場合、選択されたディレクトリが実行間でクリアされること、あるいは不要になったらデータベースが削除されることを保証するのはユーザの責任です。 This is not necessary for jobs running on GitHub-hosted runners, which obtain a fresh instance and a clean filesystem each time they run. For more information, see "About GitHub-hosted runners."

このパラメータが使われなければ、CodeQL分析ワークフローはデータベースを自分が選択した一時的な場所に作成します。

解析される言語を変更する

CodeQL code scanningは、自動的にサポートする言語で書かれたコードを検出します。

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

Note: CodeQL analysis for Ruby is currently in beta. During the beta, analysis of Ruby will be less comprehensive than CodeQL analysis of other languages.

For more information, see the documentation on the CodeQL website: "Supported languages and frameworks."

デフォルトのCodeQL分析ワークフローファイルには、分析されたリポジトリ中の言語がリストされたlanguageというビルドマトリクスが含まれます。 CodeQLは、code scanningがリポジトリに追加されたときにこのマトリクスを自動的に作成します。 languageマトリクスを使うことで、CodeQLが各分析を並列に実行するよう最適化されます。 並列ビルドのパフォーマンスのメリットから、すべてのワークフローはこの設定を採用することをおすすめします。 ビルドマトリクスに関する詳しい情報については「複雑なワークフローの管理」を参照してください。

リポジトリがサポートされている言語を複数含む場合、分析したい言語を選択できます。 言語が分析されないようにする理由はいくつかあります。 たとえば、プロジェクトには、コードの本文とは異なる言語の依存関係があり、それらの依存関係のアラートを表示する必要がない場合があります。

ワークフローがlanguageマトリクスを使っているなら、CodeQLはマトリクス中の言語だけを分析するようにハードコードされています。 分析する言語を変更したいなら、マトリクス変数の値を編集してください。 解析されないように言語を削除したり、code scanningをセットアップしたときにはリポジトリ中になかった言語を追加したりできます。 たとえば、code scanningがセットアップされた初期にはリポジトリ中にJavaScriptしかなく、後からPythonのコードを追加したなら、マトリクスにpythonを追加する必要があるだけです。

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

ワークフローがlanguageというマトリクスを含まないなら、CodeQLは分析を順次実行するように設定されます。 ワークフロー中で言語を指定していない場合、CodeQLはリポジトリ中のサポートされている言語を検出し、分析しようとします。 マトリクスを使わずに分析する言語を選択したい場合は、initアクションの下でlanguagesパラメータが利用できます。

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

追加のクエリを実行する

Linuxだけを使うGitHubがホストしているランナーでは、CodeQL分析ワークフローはCodeQLの分析にさらなる結果を加えるためにPythonの依存関係を自動的にインストールしようとします。 この動作は、"Initialize CodeQL"ステップで呼ばれるアクションのsetup-python-dependenciesパラメータを指定して制御できます。 デフォルトでは、このパラメータはtrueに設定されます:

  • リポジトリがPythonで書かれたコードを含むなら、"Initialize CodeQL"ステップは必要な依存関係をGitHubがホストするランナーにインストールします。 自動インストールが成功したら、このアクションは環境変数のCODEQL_PYTHONを依存関係を含むPythonの実行可能ファイルに設定することもします。

  • リポジトリがPythonの依存関係を持たない場合、あるいは依存関係が予想外の方法で指定されている場合、警告が示されてアクションは残りのジョブを継続します。 依存関係の解釈に問題があってもアクションの実行は成功することがありますが、結果は不完全かも知れません。

あるいは、任意のオペレーティングシステムにおいて手動でPythonの依存関係をインストールできます。 以下のワークフローの抜粋に示すとおり、setup-python-dependenciesを追加してfalseに設定するとともに、CODEQL_PYTHONを依存関係を含むPythonの実行可能ファイルに設定しなければなりません。

jobs:
  CodeQL-Build:
    runs-on: ubuntu-latest
    permissions:
      security-events: write
      actions: read

    steps:
      - name: Checkout repository
        uses: actions/checkout@v2
      - name: Set up Python
        uses: actions/setup-python@v2
        with:
          python-version: '3.x'
      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          if [ -f requirements.txt ];
          then pip install -r requirements.txt;
          fi
          # Set the `CODEQL-PYTHON` environment variable to the Python executable
          # that includes the dependencies
          echo "CODEQL_PYTHON=$(which python)" >> $GITHUB_ENV
      - name: Initialize CodeQL
        uses: github/codeql-action/init@v1
        with:
          languages: python
          # Override the default behavior so that the action doesn't attempt
          # to auto-install Python dependencies
          setup-python-dependencies: false

分析のカテゴリの設定

categoryを使って、同じツールやコミットに対して行われる、ただし様々な言語やコードの様々な部分に対して行われる複数の分析を区別してください。 ワークフロー中で指定したカテゴリは、SARIF結果ファイルに含まれます。

このパラメータは、特に単一リポジトリで作業をしていて、単一リポジトリの様々なコンポーネントに対して複数のSARIFファイルがある場合に有益です。

    - name: Perform CodeQL Analysis
      uses: github/codeql-action/analyze
      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"

ワークフローでcategoryを指定しない場合、GitHubはアクションをトリガーしたワークフロー名、アクション名、任意のマトリクス変数に基づいてカテゴリ名を生成します。 例:

  • .github/workflows/codeql-analysis.ymlワークフローとanalyzeアクションは、.github/workflows/codeql.yml:analyzeというカテゴリを生成します。
  • .github/workflows/codeql-analysis.ymlワークフロー、analyzeアクション、マトリクス変数{language: javascript, os: linux}は、.github/workflows/codeql-analysis.yml:analyze/language:javascript/os:linuxというカテゴリを生成します。

categoryの値は、SARIF v2.1.0で<run>.automationDetails.idプロパティに現れます。 詳しい情報については「code scanningの SARIF サポート」を参照してください。

指定したカテゴリは、SARIFファイルファイルにrunAutomationDetailsが含まれている場合、その詳細を上書きしません。

追加のクエリを実行する

コードをスキャンするためにCodeQLを使う場合、CodeQL分析エンジンはコードからデータベースを生成し、それに対してクエリを実行します。 CodeQLの分析はデフォルトのクエリセットを使いますが、デフォルトのクエリに加えてもっと多くのクエリを実行するよう指定することもできます。

You can run extra queries if they are part of a CodeQL pack (beta) published to the GitHub コンテナレジストリ or a QL pack stored in a repository. For more information, see "About code scanning with CodeQL."

The options available to specify the additional queries you want to run are:

  • packs to install one or more CodeQL query packs (beta) and run the default query suite or queries for those packs.
  • queries to specify a single .ql file, a directory containing multiple .ql files, a .qls query suite definition file, or any combination. クエリスイートの定義に関する詳しい情報については「CodeQLクエリスイートの作成」を参照してください。

You can use both packs and queries in the same workflow.

github/codeql/cpp/ql/src@mainというように、github/codeqlリポジトリから直接クエリスイートを参照することはおすすめしません。 そういったクエリは、他のクエリで使われるのと同じCodeQLのバージョンでコンパイルされているとは限らないので、分析の際にエラーが生じるかもしれません。

Using CodeQL query packs

Note: The CodeQL package management functionality, including CodeQL packs, is currently in beta and subject to change.

To add one or more CodeQL query packs (beta), add a with: packs: entry within the uses: github/codeql-action/init@v1 section of the workflow. Within packs you specify one or more packages to use and, optionally, which version to download. Where you don't specify a version, the latest version is downloaded. If you want to use packages that are not publicly available, you need to set the GITHUB_TOKEN environment variable to a secret that has access to the packages. For more information, see "Authentication in a workflow" and "Encrypted secrets."

Note: For workflows that generate CodeQL databases for multiple languages, you must instead specify the CodeQL query packs in a configuration file. For more information, see "Specifying CodeQL query packs" below.

In the example below, scope is the organization or personal account that published the package. When the workflow runs, the three CodeQL query packs are downloaded from GitHub and the default queries or query suite for each pack run. The latest version of pack1 is downloaded as no version is specified. Version 1.2.3 of pack2 is downloaded, as well as the latest version of pack3 that is compatible with version 1.2.3.

- uses: github/codeql-action/init@v1
  with:
    # Comma-separated list of packs to download
    packs: scope/pack1,scope/pack2@1.2.3,scope/pack3@~1.2.3

Using queries in QL packs

1つ以上のクエリスイートを追加するには、設定ファイルに queries セクションを追加します。 If the queries are in a private repository, use the external-repository-token parameter to specify a token that has access to checkout the private repository.

- uses: github/codeql-action/init@v1
  with:
    queries: COMMA-SEPARATED LIST OF PATHS
    # Optional. Provide a token to access queries stored in private repositories.
    external-repository-token: ${{ secrets.ACCESS_TOKEN }}

設定ファイルでこれらを指定して、追加のクエリスイートを実行することもできます。 クエリスイートはクエリのコレクションであり、通常は目的または言語ごとにグループ化されています。

以下のクエリスイートはCodeQL code scanningに組み込まれており、利用可能です。

クエリスイート説明
security-extendedデフォルトのクエリよりも重要度と精度が低いクエリ
security-and-qualitysecurity-extended からのクエリ、および保守性と信頼性に関するクエリ

クエリスイートを指定すると、CodeQLの分析エンジンは、デフォルトのクエリセットに加えてスイート内に含まれるクエリを実行します。

Working with custom configuration files

If you also use a configuration file for custom settings, any additional packs or queries specified in your workflow are used instead of those specified in the configuration file. If you want to run the combined set of additional packs or queries, prefix the value of packs or queries in the workflow with the + symbol. 設定ファイルの例については、「Example configuration files」を参照してください。

In the following example, the + symbol ensures that the specified additional packs and queries are used together with any specified in the referenced configuration file.

- uses: github/codeql-action/init@v1
  with:
    config-file: ./.github/codeql/codeql-config.yml
    queries: +security-and-quality,octo-org/python-qlpack/show_ifs.ql@main
    packs: +scope/pack1,scope/pack2@v1.2.3
    

サードパーティのコードスキャンツールを使用する

A custom configuration file is an alternative way to specify additional packs and queries to run. You can also use the file to disable the default queries and to specify which directories to scan during analysis.

ワークフローファイル中では、initアクションのconfig-fileパラメータを使って使用したい設定ファイルのパスを指定してください。 この例では、設定ファイル ./.github/codeql/codeql-config.yml を読み込みます。

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

設定ファイルは、分析しようとしているリポジトリ内、あるいは外部のリポジトリに配置できます。 外部リポジトリを利用すると、複数のリポジトリに対する設定オプションを一カ所で指定できます。 外部リポジトリにある設定ファイルを参照する際には、OWNER/REPOSITORY/FILENAME@BRANCHという構文が利用できます。 たとえばocto-org/shared/codeql-config.yml@mainといったようにします。

設定ファイルが外部のプライベートリポジトリにあるなら、initアクションのexternal-repository-token パラメータを使ってそのプライベートリポジトリにアクセスできるトークンを指定してください。

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

設定ファイル内の設定は、YAMLフォーマットで書かれます。

Specifying CodeQL query packs

Note: The CodeQL package management functionality, including CodeQL packs, is currently in beta and subject to change.

You specify CodeQL query packs in an array. Note that the format is different from the format used by the workflow file.

packs: 
  # Use the latest version of 'pack1' published by 'scope'
  - scope/pack1 
  # Use version 1.23 of 'pack2' 
  - scope/pack2@v1.2.3
  # Use the latest version of 'pack3' compatible with 1.23
  - scope/pack3@~1.2.3

If you have a workflow that generates more than one CodeQL database, you can specify any CodeQL query packs to run in a custom configuration file using a nested map of packs.

packs:
  # Use these packs for JavaScript analysis
  javascript:
    - scope/js-pack1
    - scope/js-pack2
  # Use these packs for Java analysis
  java:
    - scope/java-pack1
    - scope/java-pack2@v1.0.0

追加のクエリを指定する

追加のクエリはqueries配列内で指定します。 この配列の各要素には、1つのクエリファイル、クエリファイルを含むディレクトリ、あるいはクエリスイートの定義ファイルを指定する値を持つusesパラメータが含まれます。

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

あるいは、以下の設定ファイルの例にあるように、配列の各要素に名前を与えることもできます。 追加クエリに関する詳しい情報については、上の「追加のクエリを実行する」を参照してください。

デフォルトのクエリを無効にする

カスタムクエリのみを実行する場合は、構成ファイルに disable-default-queries: true を追加して、デフォルトのセキュリティクエリを無効にすることができます。

スキャンするディレクトリを指定する

For the interpreted languages that CodeQL supports (Python, Ruby and JavaScript/TypeScript), you can restrict code scanning to files in specific directories by adding a paths array to the configuration file. paths-ignore配列を追加することで、指定されたディレクトリ内のファイルを分析から除外できます。

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

ノート:

  • code scanning 設定ファイルのコンテキストで使用される paths および paths-ignore キーワードは、ワークフロー中でon.<push|pull_request>.pathsに使われる同じキーワードと混同しないでください。 ワークフローのon.<push|pull_request>を変更するときに使用する場合、これらは指定されたディレクトリのコードを誰かが変更した時にアクションが実行されるかどうかを決定します。 詳細については、「GitHub Actionsのワークフロー構文」を参照してください。
  • フィルタパターンキャラクタの?+[]!はサポートされておらず、そのままマッチします。
  • ** Note: ** characters can only be at the start or end of a line, or surrounded by slashes, and you can't mix ** and other characters. たとえば、foo/****/foo、および foo/**/bar はすべて使用できる構文ですが、**foo は使用できません。 ただし、例に示すように、単一の を他の文字と一緒に使用できます。 ``キャラクタを含むものは、引用符で囲む必要があります。

コンパイル言語の場合、プロジェクト中の特定のディレクトリにcode scanningを限定したいなら、ワークフロー中で適切なビルドステップを指定しなければなりません。 ビルドからディレクトリを除外するために使用するコマンドは、ビルドシステムによって異なります。 詳しい情報については、「コンパイル型言語の CodeQL ワークフローを設定する」を参照してください。

特定のディレクトリのコードを変更すると、monorepo の一部をすばやく分析できます。 ビルドステップでディレクトリを除外し、ワークフローファイルで on.<push|pull_request>paths-ignore および paths キーワードを使用する必要があります。

設定ファイルの例

この設定ファイルは、コードのスキャン時に CodeQL によって実行されるクエリのリストに security-and-quality クエリスイートを追加します。 使用可能なクエリスイートの詳細については、「追加のクエリを実行する」を参照してください。

name: "My CodeQL config"

queries:
  - uses: security-and-quality

以下の設定ファイルはデフォルトのクエリを無効化し、その代わりに実行するカスタムクエリのセットを指定します。 また、CodeQLがsrc/node_modulesディレクトリと.test.jsで名前が終わるファイルを除く、srcディレクトリ(ルートに対する相対)内のファイルをスキャンするようにも設定します。 したがって、 src/node_modules内のファイル や、.test.jsで名前が終わるファイルは分析から除外されます。

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'

コンパイルされた言語の code scanning を設定する

サポートされているコンパイル言語では、コードをビルドするためにCodeQL分析ワークフロー内でautobuildアクションを使うことができます。 これによって、C/C++、C#、Javaでは明示的にビルドコマンドを指定する必要がなくなります。 CodeQLは、プロジェクトをセットアップするためにGoのプロジェクトのビルドも実行します。 ただし、他のコンパイル言語とは対照的に、リポジトリ内のGoのファイルはビルドされるものだけでなく、すべてが展開されます。 ビルドが処理しないGoのファイルの展開をスキップするために、カスタムのビルドコマンドを使うこともできます。

リポジトリ内の C/C++、C#、またはJava のコードに非標準のビルドプロセスがある場合、 autobuild が失敗することがあります。 ワークフローからautobuildステップを取り除き、手動でビルドのステップを追加する必要があるでしょう。 リポジトリのGoのファイルで展開するものを指定したい場合には、ビルドのステップを追加しなければなりません。コンパイルされた言語で CodeQL code scanning を設定する方法に関する詳しい情報については、「コンパイルされた言語の CodeQL を設定する」を参照してください。

code scanning 用の設定ファイルを作成できます。

GitHubは、サードパーティのツールによって外部で生成されたコード分析データを表示できます。 ワークフローに upload-sarif アクションを追加することで、GitHub のサードパーティツールからのコード分析を表示できます。 詳しい情報については、「SARIF ファイルを GitHub にアップロードする」を参照してください。

このドキュメントは役立ちましたか?

プライバシーポリシー

これらのドキュメントを素晴らしいものにするのを手伝ってください!

GitHubのすべてのドキュメントはオープンソースです。間違っていたり、はっきりしないところがありましたか?Pull Requestをお送りください。

コントリビューションを行う

OR, コントリビューションの方法を学んでください。

問題がまだ解決していませんか?