Dependabot のアラートバッジが二桁になった。さて、どれから直すか——ここで多くのチームが手を止めます。よくある反応は「深刻度（Critical/High）の高い順に」。一見正しそうで、実は優先順位を誤るのが最大の罠です。深刻度は「もし悪用されたらどれだけ痛いか」しか語らず、「そもそも悪用されるのか」を語らないからです。
この記事はDependabot 本番運用ガイドの各論として、「どれから直すか」の順位付けにフォーカスします。有効化・SLA・auto-triage の運用そのものはアラート・セキュリティ更新ガイドに譲り、ここでは 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 違反を早期検知します。
# 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 そのものの設計はアラート・セキュリティ更新ガイドへ。
6. 優先順位ポリシーを明文化する
トリアージは「その場の勘」ではなく明文化されたポリシーで回します。世界最高峰を名乗るなら、次を言語化してチームで共有します。
- 順位付けの式：本番到達 × EPSS × CVSS の優先順（例：本番 × EPSS≥高 × Critical を最上位）。
- 自動 dismiss の境界：どの scope・EPSS 帯を auto-triage で落とすか、その論拠。
- 例外の扱い：修正版が無い高 EPSS を、緩和策（到達経路を塞ぐ・機能無効化・WAF）や代替ライブラリ移行でどう凌ぐか。
- 見直しの頻度：EPSS は毎日動く。昨日“低”だったものが今日“高”になるため、定点観測を欠かさない。
「直せないから放置」ではなく、意思決定を残すのがトリアージです。順位付け（本記事）と、いつまでに直すかの SLA・自動化（本番運用ガイド／アラート・セキュリティ更新ガイド）は、役割を分けて設計してください。
7. よくある誤解を避ける
- 「CVSS＝リスク」ではない。CVSS は影響の一軸にすぎません。リスク ≒ 影響 × 確率 × 到達可能性。
- EPSS は“予言”ではなく“確率”。EPSS 90% でも攻撃が来ないことはあるし、低 EPSS が突然跳ね上がることもある（だから毎日更新される）。確率として扱い、定点観測します。
- Dependabot は SCA（依存の既知脆弱性）。自作コードの脆弱性（SQLi/XSS/SSRF/認可不備）は SAST/DAST の領域で、EPSS/CVSS の議論とは別レイヤーです。全体像はWebアプリ脆弱性診断ガイドで扱っています。
「深刻度の高い順に上から」をやめ、「攻撃が来ていて・被害が大きく・本番で踏む少数」に集中する。これが、有限の工数でサプライチェーンの実リスクを最短で下げる、現時点で最も費用対効果の高いトリアージ設計です。