CodeQL の結果を理解する

  • 5 分

前のユニットでは、データベースを作成し、コードから抽出されたファイルをスキャンしました。 これで、結果を表示し、対処するセキュリティの脆弱性があるかどうかを判断できます。

解釈されたクエリ結果は、Visual Studio Code の CodeQL 拡張機能のソース コードに自動的に表示されます。 CodeQL CLI で生成される出力結果は、さまざまなツールで使用できるさまざまな形式にすることができます。

クエリの select ステートメントを変更することで、ソース コードでの分析結果の表示方法を制御できます。 クエリの開発中に他のユーザーが理解できるように、結果を明確にし、簡単にすることができます。 クエリ コンソールまたは Visual Studio Code の CodeQL 拡張機能で独自のクエリを記述する場合、選択できる内容に制約はありません。

GitHub コード スキャンでアラートを作成するクエリを使用する場合、または CodeQL CLI を使用して有効な分析結果を生成する場合は、 select ステートメントレポートの結果を必要な形式にする必要があります。

Copilot Autofix を使用した修復ワークフロー

CodeQL で問題が特定されたら、最も重要な手順は問題を解決することです。 GitHubは、アラートから提案された修正プログラムに直接移動できるようにすることで、検出と修復を統合します。

Copilot Autofix によるアラートの修復

[セキュリティ] タブで CodeQL アラートを開くと、影響を受けるコード、重大度、問題が発生した方法など、問題の詳細が表示GitHub。

対応しているアラートでは、Copilot Autofixも表示されます。

Copilot自動修正はアラートを分析し、提案された修正プログラムを生成します。 これには、以下のことが含まれます。

  • 問題を解決するコード変更
  • 問題が発生する理由の説明
  • 修正プログラムが問題に対処する方法に関するガイダンス

修正プログラムを手動でゼロから記述する代わりに、推奨される変更から始めます。

一般的なワークフローは次のようになります。

  1. CodeQL はワークフローで実行され、アラートが作成されます。
  2. アラートを開き、影響を受けるコードを確認します。
  3. Copilot Autofix が修正候補を生成します。
  4. 説明と提案された変更を確認します。
  5. 修正プログラムを適用すると、プル要求が作成されます。
  6. プルリクエストは、マージされる前に各種チェックが実行され、レビューされます。

このワークフローは、GitHub インターフェイスを離れることなく、検出を修復に直接接続します。

Copilot Autofix は、変更を自動的に適用することはありません。 修正プログラムのレビューと承認は、お客様の責任で行います。 これにより、以下のことが指定されます。

  • 修正はコードベースに合わせて調整されます。
  • 必要に応じて実装を調整できます。
  • 変更は、既存のレビュー プロセスを通過します。

自動修正は、次の場合に最も効果的です。

  • インジェクション リスクや安全でない API の使用など、一般的な脆弱性パターン。
  • 明確でローカライズされたコード変更で解決できる問題。

より複雑な問題の場合は、自動修正でガイダンスが提供される場合がありますが、修正プログラムを変更するか、カスタム ソリューションを実装する必要がある場合があります。

アラートで推奨される修正

自動修正を使用できない場合でも、一部のアラートには推奨される修正プログラムが含まれます。

次の推奨事項を示します。

  • 変更する必要があるコードの部分を強調表示します。
  • 問題を解決する方法に関するガイダンスを提供します。

修正プログラムを作成する際の出発点として、これらの提案を使用できます。

Dependabot を使用した依存関係の修復

すべての脆弱性がコードから取得されるわけではありません。 一部は依存関係によって導入されます。

Dependabot は、次の方法でこれらの問題に自動的に対処するのに役立ちます。

  • 脆弱な依存関係の検出。
  • 更新されたバージョンを使用してプル要求を作成する。
  • 修正内容を確認し、マージできるようになります。

これらのプル要求は、Autofix と同じワークフローに従います。

  1. 変更が提案されます。
  2. チェックが実行されます。
  3. 更新はレビューされ、マージされました。

これにより、依存関係の修復は、アプリケーション コードの問題を修正する方法と一致します。

修復ワークフローの自動化

GitHub Actionsを使用して、修正プログラムの処理方法を自動化できます。

たとえば、ワークフローでは次のことができます。

  • Autofix または Dependabot のプル リクエストに対してテストを実行します。
  • 重大度に基づいてラベルを適用します。
  • リスクの高い変更に対する承認が必要です。
  • リスクの低い更新プログラムを自動的にマージします。

これらのワークフローにより、修復が次のことが保証されます。

  • チーム全体で一貫性があります。
  • マージする前に検証済み。
  • 開発プロセスに統合されます。

検出から解決まで

完全なワークフローでは、次の操作を行います。

  1. CodeQL は脆弱性を検出します。
  2. Copilot Autofix は修正案を提案します。
  3. pull request が作成されます。
  4. GitHub Actions変更を検証します。
  5. 修正はレビューされ、マージされています。

CodeQL 分析と Copilot Autofix、Dependabot、ワークフロー自動化を組み合わせることで、問題を見つけるだけでなく、効率的に解決できるシステムを作成できます。

コード スキャンアラートに対処する

コード スキャンを設定して、リポジトリ内のコードを確認できます。 既定の CodeQL 分析、Microsoft 以外の分析、またはその他の種類の分析を使用できます。 結果のアラートは、リポジトリ内で互いに並んで表示されます。

GitHub の既定の CodeQL 分析には、Microsoft 以外のツールやカスタム クエリの結果よりも多くのアラートのプロパティが含まれる場合があります。 既定のワークフローでは、コード スキャンによって、既定のブランチとプル要求中にコードが定期的に分析されます。

各アラートには、次の情報が含まれています。

  • コードに関する問題と、それを識別したツールの名前。
  • アラートをトリガーしたコード行。
  • アラートのプロパティ (重大度など)。
  • セキュリティの重大度。
  • 問題が発生した時点。
  • 問題の性質。

また、CodeQL 分析でアラートが識別されたときに問題を解決する方法についても説明します。 さらに、CodeQL を使用したコード スキャンでは、コード内のデータ フローの問題を検出できます。

GHAS の CodeQL 分析アラートのスクリーンショット。

脆弱性を手動で修正するだけでなく、Dependabot セキュリティ更新プログラムを使用して依存関係の修復を自動化できます。

Dependabot は、脆弱な依存関係を検出すると、依存関係を更新するためのプル要求を作成します。 これらのプル要求を自動化されたワークフローに統合して、修復を効率化できます。

Dependabot を使用した依存関係の修復の自動化

一般的な自動化ワークフローは、次のパターンに従います。

  1. Dependabot は、脆弱な依存関係を更新するプル要求を作成します。
  2. GitHub Actions ワークフローは、pull_request イベントでトリガーされます。
  3. ワークフローは、プル要求が dependabot[bot]によって作成されたかどうかを確認します。
  4. 更新に関するメタデータ (依存関係の種類やバージョンの変更など) を使用して、次のアクションを決定できます。
  5. ワークフローでは、検証チェックを実行したり、ラベルを適用したり、リスクの低い更新に対して自動マージを有効にしたりできます。

次の例は、Dependabot プル要求に対してのみ実行される単純なGitHub Actions ワークフローを示しています。 更新を検証し、チェックに合格した後に自動マージを有効にすることができます。

name: Dependabot remediation

on:
  pull_request:
    branches:
      - main

permissions:
  pull-requests: write

jobs:
  dependabot:
    if: github.event.pull_request.user.login == 'dependabot[bot]'
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Run tests
        run: npm test

      - name: Enable auto-merge for approved updates
        if: ${{ success() }}
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          PR_URL: ${{ github.event.pull_request.html_url }}
        run: gh pr merge --auto --merge "$PR_URL"

このアプローチは、チームが手動作業を減らすのに役立ち、マージされる前に依存関係の更新が検証されるようにします。

運用環境のシナリオでは、自動マージは通常、パッチ リリースなどのリスクの低い更新プログラムに限定され、ブランチ保護規則、必要な状態チェック、およびレビュー ポリシーと組み合わされます。

修復アクティビティに関するチームへの通知

依存関係の更新の可視性を向上させるために、チームは多くの場合、Dependabot と外部通知システムを統合します。

GitHub通知に加えて、次の機能を使用できます。

  • チーム認識のための Slack またはMicrosoft Teams統合。
  • カスタム連携と自動化パイプラインのための GitHub Webhook

たとえば、ワークフローまたは Webhook は、次の場合にチームに通知できます。

  • Dependabot のプルリクエストが作成されます。
  • 検証チェックは失敗します。
  • セキュリティ更新プログラムが取り込まれます。

これらの通知は、修復に注意が必要な場合にチームが迅速に対応するのに役立ちます。

データ フロー アラート

データ フロー分析では、次のようなコード内の潜在的なセキュリティの問題が検出されます。

  • セキュリティを侵害する方法でデータを使用する。
  • 関数に危険な引数を渡す。
  • 機密情報の漏洩。

GitHub では、コード スキャンがデータ フロー アラートを報告するときに、コード内でデータがどのように移動するかを示します。 これらのデータ フロー アラートを使用して、機密情報を漏えいさせるコードの領域を特定できます。 この知識は、悪意のあるユーザーによる攻撃のエントリ ポイントを特定するのに役立ちます。

重大度レベル

重大度が エラー であるコード スキャンの結果は、既定でチェック エラーの原因となります。

アラートの重大度レベルは次のとおりです。

  • エラー
  • Warning
  • Note

コード スキャン アラートをトリガーするプル要求が失敗する重大度レベルを指定できます。

セキュリティの重大度レベル

コード スキャンによって生成されるセキュリティ クエリでは、アラートのセキュリティ重大度レベルが表示されます。

セキュリティの重大度レベルは次のとおりです。

  • 危うい
  • 高
  • 中程度
  • 低

GitHub では、Common Vulnerability Scoring System (CVSS) データを使用して、アラートのセキュリティ重大度を計算します。

セキュリティの重大度が [重大 ] または [ 高 ] であるコード スキャンの結果では、既定でチェック エラーが発生します。 コード スキャン結果のチェック エラーを引き起こすセキュリティの重大度レベルを指定できます。

コード スキャン アラートを閉じる

アラートを閉じる方法は 2 つあります。

  • コードの問題を修正します。
  • アラートを無視または削除します。

コード スキャン アラートを無視する

アラートを無視することは、修正する必要がないと思われるアラートを閉じる方法です。 たとえば、テストにのみ使用されるコード内のエラーのアラートを無視できます。 また、エラーを修正するために必要な作業が、コードを改善する潜在的な利点を超える場合は、アラートを無視することもできます。

アラートは、コード内のコード スキャン注釈から、または [セキュリティ ] タブの概要リストから無視できます。一覧からアラートを閉じるには、[ アラートの無視 ] メニューを選択し、無視の理由を選択して、[ アラートの無視 ] ボタンを選択します。

コード スキャン アラートを閉じるためのドロップダウン メニューとボタンを示すアニメーション。

アラートを却下すると:

  • アラートはすべてのブランチで無視されます。
  • アラートはプロジェクトの現在のアラート数から除外されます。
  • アラートは、アラートの概要の [終了] リストに移動されます。 必要に応じて、そこから再度開くことができます。
  • アラートを閉じた理由が記録されます。
  • 次回コード スキャンを実行しても、同じコードではアラートは生成されません。