5.1脆弱性のコンテキストと優先順位付け

セキュリティ運用（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）・到達可能性（実際にコードパスに乗るか）・資産の重要度を総合して決めます。これにより、限られたリソースを 最もリスクの高いもの に集中させます。

5.1.3キャンペーンと一括管理・自動却下

キャンペーンベースの修復（第1章）は、多リポにまたがる同種のアラートを束ねて計画的に片付けます。一括管理（bulk alert management） で複数アラートをまとめて状態変更・割り当てし、運用を効率化します。自動却下（automated dismissal） は、明確に許容できる条件のアラートを自動で取り下げますが、記録（ドキュメント化） を伴い、後から「なぜ却下したか」を追えるようにします。安易な自動却下はリスクの見逃しになるため、条件設計が重要です。

5.1.4この節のまとめ

• CVE＝個別の脆弱性 ID、CWE＝弱点の種類分類、GHSA＝Advisory Database の脆弱性情報
• 大規模はルールセットで重大度ベースのマージ保護を強制（SLA 期限はポリシー目標として追跡）
• 優先順位は CVSS＋EPSS＋到達可能性＋資産重要度を総合
• キャンペーン/一括管理で効率化、自動却下は記録（ドキュメント化）を伴う