コード スキャンに対する Copilot Autofix の責任ある使用

code scanning の Copilot Autofix について

GitHub Copilot Autofix は、 code scanning の拡張であり、新しいセキュリティ脆弱性の発生を回避できるように、code scanning アラートを修正するのに役立つ、ターゲットを絞った推奨事項をユーザーに提供します。 潜在的な修正は、コードベース、および code scanning 分析からのデータを使用して、大規模な言語モデル (LLM) によって自動的に生成されます。 GitHub Copilot Autofix は CodeQL 分析で使用でき、第三者製ツール ESLint をサポートしています (第三者のサポートは パブリック プレビュー にあり、変更される可能性があります)。

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

Copilot Autofix は既定で許可されており、CodeQL を使用するすべてのリポジトリで有効になっていますが、Copilot Autofix をオプトアウトして無効にすることを選択できます。 エンタープライズ レベル、組織レベル、およびリポジトリ レベルで Copilot Autofix を無効にする方法については、「コード スキャンの Copilot Autofix を無効にする」を参照してください。

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

開発者エクスペリエンス

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

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

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

CodeQL code scanning のサポートされている言語

Copilot Autofix では、 の既定およびセキュリティ拡張 CodeQLクエリ スイートに含まれるクエリのサブセットの修正生成がサポートされています。 これらのクエリ スイートの詳細については、「CodeQL クエリ スイート」を参照してください。

修正候補の生成プロセス

リポジトリに対してCopilot Autofix が有効になっている場合、特定された code scanning アラートから、LLM に入力が送信されます。 LLM が潜在的な修正を生成できる場合、修正は推奨として表示されます。

GitHub は、code scanning 分析から、さまざまなデータを LLM に送信します。 次に例を示します。

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

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

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

候補の品質

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

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

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

GitHub で候補をテストする方法

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

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

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

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

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

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

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

候補の制限事項

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

コード候補の制限事項

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

依存関係の候補の制限事項

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

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

候補の制限の緩和

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

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

次のステップ

• Code scanningアラートについて
• 「pull request で Code scanning アラートをトリアージする」
• 「コード スキャン アラートの解決」
• 「コード スキャンの Copilot Autofix を無効にする」