コード スキャンを構成する

完了

GitHub でどのようにプロジェクト内のコードの脆弱性とエラーをスキャンするかを構成できます。 独自の構成を選択するときは、時間を節約し、プロジェクトに合った最適なコード スキャン頻度を決定します。 このユニットでは、コード スキャン構成の基本事項について説明します。 また、リポジトリと開発のニーズに合わせてスキャン頻度の構成とスケジュール設定を行う方法についても説明します。

これまでのユニットで説明したように、コード スキャンは GitHub で GitHub Actions を使用して、または継続的インテグレーション (CI) システムから実行できます。 GitHub で [詳細設定 ] オプションを選択すると、カスタマイズ可能なワークフロー ファイルが生成され、リポジトリに直接コミットできます。 通常は、このワークフローを編集する必要はありません。 ただし、必要であれば一部の設定をカスタマイズできます。

たとえば、GitHub の CodeQL 分析ワークフローを編集して、スキャンの頻度、スキャンする言語またはディレクトリ、CodeQL コード スキャンによってコード内で見つける対象を指定できます。 また、特定のコマンド セットを使用してコードをコンパイルする場合も、CodeQL 分析ワークフローの編集が必要になることがあります。 CodeQL 分析は、GitHub で実行できるコード スキャンの種類の 1 つです。 GitHub Marketplace には、他にもいくつかのコード スキャン ワークフローが含まれています。

既定から高度なコード スキャンセットアップへの切り替え

既定の設定方法を使用して、コード スキャンを使用するようにリポジトリを既に設定している場合は、設定で [詳細] 設定を使用するように切り替えることができます。 >] の下にある [コード スキャン] セクションに移動し、3 つのドット オーバーフロー アイコン (...) を選択します。ドロップダウンで、[詳細設定に切り替える] を選択します。 次に、プロンプトに従って CodeQL を無効にし、詳細設定の生成されたワークフロー ファイルで再度有効にします。

コードスキャン ワークフローを編集する

GitHub は、リポジトリの .github/workflows ディレクトリにワークフロー ファイルを保存します。 追加したワークフローは、そのファイル名を検索して見つけることができます。 たとえば、既定では、CodeQL コード スキャンのワークフロー ファイルは codeql-analysis.yml と呼ばれます。

ワークフロー ファイルを編集するには、次の手順に従います。

1. ワークフロー エディターを開くには、ファイル ビューの右上隅にある 編集 アイコンを選択します。

2. 編集を行います。

3. ファイルを編集したら、[ 変更のコミット ] を選択し、[変更のコミット] フォームに入力します。 現在のブランチに直接コミットするか、新しいブランチを作成して pull request を開始するかを選択できます。

一般的なコード スキャン構成オプションについては、この後のセクションを参照してください。

頻度を構成する

ワークフロー ファイルに対して一般的に行う編集は、コード スキャンの実行頻度の調整です。 CodeQL 分析ワークフローは、スケジュールに基づいて、またはリポジトリで特定のイベントが発生した場合にコードをスキャンするように構成できます。 また、ワークフロー ファイルを編集して、誰かが変更をプッシュしたときやプル要求が作成されるたびにコードをスキャンすることもできます。 この頻度を調整することで、開発者がコードに新たな脆弱性やエラーを取り込まないようにすることができます。 スケジュールに基づいてコードをスキャンすると、GitHub、セキュリティ研究者、コミュニティによって検出された最新の脆弱性とエラーが通知されます。 開発者がリポジトリを積極的に保守していない場合にもです。

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

既定では、CodeQL 分析ワークフローで on:push イベントが使用されると、リポジトリの既定のブランチおよび保護されたブランチへのすべてのプッシュ時にコード スキャンがトリガーされます。 指定したブランチでコード スキャンがトリガーされるようにするには、ワークフローがそのブランチに存在している必要があります。 プッシュ時にスキャンすると、リポジトリの [セキュリティ ] タブに結果が表示されます。

さらに、オープン中の pull request にマップできる結果が on:push スキャンから返された場合、これらのアラートは他の pull request アラートと同じ場所にある pull request に自動的に表示されます。 これらのアラートは、ブランチのヘッドの既存の分析とターゲット ブランチの分析を比較することで特定します。

PR 時にスキャンする

既定の CodeQL 分析ワークフローでは、pull_request イベントを使用して、既定のブランチを対象とする pull request があったときにコード スキャンをトリガーします。 pull request がプライベート フォークからのものである場合、pull_request イベントがトリガーされるのは、リポジトリ設定で [Run workflows from fork pull requests] (フォークの pull requests からワークフローを実行する) オプションを選択した場合のみです。 pull request をスキャンすると、結果は、pull request チェックにアラートとして表示されます。

ヘッド コミットではなく pull request のマージ コミットをスキャンするように構成された pull_request トリガーを使用すると、プッシュごとにブランチのヘッドをスキャンするよりも効率的で正確な結果が生成されます。 ただし、pull request でトリガーするように構成できない CI/CD システムを使用する場合でも、on:push トリガーを使用して、コード スキャンで、結果をブランチのオープン pull request にマップし、アラートを注釈として pull request に追加できます。

pull request チェック エラーの原因となる重大度を定義する

既定では、重大度レベルが Error またはセキュリティの重大度レベルが Critical または High のアラートによってのみ、pull request チェック エラーが発生します。

これらのエラーによってコード スキャンの実行がブロックされるわけではありませんが、リポジトリの規則によってはマージがブロックされる可能性があります。プル要求エラーの詳細は、[セキュリティ] の [コード スキャン アラート] タブで確認できます。

リポジトリ設定でプル要求チェックエラーを引き起こす重大度レベルを構成することも、コード スキャンの結果を要求するルールを使用してリポジトリ ルールセットを使用して構成することもできます。 どちらのメカニズムも機能しますが、ルールセットは最新の推奨される構成方法です。

1. GitHub.com で、リポジトリのメイン ページに移動します。 リポジトリ名の下にある [設定] を選択します。

2. 左側のサイドバーで、[Advanced Security] を選択します。

3. [保護ルール] の [コード スキャン] セクションで、ドロップダウン メニューを使用して、プル要求チェックエラーをトリガーする重大度レベルを選択します。

コード スキャン アラートを適切にトリアージして却下する

コードの修正は、コード スキャン アラートを解決するための推奨される方法です。 ただし、一部のアラートではコードを変更する必要がない場合があります。 たとえば、アラートは誤検知であるか、テスト コードにのみ表示されるか、チームが修正しないことを決定したリスクを表します。

アラートの詳細を確認し、理由を確認した後にのみ、アラートを無視します。 アラートを閉じると、GitHubは、無視の理由を記録し、現在のアラート数からアラートを削除し、閉じた一覧に移動して、同じコードが今後のスキャンで同じアラートを生成できないようにします。 却下は、すべてのブランチに適用されます。

無視の理由は、リポジトリのセキュリティ レコードの一部になるため、慎重に選択してください。 また、無視コメントを追加して、決定を説明することもできます。 このコメントはアラート タイムラインに追加され、今後の監査、レポート、コンプライアンス レビューをサポートできます。

コメントを使用して、次のような詳細をキャプチャします。

• アラートでコードを変更する必要がない理由

• 決定をレビューしたユーザー

• 決定が一時的か永続的か

• 補正コントロールまたはフォローアップ作業

ガバナンスを強化するために、組織は委任されたアラートの無視を使用して、コード スキャン アラートを無視できるユーザーを制御できます。 これにより、開発者がレビューなしでセキュリティの結果を閉じるのを防ぎ、より説明責任のあるトリアージ プロセスを作成できます。

pull request の不要なスキャンを回避する

変更されたファイルに関係なく、既定のブランチを対象とする特定の pull request でコード スキャンがトリガーされないようにしたい場合があります。 この設定を構成するには、コード スキャン ワークフローで on:pull_request:paths-ignore または on:pull_request:paths を指定します。 たとえば、pull request 内の変更がファイル拡張子 .md または .txt のファイルに対するものだけである場合、次の paths-ignore 配列を使用できます。

on: 

push: 

branches: [main, protected] 

pull_request: 

branches: [main] 

paths-ignore: 

- '**/*.md' 

- '**/*.txt' 

スキャン スケジュールを調整する

既定の CodeQL 分析ワークフローを使用する場合、ワークフローは、イベントによってトリガーされるスキャンに加え、週に 1 回ランダムに生成された日時にリポジトリ内のコードをスキャンします。 このスケジュールを調整するには、ワークフローの cron 値を編集します。

次の例は、main という名前の既定のブランチと、protected という名前の保護された 1 つのブランチを持つリポジトリの CodeQL 分析ワークフローを示しています。

on: 

push: 

branches: [main, protected] 

pull_request: 

branches: [main] 

schedule: 

- cron: '20 14 * * 1' 

このワークフローでは以下をスキャンします。

• デフォルトのブランチと保護されたブランチへのすべてのプッシュ

• デフォルト ブランチへのすべてのプル リクエスト

• 毎週月曜日 14 時 20 分 (UTC) に既定のブランチ

Copilot の自動修正候補を使用する

GitHub Copilot自動修正は、開発者が対象となるコードの変更を提案することで、コード スキャンアラートを解決するのに役立ちます。 自動修正では、アラート、コードベース、および pull request からの情報を使用して、潜在的な修正プログラムが生成されます。 Copilot Autofix を使用するために、個別のGitHub Copilot サブスクリプションは必要ありません。 GitHub.com のパブリック リポジトリと、GitHub Code Security が有効になっている組織所有のリポジトリで使用できます。

自動修正候補は自動修正ではありません。 これらは提案された変更であり、他のコード変更と同様にレビュー、テスト、承認を行う必要があります。

自動修正候補を確認する場合:

1. アラートを読み、セキュリティの問題を理解します。

2. 推奨されるコードの変更を確認します。

3. 修正プログラムが意図した動作を変更せずにアラートに対処することを確認します。

4. プロジェクトのテストと必要なセキュリティ チェックを実行します。

5. 必要に応じて提案を変更します。

6. 修正を pull request にコミットします。

7. チェックが再度実行された後に、コード スキャン アラートが解決されることを確認します。

自動修正候補が適切でない場合は、適用するのではなく、修正候補を無視します。 アラート自体を修正する必要がない場合は、正しい理由と明確なコメントでアラートを閉じます。