# Dependabot アラート優先順位付け完全ガイド：CVSS × EPSS × 到達可能性で『どれから直すか』を決める > Dependabot のアラートが二桁溜まったとき、どれから直すべきか。深刻度（CVSS）だけで並べると優先順位を誤ります。公式ドキュメントに忠実に、CVSS（影響の大きさ）と EPSS（攻撃される確率・FIRST が毎日更新）を2軸で組み合わせ、到達可能性・依存スコープ・auto-triage rules（severity/EPSS/scope でマッチ）・REST API での棚卸しまで、アラート疲れを断ち『本当に危険な少数』に集中するトリアージ設計を実コードで解説します。 - 公開日: 2026-07-01 - 著者: 友田 陽大 - タグ: Dependabot, サプライチェーンセキュリティ, 脆弱性管理, EPSS, DevSecOps, セキュリティ - URL: https://tomodahinata.com/blog/dependabot-alerts-prioritization-cvss-epss-reachability-triage-guide - カテゴリ: Dependabot・依存関係の自動更新 - 総合ガイド: https://tomodahinata.com/blog/dependabot-production-guide ## 要点 - 深刻度（CVSS）は『被害の大きさ』、EPSS は『実際に攻撃される確率』。CVSS だけで並べると、めったに攻撃されない Critical に工数を溶かし、いま攻撃が来ている脆弱性を後回しにする - EPSS は FIRST が公開する機械学習モデルで、公開済み CVE が今後30日以内に実世界で悪用される確率（0〜1）を毎日更新する。GitHub は 2025年2月から Dependabot アラートに EPSS を表示する - 実務は CVSS × EPSS の2軸マトリクスで捌く。GitHub 自身の例では『EPSS 85%・CVSS 9.8』は『EPSS 0.5%・CVSS 9.0』より“ほぼ常に”優先。到達可能性（自コードが脆弱な経路を呼ぶか）と依存スコープ（dev/prod）が第3の軸 - auto-triage rules は severity・EPSS・scope・package・CVE・ecosystem・manifest でマッチできる。EPSS しきい値や dev スコープで自動 dismiss/優先し、通知が飛ぶ前にノイズを断つ - 『どれから直すか』の順位付けと『いつまでに直すか』の SLA 運用は別物。少数に集中すれば、少ない工数で“実際に悪用される脆弱性”の大半をカバーできる --- Dependabot のアラートバッジが二桁になった。さて、**どれから直すか**——ここで多くのチームが手を止めます。よくある反応は「**深刻度（Critical/High）の高い順に**」。一見正しそうで、実は**優先順位を誤る**のが最大の罠です。深刻度は「**もし悪用されたらどれだけ痛いか**」しか語らず、「**そもそも悪用されるのか**」を語らないからです。 この記事は[Dependabot 本番運用ガイド](/blog/dependabot-production-guide)の各論として、**「どれから直すか」の順位付け**にフォーカスします。有効化・SLA・auto-triage の運用そのものは[アラート・セキュリティ更新ガイド](/blog/dependabot-security-updates-alerts-vulnerability-management-guide)に譲り、ここでは **CVSS × EPSS × 到達可能性**という3つの軸で、アラート疲れを断ち「**本当に危険な少数**」に集中するトリアージ設計を解説します。 > **この記事のルール**：EPSS/CVSS の定義は **FIRST の一次情報**に、Dependabot の挙動は **GitHub 公式ドキュメント（2026年7月時点）** に忠実です。EPSS は「確率」であって「確定した予言」ではありません。数値は必ず最新を確認し、組織の文脈（公開/社内・規制業種か）で解釈してください。 --- ## 1. なぜ深刻度（CVSS）だけでは優先順位を誤るのか **CVSS（Common Vulnerability Scoring System）** は、脆弱性の**深刻度＝影響の大きさ**を 0〜10 で表す静的なスコアです。GitHub Advisory Database は、メンテナが割り当てた **CVSS v4.0 / v3.1 / v3.0** を取り込み、Dependabot のアラートに severity（Critical/High/Medium/Low）として表示します。 CVSS は「**もし悪用されたらどれだけ痛いか**」を測る優れた指標ですが、決定的に欠けているものがあります——「**実際に悪用されるのか**」です。世の中には CVSS 9.x でも**現実にはほぼ攻撃されない**脆弱性が大量にあり、逆に CVSS が中程度でも**攻撃が観測されている**ものがあります。深刻度の降順に並べて上から潰すと、**めったに攻撃されない Critical に工数を溶かし、いま攻撃が来ている脆弱性を後回しにする**——これが「深刻度ソートの罠」です。 GitHub のたとえが分かりやすい：**CVSS は「家に侵入されたときの被害の大きさ」、EPSS は「実際に誰かが侵入を試みる可能性」**。両方を見なければ、リスクの全体像は描けません。 --- ## 2. EPSS：攻撃される「確率」を測る **EPSS（Exploit Prediction Scoring System）** は、FIRST が公開する**データ駆動の機械学習モデル**で、「公開済みの CVE が**今後30日以内に実世界で悪用される確率**」を **0〜1（0〜100%）** で推定します。 要点は次のとおり（FIRST 公式）： - **意味**：スコアが高いほど、その脆弱性が**近い将来に実際に攻撃される確率が高い**。 - **更新頻度**：**毎日、全 CVE 分**が更新され、CSV / API で公開される。 - **percentile（パーセンタイル）**：絶対確率に加え、「全 CVE の中での相対的な位置」も提供される。 - **CVSS との違い**：CVSS が**主観的な深刻度**を測るのに対し、EPSS は**観測された悪用の実証的シグナル**で「悪用の見込み」を測る。**severity（重大さ）と likelihood（見込み）は別物**です。 つまり EPSS は、CVSS が答えられない「**この脆弱性は、この1か月で実際に狙われるのか？**」に確率で答えます。両者は競合ではなく**補完**です。 --- ## 3. CVSS × EPSS の2軸マトリクスで捌く 順位付けの実装は、**2軸のマトリクス**に落とすと迷いません。 | | **EPSS 高**（攻撃が来ている） | **EPSS 低**（まだ悪用兆候なし） | | --- | --- | --- | | **CVSS 高**（被害大） | **最優先**：即時パッチ＆デプロイ | 計画的に対応（監視しつつ次の定例更新で） | | **CVSS 低**（被害小） | 監視・緩和（悪用は多いが影響は限定的） | 後回し（多くはノイズ。auto-triage の dismiss 候補） | GitHub 自身がこの考え方を例で示しています——**「EPSS 85%・CVSS 9.8」の脆弱性は、「EPSS 0.5%・CVSS 9.0」の脆弱性より“ほぼ常に”優先すべき**。どちらも severity は Critical ですが、**攻撃される確率が桁違い**だからです。深刻度だけを見ていると、この2つは「同じ Critical」として並んでしまいます。 > **なぜ少数集中が効くのか**：EPSS の研究では、**EPSS で優先順位を付ければ、ごく一部の脆弱性に絞って対処するだけで、実際に悪用される脆弱性の大半をカバーできる**と報告されています。「全部直す」ではなく「**危険な少数を確実に直す**」ほうが、有限のエンジニア工数に対してはるかに費用対効果が高い——これが EPSS ベースのトリアージの経済的な根拠です。 --- ## 4. 第3の軸：到達可能性と依存スコープ CVSS × EPSS で「**世の中的な危険度**」は測れます。しかし最後の問いが残ります——「**その脆弱性は、自分たちのアプリで本当に踏めるのか？**」。これが**到達可能性（reachability）**です。 ここで重要な事実：**Dependabot は依存グラフ上に脆弱な依存が“存在するか”で検知**します。**自分のコードが、その脆弱な関数を実際に呼び出すかどうかまでは判定しません**。依存として入っているだけで実際には到達しないコードパスの脆弱性は、**理論上のリスク**にとどまることがあります。 厳密な到達可能性解析は別ツールの領域ですが、実務ではまず**依存スコープ（dev / prod）を代理指標**にします。 - **本番依存（production scope）**：実行時にユーザー入力を処理し得る。**到達可能性が高い**とみなす。 - **開発依存（development scope）**：ビルド・テスト時のみ。本番の攻撃面に露出しにくく、**到達可能性が低い**ことが多い（CI 環境自体の保護は別途必要）。 したがって最終的な優先順位は、**CVSS（影響）× EPSS（確率）× 到達可能性（本番で踏むか）** の3軸で決めます。「本番依存 × 高 CVSS × 高 EPSS」が最優先、「開発依存 × 低 CVSS × 低 EPSS」は auto-triage で自動 dismiss、という具合です。 --- ## 5. GitHub 上での実践 ### 5.1 EPSS でアラートを並べ替える GitHub は **2025年2月から Dependabot アラートに EPSS スコアを表示**しています（GitHub Enterprise Server は 3.17 以降）。EPSS は **FIRST から毎日同期**されます。アラート一覧を **EPSS の高い順にソート**すれば、「攻撃が来ている脆弱性」を最初に手に取れます。深刻度フィルタと併用し、**Critical/High かつ 高 EPSS** を最上段に集めるのが基本動作です。 ### 5.2 auto-triage rules で「通知の前に」ノイズを断つ `auto-triage rules`（自動トリアージ）は、**severity・EPSS・scope・package name・CVE・ecosystem・manifest location** といったメタデータでアラートにマッチし、**通知が飛ぶ前に**自動で dismiss / snooze する仕組みです。EPSS を条件に使えるのが強力で、たとえば次のようなポリシーを機械化できます。 - 「**開発依存（dev scope）かつ 低 EPSS** のアラートは自動 dismiss」——本番到達も攻撃確率も低いものを、そもそも通知しない。 - 「**高 EPSS** は severity に関わらず必ず残す」——確率が高いものを取りこぼさない。 ルールは**通知の前に適用される**ため、「後でフィルタ」ではなく「**そもそも上げない**」を実現します。自動 dismiss は「**本番に影響しない**と論証できるもの」に限定し、**判断がログに残る**運用にしてください。 ### 5.3 REST API で「未対応の危険」を棚卸しする 回すには計測が要ります。Dependabot アラートは **REST API** で取得できるので、**未対応（open）× Critical/High** をダッシュボード化し、SLA 違反を早期検知します。 ```bash # Critical / High の未対応アラートだけを抽出（棚卸し・可観測化の起点） gh api \ -H "Accept: application/vnd.github+json" \ "/repos/{owner}/{repo}/dependabot/alerts?state=open&severity=critical,high" \ --jq '.[] | {number, severity: .security_advisory.severity, package: .dependency.package.name, ghsa: .security_advisory.ghsa_id}' ``` Organization 横断なら `/orgs/{org}/dependabot/alerts` を使い、EPSS の高い順に人手のレビュー順を決めます。「**未対応の高 EPSS が滞留していないか**」を一目で見られる状態が、形骸化を防ぐ最後の砦です。SLA そのものの設計は[アラート・セキュリティ更新ガイド](/blog/dependabot-security-updates-alerts-vulnerability-management-guide)へ。 --- ## 6. 優先順位ポリシーを明文化する トリアージは「その場の勘」ではなく**明文化されたポリシー**で回します。世界最高峰を名乗るなら、次を言語化してチームで共有します。 - **順位付けの式**：本番到達 × EPSS × CVSS の優先順（例：本番 × EPSS≥高 × Critical を最上位）。 - **自動 dismiss の境界**：どの scope・EPSS 帯を auto-triage で落とすか、その**論拠**。 - **例外の扱い**：修正版が無い高 EPSS を、緩和策（到達経路を塞ぐ・機能無効化・WAF）や代替ライブラリ移行でどう凌ぐか。 - **見直しの頻度**：EPSS は毎日動く。**昨日“低”だったものが今日“高”になる**ため、定点観測を欠かさない。 「直せないから放置」ではなく、**意思決定を残す**のがトリアージです。順位付け（本記事）と、いつまでに直すかの SLA・自動化（[本番運用ガイド](/blog/dependabot-production-guide)／[アラート・セキュリティ更新ガイド](/blog/dependabot-security-updates-alerts-vulnerability-management-guide)）は、役割を分けて設計してください。 --- ## 7. よくある誤解を避ける - **「CVSS＝リスク」ではない**。CVSS は**影響**の一軸にすぎません。リスク ≒ 影響 × 確率 × 到達可能性。 - **EPSS は“予言”ではなく“確率”**。EPSS 90% でも攻撃が来ないことはあるし、低 EPSS が突然跳ね上がることもある（だから毎日更新される）。**確率として扱い、定点観測**します。 - **Dependabot は SCA（依存の既知脆弱性）**。自作コードの脆弱性（SQLi/XSS/SSRF/認可不備）は **SAST/DAST** の領域で、EPSS/CVSS の議論とは別レイヤーです。全体像は[Webアプリ脆弱性診断ガイド](/blog/web-application-vulnerability-assessment-owasp-zap-sast-dast-guide)で扱っています。 **「深刻度の高い順に上から」をやめ、「攻撃が来ていて・被害が大きく・本番で踏む少数」に集中する**。これが、有限の工数でサプライチェーンの実リスクを最短で下げる、現時点で最も費用対効果の高いトリアージ設計です。