脆弱性スキャナを入れて満足し、アラートのバッジが二桁になったまま誰も見ていない——これはセキュリティ運用で最もよくある失敗です。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 を入れたから安全」は半分だけ正しい——この線引きを発注者に説明できることが信頼につながります。