【初学者向け】PHPの緊急パッチのニュースで理解した「Dependabotを放置してはいけない理由」と対処法

Last updated at 2026-10-22Posted at 2026-10-22

はじめに

ハーブティーのレシピ管理アプリ「Herb Recipe Lab」（Rails 8.1 / Turbo 8 / Render / Neon）を個人開発しています。
MVPをリリースし、本リリースに向けて開発していたところ、コードレビューしてくださった先輩にこう言われました。

「DependabotのPRが10件溜まってるけど大丈夫？」

Dependabotが何なのかわからず、届いていたPRを放置していたのです。さらに設定を確認すると、脆弱性を知らせてくれる「Dependabot alerts」自体が Off でした。

ちょうど同じころ、PHPの緊急パッチのニュースを読み、自分の状態がどれだけ危なかったかを理解したので、学んだことをまとめます。

対象読者：Dependabotの通知やPRを、よくわからないまま放置している初学者の方

GitHubの画面名やメニューの場所は変わることがあります。この記事は2026年10月時点の公式ドキュメントをもとにしています。

1. きっかけ：PHPの緊急パッチ

2026年10月21日、PHP公式がセキュリティ勧告を出しました。

深刻度 Critical の脆弱性が2件。悪用されると、ログインしていない外部の人がサーバー上でプログラムを実行できる可能性がある
修正版が公開され、すべての利用者に すぐ更新するよう呼びかけ
前日には予告も出ており、詳細が漏れたり攻撃が確認されたりした場合は前倒しで公開する、とされていた

修正版が公開されると、攻撃者は 修正前後のコードの差分 から穴の場所を正確に知ることができます。つまり 「パッチが出た＝穴の場所が世界中にバレた」合図 で、そこから守る側と攻める側の競争が始まります。

Railsアプリでも同じ

Railsアプリは数十〜数百個の gem（ライブラリ）の上に乗っています。gem に脆弱性が見つかり修正版が出れば、PHPと同じ状況になります。それを知らせてくれるのが Dependabot です。

	PHPのニュース	自分のRailsアプリ
穴があったもの	PHP本体	使っている gem
修正版の知らせ	公式発表	Dependabotのアラート
直す人	サーバー管理者	自分

2. Dependabotとは？

GitHubに組み込まれた、依存パッケージを管理する機能です。3つの機能があり、それぞれ別々に On / Off できます。

機能	役割	何をしてくれる？
Dependabot alerts	見張り役	使っている gem に脆弱性があると知らせる
Dependabot security updates	修理役	アラートが出た gem を安全なバージョンに上げるPRを作る
Dependabot version updates	整備役	脆弱性がなくても定期的に最新化するPRを作る

アラートは、脆弱性情報のデータベースに新しい情報が追加されたときにも出ます。自分が何もしていなくても、ある日突然アラートが出る ことがあります。

3. なぜ放置してしまったのか

① dependabot.yml があっても、アラートは Off だった

ここが一番の落とし穴でした。

Rails 7.2以降で rails new すると、.github/dependabot.yml が最初から入っていることがあります。私のアプリにもありました。

.github/dependabot.yml

version: 2
updates:
- package-ecosystem: bundler
  directory: "/"
  schedule:
    interval: weekly
  open-pull-requests-limit: 10
- package-ecosystem: github-actions
  directory: "/"
  schedule:
    interval: weekly
  open-pull-requests-limit: 10

これが設定するのは version updates だけ です。設定画面を見ると、alerts と security updates はどちらも Off でした。

公式ドキュメントにも、公開リポジトリでも Dependabot alerts はデフォルトでは生成されない、と書かれています。「Dependabot からPRが来ている＝脆弱性も見張ってくれている」ではありません。

② 溜まっていたPRの中身を判断できなかった

security updates が Off だったので、10件はすべて version updates のPRです。ただし新しいバージョンにはセキュリティ修正が含まれていることも多く、alerts が Off では 急いで入れるべき修正があったのかどうか、判断する手がかりがありませんでした。

open-pull-requests-limit: 10 は 同時に開いておけるPRの上限 です。上限に達すると、PRを処理するまで新しいPRは作られません。10件溜まっていた私のアプリは、新しい更新PRも来ない状態 だった可能性があります。

③ パブリックだと、溜まったPRは「看板」になる

リポジトリをパブリックにしていると、PRも誰でも見られます。DependabotのPRが開きっぱなしだと、外から「この gem、まだ古いままだな」とバレバレ。「うち、ここの鍵かかってません」という看板を玄関に掲げているようなもの です。

正確に言うと…

アラート一覧そのものは公開されません（見られるのは権限のある人だけ）
ただ、パブリックなら Gemfile.lock も丸見え です。開きっぱなしのPRは、それを「未対応リスト」としてわかりやすくまとめちゃっている状態です
プライベートにすれば安心、でもありません。公開中のサイトから手がかりを集められることもあるので、隠すより、さっさと直す のが一番です

④ 仕組み上、気づきにくいポイントもあった

公式ドキュメントを読んで知ったことです。

alerts を有効にした時点で、すでに見つかっている脆弱性は通知されない。On にしたら自分で一覧を確認する必要がある
通知はリポジトリを Watch して、セキュリティアラートの通知を有効にしている人にしか届かない
PRに反応しない状態が続くと、Dependabot が更新を一時停止することがある

そして何より、脆弱性は「動作」には出てきません。アプリが普通に動いていても、穴は開いています。

4. アラートが来たときの対処法

4-1. アラート一覧を開く

次のURLを直接開くのが確実です。

https://github.com/<ユーザー名>/<リポジトリ名>/security/dependabot

画面からたどる場合は、リポジトリの Security タブ（表示によっては「Security and quality」）から Dependabot を選びます。

一覧が見つからないときは、まず Dependabot alerts が On になっているか 確認してください（5-1 参照）。

Dependabot のPRは、Pull requests タブで is:pr is:open author:app/dependabot と検索すると絞り込めます。

4-2. 優先順位をつける

一覧は Most important（重要度順）に並んでいるので、上から見ればOK
深刻度は Critical → High → Moderate → Low の順に対応
本番で使う gem を優先。「Development」ラベル付きは開発用（scope:development で絞り込み可）

4-3. 直す

パターンA：DependabotのPRをマージする
アラート画面に修正PRへのリンクがあります。なければ Create Dependabot security update ボタンで作れます。Dependabotは 修正が入っている最小のバージョン に上げてくれるので、壊れにくいです。CIが通っていることを確認してマージします。

パターンB：自分で更新する
間接的に使っている gem の場合など、Dependabotが自動で直せないことがあります。

git switch -c chore/update-<gem名>
bundle update <gem名> --conservative   # 指定した gem 以外はなるべく変えない
git diff Gemfile.lock                  # 何が上がったか確認
bin/rails test                         # RSpecなら bundle exec rspec

4-4. 確認してデプロイ

CIとローカルで主要な機能（ログインなど）を確認し、本番にデプロイします。マージしただけでは本番は直っていません。

4-5. 今すぐ直せないとき（Dismiss）

計画中の大きな更新や誤検知などの場合は、理由を選んでアラートを Dismiss（却下） できます。コメントで理由を残しておきましょう。

「よくわからないからDismiss」は放置と同じです。 迷ったら先輩やチームに相談しましょう。

5. 二度と放置しないための設定

5-1. alerts と security updates を On にする

リポジトリの Settings → セキュリティ関連の項目（公式ドキュメントでは「Advanced Security」）→ Dependabot の欄で設定します。

項目	おすすめ
Dependabot alerts	On
Dependabot security updates	On
Grouped security updates	PRが多くて大変なら On
Malware alerts / auto-triage rules	alerts を On にすると表示される。auto-triage は中身を一度確認

On にしたら、すぐにアラート一覧を開いて確認 しましょう（既存の脆弱性は通知されないため）。

5-2. dependabot.yml を見直す

.github/dependabot.yml

# 設定ファイルの書式のバージョン。必ず 2 を指定する（必須）
version: 2

# 監視するパッケージマネージャーごとに、設定を並べて書く（必須）
updates:
  # ---------- 1つ目：Ruby の gem（Gemfile / Gemfile.lock） ----------
  - package-ecosystem: "bundler"    # 監視するパッケージマネージャー。Rails の gem は "bundler"
    directory: "/"                  # Gemfile がある場所。リポジトリ直下なら "/"
    schedule:
      interval: "weekly"            # 新しいバージョンを確認する頻度（daily / weekly / monthly）
      day: "monday"                 # 【追加】weekly のときの曜日。省略すると月曜日
      time: "09:00"                 # 【追加】確認を始める時刻。省略すると時刻はランダムに決まる
      timezone: "Asia/Tokyo"        # 【追加】time のタイムゾーン。これがないと日本時間にならない

    # 同時に開いておけるPRの上限（「1回に作るPRの数」ではない）
    # 上限に達すると、既存のPRをマージかクローズするまで新しいPRは作られない
    # 元の設定は 10。溜めずにこまめに処理する前提で 5 に減らした
    open-pull-requests-limit: 5

    # 【追加】複数の gem の更新を、1つのPRにまとめるルール
    groups:
      minor-and-patch:              # グループ名（自由に付けられる。PRのタイトルなどに使われる）
        patterns:
          - "*"                     # 対象にする gem 名。"*" はすべての gem
        update-types:               # まとめる更新の種類
          - "minor"                 # マイナー更新。例：1.2.0 → 1.3.0（機能追加など）
          - "patch"                 # パッチ更新。例：1.2.0 → 1.2.1（バグ修正など）
        # "major"（例：1.x → 2.0）はあえて入れていない
        # メジャー更新は大きな変更が入りやすいので、gem ごとに別のPRで1つずつ確認する

  # ---------- 2つ目：GitHub Actions ----------
  - package-ecosystem: "github-actions"  # .github/workflows の中で使っている Action を監視
    directory: "/"                       # Actions の場合も "/" でOK（.github/workflows を自動で見てくれる）
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 5          # 省略した場合の既定値も 5

脆弱性を直すPR（security updates）は、このスケジュールや上限とは別枠 で作られます。

5-3. 通知と運用ルール

リポジトリの Watch → Custom → Security alerts にチェックを入れる
週1回、アラートとPRを確認する
Critical / High はその日のうちに対応を始める
PRは溜めない
新しいリポジトリを作ったら、最初に alerts と security updates が On か確認する

まとめ

修正版が出た直後は 「穴の場所が世界中にバレた」状態。PHPのニュースもDependabotのアラートも同じ構図
dependabot.yml があっても、alerts と security updates は別に On にしないと動かない
パブリックリポジトリでは、溜まったPRは 「まだ直してません」の看板 になる。隠すより直す
アラートは 見て、直して、デプロイして 初めて意味がある
設定と定期確認のルールで、放置を防ぐ

わからないものを、わからないまま放置しない。セキュリティの通知ほど、それが大事だと痛感しました。
同じように Dependabot の通知を放置している方の参考になれば嬉しいです。

参考

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up