CodeQL コード スキャンの自動修正について

CodeQL code scanning の自動修正について

Code scanning 自動修正は、code scanning の GitHub Copilot 搭載による拡張であり、新しいセキュリティ脆弱性の発生を回避できるように、pull request 内の code scanning アラートを修正するのに役立つ、ターゲットを絞った推奨事項をユーザーに提供します。 潜在的な修正は、コードベース、pull request、および CodeQL 分析からのデータを使用して、大規模な言語モデル (LLM) によって自動的に生成されます。

Code scanning 自動修正では、既存のソース コードに関連する潜在的な修正が生成され、アラートの説明と場所が、アラートを修正できる可能性のあるコード変更に変換されます。 自動修正では、内部 GitHub Copilot API と、GPT-4 などの OpenAI 大規模言語モデルのプライベート インスタンスが使用されており、コードで推奨される修正および、それらの修正の説明テキストを生成するのに十分な生成機能があります。

組織のセキュリティの概要ダッシュボードでは、所定の期間に組織内のオープンおよびクローズされた pulll request で生成された自動修正候補の合計数を表示できます。 詳しくは、GitHub Enterprise Cloud のドキュメントの「セキュリティの分析情報の表示」をご覧ください。

開発者エクスペリエンス

GitHub Advanced Security ユーザーは、CodeQL を使用して pull request を分析することで code scanning によって検出されたセキュリティ アラートを既に確認している可能性があります。 ただし、多くの場合、開発者はコード セキュリティに関するトレーニングをほとんど受けていないため、これらのアラートを修正するにはかなりの作業量が必要です。 まず、アラートの場所と説明を読んで理解し、その理解に基づいてソース コードを編集して脆弱性を修正する必要があります。

Code scanning 自動修正は、ベスト プラクティスに関する情報とコードベースとアラートの詳細を組み合わせて開発者に潜在的な修正を提案することで、開発者が参入する際の障壁を減らします。 開発者は、脆弱性に関する情報の検索から開始するのではなく、コードベースについて潜在的なソリューションを示すコード候補から開始します。 開発者は、潜在的な修正を評価して、それがコードベースにベストのソリューションであるかどうかを判断し、意図する動作が維持されることを確認します。

提案された修正、または変更した修正をコミットした後、開発者は、pull request を統合する前に、コードベースが継続的インテグレーション テスト (CI) に引き続きパスし、アラートが解決済みとして表示されることを常に確認する必要があります。

サポートされている言語

Code scanning 自動修正は　JavaScript、TypeScript、Python、Java、および C# のデフォルトのクエリ スイートに含まれるクエリのサブセットの修正生成をサポートしています。 既定のクエリスイートの詳細については、「CodeQL クエリ スイート」を参照してください。

自動修正の生成プロセス

リポジトリに対して自動修正が有効になっている場合、サポートされている CodeQL クエリによって pull request 内で特定された code scanning アラートから、LLM に入力が送信されます。 LLM が潜在的な修正を生成できる場合、修正は推奨コメントとして pull request に表示されます。

GitHub は、pull request と CodeQL 分析から、さまざまなデータを LLM に送信します。

• CodeQL アラート データ (SARIF 形式)。 詳しくは、「Code scanningの SARIF サポート」をご覧ください。
• pull request ブランチの現在のバージョンからのコード。
  • それぞれのソースの場所、シンクの場所、アラート メッセージで参照されていたりフロー パスに含まれていたりするすべての場所の周辺のコードの短いスニペット。
  • これらの場所のいずれかに関係する各ファイルの最初の最大 10 行。
• 問題を特定した CodeQL クエリのヘルプ テキスト。 例については、「CodeQL query help」(CodeQL クエリ ヘルプ) を参照してください。

自動修正候補が生成され、code scanning バックエンド内に格納されます。 これらは、pull request で推奨コメントとして表示されます。 コードベースで code scanning を有効にして pull request を作成する以外に、ユーザー操作は必要ありません。

修正プログラムを生成するプロセスでは、上記の範囲を超えて顧客データが収集または利用されることはありません。 したがって、この機能の使用は、GitHub Advanced Security に関連付けられている既存の使用条件によって管理されます。 さらに、code scanning 自動修正によって処理されるデータは、LLM トレーニングの目的では厳密には使用されません。 GitHub Advanced Security の使用条件の詳細については、「追加の製品および機能に適用される GitHub 条件」を参照してください。

自動修正候補の品質

GitHub は自動テスト ハーネスを使用して、自動修正候補の品質を継続的に監視します。 これにより、LLM が生成した自動修正候補が、モデルの発展に伴ってどのように変化するかを把握できます。

テスト ハーネスには、強調表示されたコードがテスト カバレッジを持つさまざまなパブリック リポジトリの 1,870 を超えるアラートのセットが含まれています。 これらのアラートに対する自動修正候補は、コードベースにコミットする前にどの程度良好であるか、つまりどれくらい開発者が編集する必要があるかを確認するためにテストされます。 多くのテスト アラートでは、LLM が生成した自動修正をそのままコミットしてアラートを修正することも可能で、それで既存のすべての CI テストに引き続きパスします。

さらに、有害である可能性をチェックするためにシステムはストレス テストされ (多くの場合、レッド チーム テストと呼ばれます)、LLM のフィルタリング システムは、有害な可能性のある提案がユーザーに表示されるのを防ぐのに役立ちます。

GitHub で自動修正候補をテストする方法

結果コードで code scanning とリポジトリの単体テストを実行する前に、提案されたすべての変更を編集されていない状態で統合することで、自動修正候補の有効性をテストします。

1. code scanning アラートは提案によって修正されましたか?
2. 修正によって、新しい code scanning アラートが発生しましたか?
3. 修正によって、CodeQL が検出できる構文エラーが発生しましたか?
4. 修正によって、いずれかのリポジトリ テストの出力が変化しましたか?

さらに、成功した提案の多くをスポット的にチェックし、新しい問題を発生させずにアラートが修正されることを確認します。 これらのチェックの 1 つまたは複数が失敗した場合、提案された修正プログラムは、多くの場合、ほぼ正しいが、ユーザーが特定して手動で実行できるいくつかの軽微な変更が必要なことが、手動トリアージで示されました。

他のプロジェクトの有効性

テスト セットには、さまざまな種類のプロジェクトとアラートが含まれています。 自動修正でサポートされている言語を使用する他のプロジェクトの自動修正も同様のパターンに従うと予想されます。

• 自動修正は、大部分のアラートにコードの提案を追加する可能性があります。
• 開発者が自動修正候補を評価すると、編集せずに、または軽微な更新で修正の大部分をコミットすることで、コードのより広いコンテキストを反映できると想定しています。
• コードベースまたは脆弱性に対する重大な誤解に基づくのは、提案された修正のごく一部です。

ただし、各プロジェクトとコードベースは一意であるため、提案された修正をコミットする前に開発者が編集する必要がある割合は多くなります。 自動修正は code scanning アラートを解決するのに役立つ貴重な情報を提供しますが、提案された変更を評価し、コードのセキュリティと正確性を確保するのは最終的にユーザーの責任です。

自動修正候補の制限事項

自動修正候補を確認するときは、変更を受け入れる前に、AI の制限を常に考慮し、必要に応じて変更を編集する必要があります。 また、code scanning の自動修正を有効にする前に、リポジトリの CI テストと依存関係管理を更新することも検討する必要があります。 詳細については、「自動修正候補の制限の緩和」を参照してください。

自動修正コード候補の制限事項

• プログラミング言語: プログラミング言語のサブセットがサポートされています。 他の言語のサポートも追加しますが、すべての CodeQL 言語をサポートする予定はありません。
• 人間の言語: システムは主に英語データを使用します。これには、システムに送信されるプロンプト、データセット内の LLM が認識するコード、内部評価に使用されるテスト ケースが含まれます。 LLM が生成した提案は、他の言語で記述され他の文字セットを使用するソース コードとコメントでは、成功率が低くなる可能性があります。
• 構文エラー: 構文的に正しくないコード変更による修正をシステムが提案する可能性があるため、pull request について構文チェックを実行することが重要です。
• 場所エラー: 構文的に正しいコードであっても正しくない場所の修正をシステムが提案する可能性があります。つまり、ユーザーが場所を編集せずに修正を受け入れると、構文エラーが発生します。
• セマンティック エラー: 構文的に有効であるが、プログラムのセマンティクスを変更する修正をシステムが提案する可能性があります。 システムは、コードの動作に関するプログラマーやコードベースの意図を理解しません。 テスト カバレッジを適切に設定すると、開発者は修正によってコードベースの動作が変化しないことを確認できます。
• セキュリティの脆弱性と誤りの基になる修正: 基になるセキュリティ脆弱性を修復できなかったり、新しいセキュリティ脆弱性が発生したりする修正をシステムが提案する可能性があります。
• 部分的な修正: セキュリティの脆弱性に部分的にしか対処しない、または意図されているコード機能を部分的にしか保持しない修正をシステムが提案する可能性があります。 システムはコードベース内のコードのごく一部のみを見るので、必ずしもグローバルに最適または正しいソリューションを生成するとは限りません。

自動修正の依存関係の提案の制限事項

提案された修正には、コードベースの依存関係の変更が含まれている場合があります。 依存関係管理システムを使用する場合、開発者が確認できるように変更が自動的にハイライトされます。 pull request をマージする前に、依存関係の変更がセキュリティで保護され、コードベースの意図されている動作が維持されることを必ず確認します。

• 新しい依存関係または更新された依存関係: 提案された修正の一部として、ソフトウェアの依存関係の追加または更新をシステムが提案する可能性があります。 たとえば、JavaScript プロジェクトが npm から依存関係を追加するように package.json ファイルを変更することを提案する場合などです。
• サポートされていない依存関係またはセキュリティで保護されていない依存関係: システムは、既存の依存関係のどのバージョンがサポートされているか、セキュリティで保護されているかを認識しません。
• 捏造された依存関係: より広範なエコシステムで公開されている依存関係に関しては、システムの知識は不完全です。 これにより、攻撃者が統計的にもっともらしい依存関係名で悪意のあるソフトウェアを公開すると、このソフトウェアへの新しい依存関係を追加する提案につながる可能性があります。

自動修正候補の制限の緩和

自動修正候補の制限を緩和する最善の方法は、ベスト プラクティスに従う方法です。 たとえば、pull request の CI テストを使用して機能要件が影響を受けないことを確認することや、依存関係レビュー API やアクションなどの依存関係管理ソリューションを使用することです。 詳しくは、「依存関係の確認について」をご覧ください。

pull request の作成者は、同僚や自動ツールによって提案されたかどうかにかかわらず、レビュー コメントやコード変更の提案にどのように対応するかについて責任を負うことを忘れないでください。 開発者は、コードの変更に関する提案を常に批判的に見る必要があります。 必要に応じて、提案された変更を編集して、結果コードとアプリケーションが正しく、セキュリティで保護され、パフォーマンス基準を満たし、アプリケーションの他のすべての機能要件と非機能要件を満たすようにする必要があります。

次のステップ

• 「Code scanningアラートについて」
• GitHub Enterprise Cloud ドキュメントの「Pull RequestでCode scanningアラートをトリアージする」