コード スキャン アラートを解決する

ギットハブ コパイロット チャットアラートについてcode scanningに質問する

GitHub Copilot Enterprise ライセンスを使用すると、組織内のリポジトリのセキュリティ アラート (コパイロットチャット アラートなど) をより深く理解するためのヘルプをcode scanningに依頼できます。 詳しくは、「GitHubでGitHub Copilotに質問する」をご覧ください。

code scanningアラートの修正候補の生成

GitHub Copilotの自動修正機能 では、 code scanning 分析によって識別されたアラートの修正プログラムを生成できます。 ほとんどの CodeQL アラートの種類がサポートされています。 「コードスキャンにおけるCopilotの自動修正について」を参照してください。

1. GitHub で、リポジトリのメイン ページに移動します。
2. リポジトリ名の下にある [ Security and quality ] タブをクリックします。[ Security and quality] タブが表示されない場合は、 ドロップダウン メニューを選択し、[ Security and quality] をクリックします。
3. 左側のサイドバーで、 [Code scanning] をクリックします。
4. アラートの名前をクリックします。
5. 修正をCopilot の自動修正提案できる場合は、ページの上部にある [修正プログラムの生成] をクリックします。
6. 修正候補が生成されたら、ページの下部にある [修正プログラムを含む PR を作成] をクリックして修正ピログラムを含むプル リクエストを自動的に生成できます。 既定のブランチから新しいブランチが作成され、生成された 修正プログラムがコミットされ、ドラフトのプル リクエストが作成されます。 その他の修正プログラムと同様に、提供産された修正プログラムはテスト、編集できます。

履歴アラート エンドポイントで Autofix API を使用すると、提案された修正プログラムを生成、取得、コミットすることもできます。

• コード スキャン アラートの自動修正を作成する
• コード スキャン アラートの自動修正の状態を取得する
• コード スキャン アラートの自動修正をコミットする

Copilot の自動修正 code scanningアラートでは、あらゆる状況のすべてのアラートに対して修正プログラムを生成することはできません。 この機能はベスト エフォート ベースで動作し、常に成功する保証はありません。 自動的に生成されるフィックスの制限については、「提案の制限事項」を参照してください。

Copilot クラウドエージェントへのアラートの割り当て

Copilotを割り当てて自動修正を適用できます。 Copilot は、コード スキャン アラートを分析し、修復計画を作成し、必要なコード変更をプル要求に実装します。

1. GitHub で、リポジトリのメイン ページに移動します。
2. リポジトリ名の下にある [ Security and quality ] タブをクリックします。[ Security and quality] タブが表示されない場合は、 ドロップダウン メニューを選択し、[ Security and quality] をクリックします。
3. 左側のサイドバーで、 [Code scanning] をクリックします。
4. アラートの名前をクリックします。
5. 自動修正が生成されておらず、修正プログラムCopilot の自動修正提案できる場合は、ページの上部にある [修正プログラムの生成] クリックします。
6. 右側のメニューで、[ 担当者] をクリックします。
7. [Copilot] を選択します。

30 秒以内に、 Copilot はアラートに対処するためのプル要求を開き、修正の概要と加えられた変更の詳細が含まれます。 作成されると、pull request が [開発] セクションに表示されます。

アラート 手動で修正する

リポジトリへの書き込み権限があるユーザなら誰でも、コードに修正をコミットしてアラートを解決できます。 リポジトリがプルリクエストに対して実行されるようにスケジュールcode scanningされている場合は、あなたの修正を反映したプルリクエストを提出することをお勧めします。 これにより、変更の code scanning 分析がトリガーされ、修正によって新しい問題が発生しないことをテストできます。 詳しくは、「Pull RequestでCode scanningアラートをトリアージする」をご覧ください。

GitHubを離れることなくチームのワークフローで修復作業を追跡するには、アラートを問題にリンクできます。 「コード スキャンアラートをGitHubの問題にリンクする」を参照してください。

自由テキスト検索またはフィルターを使ってアラートの一部を表示し、一致するすべてのアラートをクローズ済みとマークすることができます。

あるブランチでは解決されたアラートが、別のブランチでは解決されていないことがあります。 アラートの概要で "[ブランチ]" フィルターを使用すると、特定のブランチでアラートが修正されているかどうかを確認できます。

既定ではないブランチでフィルター処理したのと同じアラートが、既定のブランチに存在する場合、そのアラートのアラート ページには、その状態が既定ではないブランチでの状態と競合する場合でも、既定のブランチのアラートの状態のみが反映されることに注意してください。 たとえば、アラートの概要の branch-x の [Open](オープン) リストに表示されるアラートは、そのアラートが既定のブランチで既に修正されている場合、アラート ページに "Fixed"(修正済み) の状態で表示される場合があります。 フィルター処理したブランチのアラートの状態は、アラート ページの右側の [Affected branches](影響を受けるブランチ) セクションで確認できます。

アラートを無視する

アラートをクローズする方法は2つあります。 コード中の問題を修正するか、アラートを却下できます。

アラートを無視することは、修正する必要がないと思われるアラートを閉じる方法です。 たとえば、テストで使われるだけのコードのエラーや、エラーを修正するための労力がコードを改善することによる潜在的な利点よりも大きい場合です。 アラートは、コード内の code scanning 注釈から、または [ Security and quality ] タブ内の概要リストから無視できます。

アラートを却下すると:

• それはすべてのブランチで却下されます。
• アラートはプロジェクトの現在のアラート数から除外されます。
• アラートはアラートのサマリの"Closed"リストに移動されます。必要な場合は、そこからアラートを再オープンできます。
• アラートを閉じた理由がログに記録されます。
• 必要に応じて、無視した理由をコメントに残し、アラートを無視したコンテキストを記録することもできます。
• 次回 code scanning 実行しても、同じコードでアラートは生成されません。

アラートを無視する:

1. GitHub で、リポジトリのメイン ページに移動します。
2. リポジトリ名の下にある [ Security and quality ] タブをクリックします。[ Security and quality] タブが表示されない場合は、 ドロップダウン メニューを選択し、[ Security and quality] をクリックします。
3. 左側のサイドバーで、 [Code scanning] をクリックします。
4. アラートを却下したい場合、そのアラートをまず調べて、却下する正しい理由を選択できるようにすることが重要です。 調べたいアラートをクリックしてください。
5. アラートを確認してから Dismiss alert をクリックし、アラートをクローズする理由を選ぶか入力します。

クエリが将来の分析に含まれ続けるかに影響することがあるので、ドロップダウンメニューから適切な理由を選択することは重要です。 必要に応じて、却下についてコメントを残し、アラートを却下したコンテキストを記録することもできます。 無視のコメントはアラート タイムラインに追加され、監査と報告の間に正当な理由として使用できます。 コード スキャン REST API を使用して、コメントを取得または設定できます。 コメントは、dismissed_comment エンドポイントの alerts/{alert_number} に含まれます。 詳しくは、「コード スキャン用の REST API エンドポイント」をご覧ください。

たとえばコードがサポートされていないサニタイズ ライブラリを使っているといった理由で、CodeQL のアラートを擬陽性の結果として却下する場合、CodeQL に貢献して分析を改善することを検討してください。 CodeQL の詳細については、「CodeQL に貢献する」を参照してください。

複数のアラートを一度に却下する

同じ理由で却下したい複数のアラートがプロジェクトにあるなら、アラートのサマリからそれらをまとめて却下できます。 通常は、リストをフィルタしてマッチするアラートをすべて却下することになるでしょう。 たとえば、プロジェクト中で特定の共通脆弱性タイプ (CWE)の脆弱性がタグ付けされた現在のアラートをすべて却下したいことがあるでしょう。

無視されたアラートを再び開く

アラートを無視した後、アラートを修正する必要があることがわかった場合は、アラートを再度開いて、コードで問題を修正できます。 閉じたアラートの一覧を表示し、アラートを検索して表示し、再度開きます。 その後、他のアラートと同じ方法でアラートを修正します。

ブランチから古い構成とアラートを削除する

1 つのリポジトリに複数のコード スキャン構成が含まれる場合があります。 実行すると、複数の構成で同じアラートが生成されることがあります。 さらに、構成を異なるスケジュールで実行した場合、頻度の低い構成または古い構成ではアラートの状態が古くなる可能性があります。 複数構成からのアラートの詳細については、「AUTOTITLE」を参照してください。

1. GitHub で、リポジトリのメイン ページに移動します。

2. リポジトリ名の下にある [ Security and quality ] タブをクリックします。[ Security and quality] タブが表示されない場合は、 ドロップダウン メニューを選択し、[ Security and quality] をクリックします。

3. 左側のサイドバーで、 [Code scanning] をクリックします。

4. [Code scanning] でcode scanningアラートをクリックします。

5. サイドバーの [影響を受けるブランチ] セクションで、目的のブランチをクリックします。

6. [構成の分析] ダイアログで、選択したブランチでこのアラートを報告した構成の詳細を確認します。 目的のブランチの不要な構成を削除するには、[ ] をクリックします。

   誤って構成を削除した場合は、 [キャンセル] をクリックして変更を適用しないようにします。

   

7. 不要な構成を削除し、期待される構成が表示されていることを確認したら、 [変更の保存] をクリックします。

   誤って構成を削除した後で変更を保存した場合は、構成をもう一度実行してアラートを更新します。 GitHub Actionsを使用する構成の再実行の詳細については、ワークフローとジョブの再実行 を参照してください。

詳細については、次を参照してください。

• Pull RequestでCode scanningアラートをトリアージする
• コード スキャンの既定セットアップの構成
• Code scanningとのインテグレーションについて