RubyとRailsのセキュリティアップデート：まだ修正が届くバージョンと、取り残されないための運用
2026年11月7日で、Rails 8.0へのセキュリティ修正の提供が終わりました。その3日前、11月4日のセキュリティリリースではRailsの21件の問題が修正されましたが、8.0にとってはこれが最後です。Rails 8.0以前で動いているアプリでは、次に見つかるRailsの脆弱性は修正されません。
Railsアプリを健全に保つうえで、誰も予定に入れない部分がここです。大きなアップグレードではなく、小さく頻繁に出るセキュリティリリースを当てること、そして自分のバージョンがサポート対象から外れる時期を知っておくこと。この記事では現在の状況と、自社のプロダクションアプリやお客様のアプリで実際に回している運用を紹介します。
今セキュリティ修正が届くバージョン
Rails。 Railsは決まったスケジュールで運用されています。各マイナーシリーズは、最初のリリースから1年間バグ修正、2年間セキュリティ修正を受けます。2026年11月13日時点のRailsのメンテナンスポリシーは次のとおりです。
| Rails | バグ修正 | セキュリティ修正 |
|---|---|---|
| 8.1 | 2026年10月10日まで | 2027年10月10日まで |
| 8.0 | 終了 | 2026年11月7日で終了 |
| 7.2以前 | 終了 | 終了（7.2の最終リリースは2026年9月の7.2.4） |
つまり今セキュリティ修正が届くのは8.1シリーズだけです。最新版は11月4日のRails 8.1.4.1です。
Ruby。 Rubyは毎年12月25日に新しいバージョンが出ます。Rubyのブランチ情報によると次のとおりです。
| Ruby | 状態 | サポート終了 |
|---|---|---|
| 4.0 | 通常メンテナンス（バグ修正とセキュリティ修正） | 未発表 |
| 3.4 | 通常メンテナンス | 未発表 |
| 3.3 | セキュリティメンテナンスのみ | 2027年3月末 |
| 3.2以前 | サポート終了 | 3.2は2026年4月1日に終了 |
最新のパッチリリースは、いずれも2026年10月23日の4.0.9、3.4.12、3.3.13です。ここ数年、各ブランチは3年余りの通常メンテナンスのあと、1年間セキュリティ修正のみの期間に入っています。Ruby 3.3に残された期間はあと4か月ほどです。
Rails 8.0とRuby 3.3の組み合わせなら数か月はしのげますが、Railsはすでに1バージョン遅れで、Rubyも期限が近づいています。
告知はどこから来るか
すべての変更履歴を読む必要はありませんが、次の告知は誰かが必ず見ているべきです。
- Ruby： セキュリティ情報はruby-lang.orgのニュースとして公開され、RSSでも受け取れます。Ruby本体ではなく、Rubyに同梱されているgemの問題であることも多いです。2026年8月には同梱の
resolvgemに2件のCVEが見つかりましたが、修正はRubyの新バージョンを待つのではなく、そのgemを0.7.2に更新することでした。 - Rails： Rails Security Announcementsのフォーラムに公開解禁と同時に告知が出て、セキュリティメーリングリストにも同じ内容が届きます。修正はすべてGitHubのセキュリティアドバイザリとして登録され、当日中にアップグレードできない場合に当てられるパッチへのリンクもあります。
- そのほかのgem： bundler-auditが参照するRuby Advisory Database。2026年10月からはrubygems.orgのgemページにも脆弱性の警告が表示されるようになりました。
運用
1. CIのたびにGemfile.lockをチェックする
bundler-auditはGemfile.lockを脆弱性データベースと照合し、安全でないgemソースも検出します。
gem install bundler-audit
bundle-audit check --update
--updateで先に最新のアドバイザリを取得します。これを付けないと、そのマシンにたまたまあるデータベースでチェックすることになり、CIのランナーでは数か月前のものかもしれません。
Rails 8.1で新規作成したアプリには、最初からbundler-auditとBrakemanが入っています。bin/bundler-audit、無視リストのconfig/bundler-audit.yml、両方を実行するCIのジョブも生成されます。ただしRails 8.1.4.1のbinstubは--updateを渡さないので、修正版が出るまではCIでbin/bundler-audit check --updateと自分で付けてください。古いアプリには2つのgemを追加します。
group :development, :test do
gem "bundler-audit", require: false
gem "brakeman", require: false
end
Brakemanは自分のコードの脆弱性（SQLインジェクション、安全でないリダイレクト、マスアサインメントなど）を静的解析で見つけます。これは脆弱性データベースではわかりません。
自分のアプリに当てはまらないアドバイザリは、チェック自体を止めるのではなく、理由をコメントに書いてIDを無視リストに入れます。
2. セキュリティリリースは次のアップグレードを待たず、数日以内に当てる
セキュリティリリースで変わるのはパッチ番号だけ（8.1.4から8.1.4.1）なので、いちばん安上がりな更新です。小さいまま当てましょう。
bundle update --patch --strict rails
--patchは次のパッチバージョンを優先し、--strictでそれを上限にします。これで別のgemの新しいマイナーバージョンが一緒に入ってくることはありません。--conservativeを付けると、そのgemの依存gemも更新しません。テストを通してデプロイすれば完了です。
Bundlerの依存クールダウン（Bundler 4.0.13以降、任意で有効化）で新しすぎるバージョンを避けている場合、急ぎのセキュリティ修正には--cooldown 0を付けます。
Dependabotのセキュリティアップデートを有効にすると、アドバイザリがGemfile.lockに該当したときにプルリクエストが作られます。CIのチェックを補うものであって、代わりにはなりません。プルリクエストが放置されたまま、ほかの変更がマージされ続けることもあるからです。
3. Ruby本体も忘れない
Rubyのパッチリリースも同じ種類の変更で、3.4.11から3.4.12への更新は本来何も起きないはずです。更新する場所は2つです。
.ruby-version（Gemfileのruby行でパッチまで固定している場合はそこも）。インストールし直してテストを実行します。- Dockerイメージ。公式の
ruby:3.4-slimタグは常に3.4の最新パッチを指すので、ビルドキャッシュを使わずにイメージを作り直せば反映されます。ruby:3.4.11-slimのようにフルバージョンで固定したタグは動かないので、再現性は高い代わりに手で上げる必要があります。
4. サポート終了日を、来る前に把握しておく
ここまでの運用は、使っているバージョンにパッチが届いている間しか機能しません。RailsやRubyのシリーズがサポート終了を迎えると、セキュリティリリースはただ来なくなります。Railsのガイドもはっきり書いていて、それ以降のセキュリティ問題への対応は自己責任です。
だから日付をカレンダーに入れておきましょう。Rails 8.0のアプリなら、8.1へのアップグレードはもう遅れています。Ruby 3.3なら、2027年3月末までに3.4か4.0への移行を計画してください。1マイナーバージョンずつ上げれば、各ステップは小さくレビューしやすいままです。アップグレードが大仕事になるのは、何バージョンも先送りしたときです。
チェックリスト
- [ ] CIで
bundle-audit check --updateとBrakemanを実行し、問題があればビルドを失敗させている - [ ] Railsのセキュリティ告知とruby-lang.orgのセキュリティ情報を受け取る担当者がいる
- [ ] Dependabotのセキュリティアップデートが有効
- [ ] セキュリティリリースは
bundle update --patch --strictで当て、数日以内にデプロイしている - [ ] Rubyのパッチリリースを
.ruby-versionとDockerイメージに反映している - [ ] 使っているRailsとRubyのサポート終了日がカレンダーにあり、その前にアップグレードを計画している
私たちは自社のアプリJapan VoyageをRailsとRubyの開発ブランチで動かしているので、この運用を毎週回しています。また私はJRubyアンバサダーとしてJRuby本体に貢献していて、最近は主にFiber周りに取り組んでいます。RailsのJRuby対応にも着手したところです。8.1.4.1のセキュリティリリースがあった週のRails Foundationの「This Week in Rails」では、プルリクエストが取り上げられたコントリビューターの一人として名前を挙げてもらいました（Rails Foundationの投稿）。すでにセキュリティ修正が届かないバージョンで動いているアプリや、告知の確認とリリースの適用を毎月任せたい場合は、RailsとRubyのアップグレードのサービスをご覧ください。