脆弱性スキャナを入れて満足し、アラートのバッジが二桁になったまま誰も見ていない——これはセキュリティ運用で最もよくある失敗です。Dependabot のアラートは検知にすぎません。価値が出るのは「検知 → トリアージ → 修正 → クローズ」がSLA を持って回り始めてからです。
この記事はDependabot 本番運用ガイドの各論として、脆弱性対応にフォーカスします。設定の話（dependabot.yml）は設定完全ガイドに譲り、ここではアラート・セキュリティ更新・トリアージの運用を掘り下げます。
この記事のルール：機能名・前提条件は GitHub 公式ドキュメント（2026年6月時点） に基づきます。脆弱性対応は仕様変更の影響が大きい領域なので、本番運用前に必ず公式の Dependabot alerts ドキュメントで最新を確認してください。
1. アラートとセキュリティ更新は「検知」と「修正」
| Dependabot alerts | Dependabot security updates | |
|---|---|---|
| 役割 | 検知：脆弱な依存を通知 | 修正：パッチがある脆弱性を直すPRを自動生成 |
| 対象 | 依存グラフ上のすべての脆弱な依存 | そのうち修正版が存在するもの |
| コード変更 | しない | する（manifest / ロックファイルを更新） |
| 何で有効化 | セキュリティ設定でON | セキュリティ設定でON（アラートが前提） |
アラートは何で生まれるか——公式によれば2つの引き金です。
- GitHub Advisory Database に新しい脆弱性が追加されたとき
- リポジトリの依存を更新するコミットをpushしたとき（依存グラフが変化）
GitHub はデフォルトブランチを継続的にスキャンします。アラートには影響を受けるファイルへのリンク・脆弱性の詳細と深刻度（severity）・（あれば）修正バージョンが含まれます。
そして運用上うれしいのが自動クローズ：「Dependabot のセキュリティ更新PRがマージされると、対応するアラートは自動でクローズされる」。手で閉じ忘れる事故が起きません。
2. 有効化と前提条件（ここを外すと「PRが来ない」）
セキュリティ更新が動くための4条件（公式）：
- 依存グラフが有効
- Dependabot alerts が有効
- サポート対象のエコシステム
- 依存が manifest かロックファイルに記載されている
設定箇所：
- リポジトリ単位：Settings → Advanced Security（Code security）で alerts と security updates をON。
- Organization 単位：Global settings（Advanced Security）で全リポジトリに既定適用。新規リポジトリにも自動で効かせたいならここ。
最頻の落とし穴：「セキュリティ更新が前提条件4を満たさない」。例えば
package-lock.jsonを.gitignoreしていると、公式の言う「manifest かロックファイルに記載」を満たさず、更新対象から外れます。ロックファイルはコミットしましょう。
3. auto-triage rules：アラート疲れを根本から断つ
検知が増えると、今度は**アラート疲れ（alert fatigue）**が運用を殺します。auto-triage rules（自動トリアージ）は、通知が飛ぶ前にアラートを自動で dismiss / snooze する仕組みです。
3.1 GitHub プリセット
GitHub がキュレーションするルール。代表例：
- Dismiss low impact issues for development-scoped dependencies：本番に影響しにくい npm の開発依存の低影響アラートを自動 dismiss。
- Dismiss package malware alerts：マルウェア判定の自動 dismiss（既定では無効）。
重要な性質：ルールは通知の前に適用されるため、作成時に自動 dismiss されたアラートは通知すら飛びません。これがノイズ削減の本質です。「通知を後でフィルタ」ではなく「そもそも上げない」。
3.2 カスタムルール
Organization の方針に合わせて、深刻度・スコープ（dev/prod）・パッケージ名・CWE などのメタデータでマッチする独自ルールを作れます。例：
- 「開発依存（development scope）かつ Low/Medium のアラートは自動 dismiss、本番依存は残す」
- 「特定の許容済みパッケージのアラートは snooze」
カスタムルールはパブリックリポジトリ、および GitHub Code Security を有効にした Organization リポジトリで利用できます。
設計指針：自動 dismiss はあくまで『本番に影響しない』と論証できるものに限定します。「面倒だから全部 dismiss」は検知の意味を消します。dev スコープ・低影響を出発点に、dismiss した理由がログに残る運用にしてください。
4. grouped security updates：修正PRをまとめる
脆弱性が同時に複数出ると、1つずつPRが来てレビューが破綻します。grouped security updates は、複数の脆弱性修正をエコシステム単位で1PRに集約します。
設定箇所は3つ：
- リポジトリの Advanced Security 設定
- Organization の Global settings（Advanced Security）
dependabot.ymlのgroups（applies-to: security-updates）で粒度を制御（パッケージ名・依存タイプ・SemVer レベル）
# dependabot.yml — セキュリティ更新を1PRにまとめる例
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "daily"
groups:
security:
applies-to: security-updates
patterns: ["*"]
公式の制約（覚えておく）：
- 異なるエコシステムをまたいだグループ化はしない。
- セキュリティ更新とバージョン更新を同一PRに混ぜない。
5. SLA を持ったトリアージ運用（運用設計の本丸）
ここからがツールではなく運用の話です。世界最高峰を名乗るなら、以下を明文化します。
5.1 深刻度別 SLA を決める
| 深刻度 | 対応SLA（例） | 方針 |
|---|---|---|
| Critical | 1〜2営業日以内 | 最優先。可能なら即パッチ＆デプロイ |
| High | 5営業日以内 | 次スプリントを待たず対応 |
| Medium | 次の定例更新で | バージョン更新の波に乗せる |
| Low / dev-scope | auto-triage で dismiss 検討 | 本番影響が論証できれば抑制 |
数字は組織の前提（公開サービスか社内か、規制業種か）で変わります。大事なのは**「曖昧にしない」**ことです。
5.2 修正できない脆弱性をどうするか
修正版がまだ無い脆弱性は、セキュリティ更新PRも来ません。このとき取り得る選択肢：
- snooze（一時停止）：修正が出るまで待つ意思決定を記録する。
- 緩和策（mitigation）：到達経路を塞ぐ（該当機能を無効化、入力検証を追加、WAFルール）。
- 代替ライブラリへ移行：放置が許されない Critical で修正の見込みがないなら、依存そのものを差し替える。
「直せないから放置」ではなく、意思決定を残すのがトリアージです。
6. 可観測性：未対応を「見える化」する
回す運用には計測がいります。Dependabot アラートは REST / GraphQL API でエクスポートできるので、次の指標をダッシュボード化します。
- 未対応（open）アラート件数（深刻度別）
- 最古アラートの経過日数（SLA 違反の早期警告）
- セキュリティ更新PRの平均滞留時間
REST API でリポジトリのアラートを取得する最小例：
# 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 を使い、結果を BI / スプレッドシート / Slack 通知に流します。「未対応が増え続けていないか」を一目で見られる状態が、形骸化を防ぐ最後の砦です。
7. Dependabot の守備範囲を取り違えない（SCA ≠ SAST/DAST）
ここは案件相談でも頻繁に誤解される点です。
- Dependabot が見るのは「依存（SCA：Software Composition Analysis）」の既知脆弱性。npm/pip/gem などのライブラリに付いた CVE/GHSA を、Advisory Database 照合で検知します。
- 自分たちが書いたコードの脆弱性——SQLインジェクション・XSS・SSRF・認可不備（IDOR）・シークレット漏洩——はDependabot の守備範囲外で、SAST（静的解析）/ DAST（動的診断） の領域です。
両者は補完関係です。サプライチェーン（依存）は Dependabot で自動化し、アプリ自体のロジックは SAST/DAST で診る。この全体像はWebアプリ脆弱性診断（SAST/DAST/SCA）の実践ガイド、AI生成コードのリスクはAI生成コードの脆弱性評価ガイドで扱っています。「Dependabot を入れたから安全」は半分だけ正しい——この線引きを発注者に説明できることが信頼につながります。
8. FAQ
Q. アラートは出るのにセキュリティ更新PRが来ません。 A. その脆弱性に修正版が存在しないか、前提条件（依存グラフ・アラート有効・対象エコシステム・manifest/ロックファイル記載）のどれかを満たしていない可能性が高いです。
Q. アラートが多すぎて見きれません。
A. auto-triage rules で「開発依存の低影響アラートを自動 dismiss」から始め、grouped security updates で修正PRをまとめます。通知前に抑制されるのでノイズが根本から減ります。
Q. セキュリティ更新の同時PR数を増やせますか？
A. セキュリティ更新の open-pull-requests-limit は 10 固定で変更できません。「脆弱性修正は溜めない」という設計です。
Q. 自動 dismiss は危なくないですか？ A. 本番に影響しないと論証できるものに限定すれば有効なノイズ削減です。dev スコープ・低影響を起点にし、dismiss 理由が残る運用にしてください。
Q. Dependabot だけでセキュリティは十分ですか？ A. いいえ。Dependabot は**依存（SCA）**を見ます。自作コードの脆弱性は SAST/DAST が必要です。両輪で初めて多層防御になります。