変更要約: GH-500 第5章を新規作成（脆弱性コンテキストと優先順位付け＝CVE/CWE/GHSA・リポジトリアドバイザリ・ルールセットで重大度/SLA 強制・CVSS＋EPSS＋到達可能性＋資産重要度・キャンペーン/一括管理・自動却下と記録、カスタマイズとガバナンス・シフトレフト＝CodeQL クエリスイート[default/security-extended/カスタム]・役割/委譲例外/所有権・スイート横断ルールセット強制・Push Protection/依存スキャン/マージ前解析）
5.1脆弱性のコンテキストと優先順位付け
CVE・CWE・GitHub Security Advisory の概念、アラートとアドバイザリにまたがるエンドツーエンドの修復ワークフロー、重大度/修復のルールセットの定義・優先順位付け・強制、キャンペーンベースの一括管理、そして自動却下と記録の実践を理解します。
セキュリティ運用（SecOps）の要は、出てきた大量のアラートを 共通言語で理解し、優先順位を付け、組織として修復を回す ことです。GH-500 ではまず、脆弱性を語る 標準概念 を押さえます——個別の脆弱性 ID の CVE、脆弱性の種類分類の CWE、そして GitHub が提供する Security Advisory です。
5.1.1CVE・CWE・GitHub Security Advisory
CVE（Common Vulnerabilities and Exposures） は、特定の製品/版の 個別の脆弱性に付く一意の ID（例: CVE-2024-XXXXX）です。CWE（Common Weakness Enumeration） は、SQL インジェクションやバッファオーバーフローといった 弱点の「種類」の分類（例: CWE-89）です（CVE が「事例」、CWE が「種類」）。GitHub Security Advisory（GHSA） は、GitHub Advisory Database に収録される脆弱性情報で、Dependabot の検知の裏付けになります。リポジトリ管理者は リポジトリのセキュリティアドバイザリ を作成して、自プロジェクトの脆弱性を 非公開で修正してから公開 することもできます。
5.1.2ルールセットによる優先順位付けと強制
大規模では、対応方針を ルールセット として定義し、コードスキャンのマージ保護（一定重大度以上のアラートがある PR はマージ不可）を組織横断で 強制 します。修復の SLA（期限） はポリシー目標として定め（キャンペーンの期日などで追跡）遵守を促します。「未修復の高重大度アラートがある PR はマージ不可」といった保護を 必須化 します。優先順位は、重大度（CVSS）・悪用確率（EPSS）・到達可能性（実際にコードパスに乗るか）・資産の重要度を総合して決めます。これにより、限られたリソースを 最もリスクの高いもの に集中させます。