# Dependabot アラート・セキュリティ更新・脆弱性対応ガイド：検知で終わらせず、SLA で回す運用設計 > GitHub の Dependabot アラートとセキュリティ更新を本番品質で運用するガイド。公式ドキュメント（2026年6月時点）に忠実に、アラートとセキュリティ更新の違い、有効化の前提条件、auto-triage rules（自動トリアージ）でアラート疲れを防ぐ方法、grouped security updates、SLA を持ったトリアージ運用、REST API での可観測性までを、SCA と SAST/DAST の役割分担を含めて実コードで解説します。 - 公開日: 2026-06-28 - 著者: 友田 陽大 - タグ: Dependabot, サプライチェーンセキュリティ, 脆弱性管理, DevSecOps, セキュリティ, GitHub Actions - URL: https://tomodahinata.com/blog/dependabot-security-updates-alerts-vulnerability-management-guide - カテゴリ: Dependabot・依存関係の自動更新 - 総合ガイド: https://tomodahinata.com/blog/dependabot-production-guide ## 要点 - アラートは『検知』、セキュリティ更新は『パッチがある脆弱性を直すPR』。アラート→セキュリティ更新→マージでアラートは自動クローズされる - セキュリティ更新の前提は4つ：依存グラフ有効・アラート有効・サポート対象エコシステム・依存が manifest かロックファイルに記載。ロックファイルの .gitignore は対象漏れの典型 - auto-triage rules で『本番に影響しにくい開発依存の低影響アラート』などを自動 dismiss できる。ルールは通知の前に適用されるのでノイズが根本から減る - grouped security updates でエコシステム単位に脆弱性修正を1PRへ集約。ただしエコシステム横断・バージョン更新との混在はしない - ツール導入＝運用ではない。Critical/High の対応SLA、開発依存の扱い、dismiss 基準を明文化し、未対応件数・最古アラート経過日数を REST API で可観測化して初めて回る --- 脆弱性スキャナを入れて満足し、**アラートのバッジが二桁になったまま誰も見ていない**——これはセキュリティ運用で最もよくある失敗です。Dependabot のアラートは**検知**にすぎません。価値が出るのは「**検知 → トリアージ → 修正 → クローズ**」が**SLA を持って回り始めて**からです。 この記事は[Dependabot 本番運用ガイド](/blog/dependabot-production-guide)の各論として、**脆弱性対応**にフォーカスします。設定の話（`dependabot.yml`）は[設定完全ガイド](/blog/dependabot-yml-configuration-complete-guide)に譲り、ここでは**アラート・セキュリティ更新・トリアージの運用**を掘り下げます。 > **この記事のルール**：機能名・前提条件は **GitHub 公式ドキュメント（2026年6月時点）** に基づきます。脆弱性対応は仕様変更の影響が大きい領域なので、本番運用前に必ず[公式の Dependabot alerts ドキュメント](https://docs.github.com/en/code-security/dependabot/dependabot-alerts)で最新を確認してください。 --- ## 1. アラートとセキュリティ更新は「検知」と「修正」 | | Dependabot alerts | Dependabot security updates | | --- | --- | --- | | 役割 | **検知**：脆弱な依存を通知 | **修正**：パッチがある脆弱性を直す**PRを自動生成** | | 対象 | 依存グラフ上の**すべての**脆弱な依存 | そのうち**修正版が存在する**もの | | コード変更 | しない | する（manifest / ロックファイルを更新） | | 何で有効化 | セキュリティ設定でON | セキュリティ設定でON（アラートが前提） | アラートは何で生まれるか——公式によれば**2つの引き金**です。 1. **[GitHub Advisory Database](https://github.com/advisories) に新しい脆弱性が追加された**とき 2. リポジトリの依存を**更新するコミットをpush**したとき（依存グラフが変化） GitHub は**デフォルトブランチを継続的にスキャン**します。アラートには**影響を受けるファイルへのリンク・脆弱性の詳細と深刻度（severity）・（あれば）修正バージョン**が含まれます。 そして運用上うれしいのが**自動クローズ**：「Dependabot のセキュリティ更新PRがマージされると、対応するアラートは自動でクローズされる」。手で閉じ忘れる事故が起きません。 --- ## 2. 有効化と前提条件（ここを外すと「PRが来ない」） セキュリティ更新が動くための**4条件**（公式）： 1. **依存グラフが有効** 2. **Dependabot alerts が有効** 3. **サポート対象のエコシステム** 4. **依存が 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 レベル） ```yaml # 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 でリポジトリのアラートを取得する最小例： ```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` を使い、結果を 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）の実践ガイド](/blog/web-application-vulnerability-assessment-owasp-zap-sast-dast-guide)、AI生成コードのリスクは[AI生成コードの脆弱性評価ガイド](/blog/ai-generated-code-vulnerability-assessment-vibe-coding-security-guide)で扱っています。「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** が必要です。両輪で初めて多層防御になります。