🤖

Dependabotで依存関係更新を仕組み化する取り組み

に公開

こちらはe-dash advent calendar 2025 17 日目の記事となります。

はじめに

こんにちは! e-dash株式会社、フロントエンドエンジニアのtagawaです。
2025年12月は、React の一部コンポーネントに深刻な脆弱性「CVE-2025-55182」が見つかった矢先、Node.js でも High が3件を含む脆弱性が見つかるなど、慌ただしい年末になっていますね。
これをお読みの皆さまは、ライブラリの更新をしっかり実施できていますでしょうか?
今回はDependabotを導入して、ライブラリを最新バージョンに保つ取り組みをご紹介します。

背景

私たちのチームで開発していたプロジェクトがいったん区切りを迎えたタイミングで、今後の運用方法を議論していました。
その中でひとつ挙がったのが、依存ライブラリをどう更新し続けるかという課題です。
依存ライブラリの更新を放置すると、次のような問題が起きやすくなります。

  • 依存関係の解消に時間がかかる:いざ更新が必要になったとき、依存関係の解消に多大な時間を要す
  • 脆弱性の放置:対応が遅れるほどリスクが高まる
  • 潜在的なバグの残存:古いバージョンに含まれるバグが放置される

ただ、これらを人力で追いかけながら、継続的に更新し続けるのは大変です。
そこで、この課題を解決するためにDependabotを導入しました。

Dependabotとは?

Dependabotは、GitHub上のリポジトリで依存関係のメンテナンス(更新)とセキュリティ対応(脆弱性対応)を支援してくれる機能です。
依存ライブラリの更新提案を自動化しつつ、公開されている脆弱性情報をもとにリスクの早期発見・対処を後押ししてくれます。

役割は大きく次の3つです。

  • Dependabot alerts:依存関係に含まれる脆弱性を検知し、通知する(検知)
  • Dependabot security updates:脆弱性修正のための更新PRを自動作成(セキュリティ対応)
  • Dependabot version updates:脆弱性に限らないバージョン更新PRを自動作成(継続運用)

導入方法

Dependabotの導入は非常に簡単です。まずはGitHubのリポジトリ設定でアラートやセキュリティ更新を有効化します。

dependabot

加えて、リポジトリに.github/dependabot.yml を用意すると、更新対象・実行間隔・更新範囲・除外ルールなどを細かく調整できます。

たとえば私たちのチームでは、週1回実行・関連ライブラリはグルーピング・メジャーアップデートは除外という方針で、次のように設定しています。

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"

    # 毎週木曜 08:00(JST)に依存関係の更新PRを作成
    schedule:
      interval: "weekly"
      day: "thursday"
      time: "08:00"
      timezone: "Asia/Tokyo"

    # PRが細かく分散してノイズにならないよう、関連ライブラリはまとめて更新
    groups:
      aws-sdk:
        patterns:
          - "@aws-sdk/*"
      mui:
        patterns:
          - "@mui/*"
      react:
        patterns:
          - "react"
          - "react-dom"
          - "@types/react"
          - "@types/react-dom"
      tailwind:
        patterns:
          - "tailwindcss"
          - "@tailwindcss/*"
          - "tailwind-merge"
          - "tailwind-variants"

    # メジャーバージョンアップデートはチームで確認の上手動で行うため、検知を除外
    ignore:
      - dependency-name: "*"
        update-types:
          - "version-update:semver-major"

Dependabotの設定方法についての詳細はGitHub公式ドキュメントを参照してください。

導入直後のハードル

Dependabot導入直後は、直近まで依存関係の更新が止まっていた期間が長いほど、更新PRが一気に溜まりがちです。
最初からメジャーアップデートまで対象にすると差分が大きくなり、対応コストや不具合リスクも上がります。

そこで、まずは security updates(脆弱性対応) のような重要度の高い範囲から始め、運用が回ることを確認しつつ、段階的に対象を広げるのがおすすめです。
たとえば、下記のようにメジャーアップデートは一旦除外しておくと更新時の問題が発生しにくくなります。

    ignore:
      - dependency-name: "*"
        update-types:
          - "version-update:semver-major"

以上で導入までは完了です。次は、Dependabot導入後に得られた効果を振り返ります。

導入後の効果検証

Dependabot導入によりどのような効果があったのか一例として、私たちのチームでこの1年間ライブラリ更新を継続した結果を、セキュリティ・品質(バグ)・パフォーマンスの観点で紹介します。

セキュリティ脆弱性の修正

最も大きな成果は、依存関係に起因する複数の脆弱性を継続的に解消できたことです。
以下はその一例です。

  • Vite(v5.4.10 → v5.4.21)

    • CVE-2025-30208
      • 不正なURLパラメータによるファイルアクセス制限のバイパス
      • .envファイル、SSL証明書、ソースコードなどの任意のファイルが読み取られる可能性
    • CVE-2025-31486
      • SVGと相対パスによるserver.fs.denyバイパス
  • @aws-sdk(v3.705.0 → v3.857.0)

  • @remix-run(v2.13.1 → v2.17.0)

    • CVE-2025-31137(GHSA-4q56-crqp-v477)
      • Host/X-Forwarded-Hostヘッダーを介したURL操作脆弱性
    • ポートサニタイゼーション不備によるURL操作と潜在的なキャッシュ汚染
    • Cookie関連の脆弱性対応
    • X-Forwarded-Hostヘッダー検証の強化
  • Vitest(2.0.0 → 2.1.8)

    • APIサーバー稼働中に悪意のあるウェブサイトにアクセスすると、リモートコード実行される可能性がある脆弱性を修正
  • その他、間接的な脆弱性

    • path-to-regexp(< 0.1.12)
      • ReDoS(正規表現サービス拒否攻撃)の脆弱性
      • 特定の入力でCPUを100%消費させられる
    • tar-fs(v2.0.0 → 2.1.2)
      • リンク追跡とパストラバーサル攻撃
      • 悪意のあるtarファイルで指定ディレクトリ外にファイルを展開される
    • cross-spawn(v7.0.0 → 7.0.4)
      • ReDoS攻撃の脆弱性
      • プロセス実行時にサービス拒否攻撃を受ける可能性
    • @remix-run/express(<= 2.16.3)
      • HostヘッダーやX-Forwarded-Hostヘッダーを使ったURL操作攻撃
      • リダイレクト攻撃やフィッシング攻撃に悪用される可能性

バグ解消

Dependabotで依存関係を定期的に更新することで、日々の開発・運用で潜在的に存在していた不具合なども解消できました。たとえば次のような改善です。

  • メモリリークの修正
  • SSR周りのハイドレーションエラーの修正
  • 状態管理に起因する不整合の解消
  • 型チェックの不整合の解消
  • 特定条件でのクラッシュの修正

パフォーマンス向上

大きな数値改善ではないものの、体感と計測の両面で軽微な改善も確認できました。

  • ビルド時間の短縮:Vite、Tailwind、Vitest(テスト実行が2-4%改善)
  • 描画速度の向上:MUI、@mui/x-data-grid

今後の課題と展望

近年は、特定企業を狙ったnpmパッケージのサプライチェーン攻撃も増えており、OSSを利用する誰もが影響を受ける可能性があります。
Dependabotの運用を継続しつつ、更新を安全に取り込むためのcooldownの導入など、運用をより堅くしていきたいです。

おわりに

Dependabotを導入することで、依存関係の更新を「思い出したときにやる作業」から「継続的に回る仕組み」へ置き換えられました。
まずは小さく(security updates中心に)始めて、チームの運用に合わせて徐々に育てていくのがおすすめです。

それでは、みなさまクリスマスまで楽しい日々をお過ごしください!

Discussion