注: この機能を使うには、サイト管理者が お使いの GitHub Enterprise Server インスタンス の code scanning を有効にする必要があります。 詳しくは、「アプライアンス用コードスキャンの構成」を参照してください。
Enterprise の所有者が Enterprise レベルで GitHub Advanced Security (GHAS) ポリシーを設定している場合、code scanning を有効または無効にできない場合があります。 詳しくは、「エンタープライズのコード セキュリティと分析のためのポリシーの適用」を参照してください。
code scanning からのアラートについて
code scanning を構成して、既定の CodeQL 解析、サードパーティーの解析、または複数の種類の解析を使ってリポジトリのコードをチェックできます。 解析が完了すると、解析によるアラートがリポジトリのセキュリティビューに隣り合わせで表示されます。 サードパーティツールまたはカスタムクエリの結果には、GitHub のデフォルト CodeQL 解析により検出されたアラートで表示されるプロパティの一部が含まれていない場合があります。 詳細については、「About code scanning alerts」を参照してください。
デフォルトでは、code scanning はプルリクエスト中にデフォルトブランチのコードを定期的に解析します。 pull request のアラートの管理については「Pull RequestでCode scanningアラートをトリアージする」を参照してください。
GitHub ツールを使用して、code scanning アラートに応答して実行されたアクションを監査できます。 詳しくは、「セキュリティ アラートの監査」を参照してください。
アラートの詳細について
各アラートはコードの問題と、それを特定したツールの名前を表示します。 アラートをトリガーしたコード行と、アラートのプロパティ (アラートの重要度、セキュリティの重要度、問題の性質など) を確認できます。 アラートは、問題が最初に発生したときにも通知します。 CodeQL 解析で特定されたアラートについては、問題を解説する方法についての情報も表示されます。
[アラート] ページのステータスと詳細は、他のブランチにアラートが存在する場合であっても、リポジトリの既定のブランチに対するアラートのステータスを反映するのみです。 既定以外のブランチのアラートの状態は、[アラート] ページの右側にある [影響を受けるブランチ] セクションで確認できます。 既定のブランチにアラートが存在しない場合、アラートの状態は、[in pull request] または [in branch] として、グレー表示されます。
CodeQL を使って code scanning を構成した場合、コード中のデータフローの問題も見つけることができます。 データフロー解析は、データを安全でない方法で利用する、関数に危険な引数を渡す、機密情報を漏洩するなど、コードにおける潜在的なセキュリティ問題を検出します。
code scanning がデータフローアラートを報告すると、GitHub はデータがコードを通してどのように移動するかを示します。 Code scanning を使うと、機密情報を漏洩し、悪意のあるユーザーによる攻撃の入り口になる可能性があるコードの領域を特定できます。
分析元について
リポジトリでコード分析の複数の構成を実行し、さまざまなツールを使用して、さまざまな言語またはコード領域をターゲットにすることができます。 code scanning の各構成は、それにより生成されるすべてのアラートの分析元です。 たとえば、GitHub Actions で既定の CodeQL 分析を使用して生成されたアラートには、外部で生成されて、code scanning API を介してアップロードされたアラートとは異なる分析元があります。
複数の構成を使用してファイルを分析した場合、同じクエリによって検出された問題が、複数の分析元があるアラートとして報告されます。 アラートの分析元が複数ある場合、アラート ページの右側にある [影響を受けるブランチ] セクションで、該当するブランチの横に アイコンが表示されます。 アイコンの上にカーソルを合わせると、各分析元の名前とその分析元のアラートの状態を確認できます。 また、各分析元でいつアラートが発生したかの履歴を、アラート ページのタイムラインに表示することもできます。 アラートに分析元が 1 つしかない場合、アラート ページに分析の発生元に関する情報は表示されません。
注: 場合によっては、code scanning アラートが 1 つの分析元について修正済みとして表示されていても、2 つ目の分析元については解決されていないことがあります。 これを解決するには、2 番目の code scanning 構成を再実行して、その分析元のアラートの状態を更新します。
アプリケーションコード中には見つからないアラートのラベルについて
GitHub Enterprise Serverは、アプリケーションコード中に見つからないアラートに対し、カテゴリラベルを割り当てます。 ラベルは、アラートの場所に関連づけられます。
- [生成済み] : ビルド プロセスによって生成されたコード
- [テスト] : テスト コード
- [ライブラリ] : ライブラリまたはサードパーティのコード
- [ドキュメント] : ドキュメント
Code scanning は、ファイルをファイル パスによって分類します。 手動でソースファイルを分類することはできません。
この例のアラートは、code scanning アラート リストで "テスト" コードとしてマークされています。
クリックしてアラートの詳細を表示すると、ファイル パスが "テスト" コードとしてマークされていることがわかります。
アラートの重大度とセキュリティの重大度レベルについて
code scanning アラートの重大度レベルは、問題がコードベースに追加するリスクの程度を示します。
- [重要度]。 すべての code scanning アラートには、
Error
、Warning
、またはNote
レベルがあります。 - セキュリティの重要度。 また、CodeQL を使用して検出された各セキュリティ アラートには、セキュリティの重大度レベル
Critical
、High
、Medium
またはLow
があります。
アラートにセキュリティ重大度レベルがある場合、code scanning が表示され、このレベルが severity
よりも優先して使用されます。 セキュリティの重大度レベルは、業界標準の共通脆弱性スコアリング システム (CVSS) に従います。このシステムは、GitHub Advisory Database のアドバイザリにも使用されます。 詳細については、「CVSS: 定性重要度評価スケール」を参照してください。
code scanning アラートの pull request チェック失敗
pull request で code scanning を有効にすると、チェックは、重大度 error
のアラートが 1 つまたは複数検出された場合か、critical
または high
が検出された場合のみ失敗します。 重大度が低いアラートまたはセキュリティ重大度のアラートが検出された場合、チェックは成功します。 重要なコードベースの場合は、コード変更をマージする前にアラートを修正または無視するようにするために、アラートが検出された場合に code scanning チェックを失敗させることができます。 重大度レベルの詳細については、「アラートの重大度とセキュリティの重大度レベルについて」を参照してください。
チェック エラーを発生させる重大度とセキュリティの重大度アラート レベルを編集できます。 詳しくは、コード スキャンの詳細設定を行う」をご覧ください。
セキュリティの重大度レベルの計算
セキュリティ クエリを CodeQL Default または Extended クエリ スイートに追加すると、CodeQL エンジニアリング チームは、セキュリティの重大度を次のように計算します。
- 新しいセキュリティ クエリに関連付けられている 1 つ以上の CWE タグが割り当てられている、すべての CVE を検索します。
- それらの CVE の CVSS スコアの 75 パーセンタイルを計算します。
- クエリのセキュリティ重大度としてスコアを定義します。
- クエリで検出されたアラートを表示する際、CVSS 定義を使用して、数値スコアを
Critical
、High
、Medium
、またはLow
に変換します。
詳しくは、CodeQL ドキュメント サイトの「CodeQL CWE カバレッジ」をご覧ください。