RailsアップグレードのTipsソフトウェアがEOLを迎えるとどうなるか?不具合のアップデートがされなくなるセキュリティリスクが発生するEOLについてRailsの場合どう説明されているかまとめ、EOLを放置しアップグレードしないと発生する具体的な不利益はなにか?参考リンクPR目的ソフトウェアのバージョンアップを何のためにするのか理解する対象読者エンジニアからソフトウェアのアップデート作業の工数を取ることを求められるプロダクトオーナーなど意思決定者スケジュールや決済券を持つ人にソフトウェアノップデート工数を獲得したいエンジニアPRUZUMAKIではアジャイル開発で新規事業の開発から、大規模Webアプリケーションのアーキテクチャ更新などの開発をしています。お問い合わせはUZUMAKIのHPのお問合せフォームから株式会社UZUMAKIUZUMAKI(うずまき)はエンジニア・デザイナー・ディレクターで構成されるギルド型開発チーム。成長するWebサービスやアプリのリニューアル・リファクタリングに強みがあります。略で製品の更新を意味します。ソフトウェアのサポートが終了し、新たに発見されたセキュリティの問題が修正されません。商用のソフトウェアの場合、問い合わせにも対応されません。RubyとRailsの直近のEOLスケジュールまずはUZUMAKI社がクライアント各位から頼まれるRubyやRailsのアップグレード案件でも説明に使う直近のEOLスケジュールを共有します。明記なしRailsアップグレード用語の整理RailsのアップグレードとはRailsのフレームワークのバージョンを上げることを指します。Railsのバージョンをどのレベルで上げるか小数点単位で上げるのか整数単位で上げるのかによって名前が違います。API変更はないRubyとRailsのバージョン番号に対する意味合いはほぼ同じです。0.1単位のバージョン変更でも使われないメソッドや非推奨のメソッドなどがあるので大雑把に「0.1上げるだけだからテストもしないでいいや」というわけには行かないのでご注意ください。0.0.1単位のパッチであればprivateなメソッドを直接呼ぶなどトリッキーなことをしていない限りは問題ないでしょう。Railsの制約条件2023年もサポート対称内のバージョンでサービスを維持するにはRuby3.0とRails6.1の組み合わせまではアップグレードが必要です。6.1と刻むべきRailsのバージョンを変更する場合、マイナーバージョンを1つずつゆっくりと上げながら、その都度表示される非推奨機能の警告メッセージを上手に利用するのがベストです。Railsガイドアップグレード手順よりソフトウェアがEOLを迎えるとどうなるか?不具合のアップデートがされなくなるEOLを過ぎると新たなバグや脆弱性が発見されても改修が行われないため、自社(自分)でセキュリティ面の強化や運用対処などの回避策を取る必要があります。これは現実的ではありません。最初の一つの脆弱性の対応のパッチを当てることはできるかも知れませんがそれが2つ3つと増えてきたときに整合性を保つことは難しいです。技術的に高度なことをするため運用の負荷が増したり、属人化の原因になったりします。セキュリティリスクが発生する新たな脆弱性が発覚しても修正が行われないため、セキュリティリスクを抱えた状態で運用することになります。これはOSやアプライアンスの場合は特に重大な脆弱性が発見された場合、無差別に攻撃されると、EOLを迎えたものを使い続けていると攻撃を受けるリスクが高まります。現在のリリースシリーズ、および1つ前のリリースシリーズには、セキュリティ問題発生時にパッチや新バージョンが提供されます。これらのリリースは、直近にリリースされたバージョンにセキュリティパッチを適用してリリースされます。続いて、それらのパッチはx-y-stable(安定版)ブランチの最後に適用されます。1.2.3というセキュリティリリースは、理論上1.2.2を元にビルドされ、1-2-stableの最後に追加されます。最新のRailsを利用していればセキュリティリリースへのアップグレードを容易に行えます。セキュリティリリースには、直接的なセキュリティパッチ(修正プログラム)のみが含まれます。セキュリティパッチが原因で発生したセキュリティと無関係なバグの修正は、リリースのx-y-stableブランチで公開され、バグ修正ポリシーに基づいて新しいgemとしてのみリリースされます。7.0.Z、6.1.Z。重大なセキュリティ問題については、最新のメジャーなシリーズにおけるすべてのリリースと、前回のメジャーなシリーズの最新リリースに対してセキュリティパッチと新バージョンを提供します。セキュリティ問題の重大性の判定はコアチームによって行われます。5.2.Zがサポート対象シリーズのリストに含まれるのは、2022年6月1日までです。6.0.Zがサポート対象シリーズのリストに含まれるのは、2023年6月1日までです。7.0.Z、6.1.Z、6.0.Z、5.2.Z。あるリリースシリーズがサポート対象外になった場合、バグ修正とセキュリティ問題の対応は各自の責任となります。場合によっては修正のバックポートの提供とgitへの公開が行われる可能性もありますが、新バージョンがリリースされることはありません。アプリケーションで使われているバージョンのメンテナンスが難しい場合は、サポート対象のバージョンにアップグレードしてください。まとめ、EOLを放置しアップグレードしないと発生する具体的な不利益はなにか?以上のことからまとめると、EOLを放置したシステムのままでいると下記のような不利益を被ります。脆弱性を放置してセキュリティリスクを高めるこれが現場では一番多いのではないでしょうか?アプリケーションのセキュリティの問題も、それを動かしているクラウドサービスで防いでいるので問題が顕在化しない場合もあり気づきにくです。基本的にはセキュリティは二重三重にしておくべきでしょう。脆弱性への対応するための修正を自分でやらないといけないセキリティパッチを自前で行うこと、このようなタスクをデキる人が少ないので属人化してしまうリスクが高いです。人材の流動が激しいソフトウェア業界の場合、常に変えが効くようにできるだけベストプラクティスを意識したほうが良いですライブラリの依存関係を解決できなくなる基本的にOSSのライブラリを組み合わせてシステム構築します。一つ一つのライブラリ内でも別のライブラリを依存関係として利用していることもあります。そのライブラリのどこかに不具合があった場合に修正されるのはよっぽどメジャーなものでない限りは最新版にのみ反映されます。hashieのバージョンを3.4.6以上を使わなければならないhttps://github.com/omniauth/omniauth/blob/master/omniauth.gemspecエンジニア採用で困るこれが一番わかりやすく不利益を生むのではないでしょうか?古いシステムのメンテするのに飽きて転職するケースも多く、ソフトウェアのアップデートを訴えても拒否も認められない経験をしてきているはずです。そんなエンジニアがサポートの切れているソフトウェアを使っている会社に転職したいでしょうか?ソフトウェアのパフォーマンスをあげられないソフトウェアは日々改善されていきます、ただしその改善は最新のものだけがその恩恵を受けることができます。情シスレスキュー隊PRXではUZUMAKIの新しい働き方や日常の様子を紹介!ぜひフォローをお願いします!noteではUZUMAKIのメンバー・クライアントインタビュー、福利厚生を紹介!UZUMAKI|note株式会社UZUMAKIです。代表の工藤が投稿してますが、ほかのメンバーもたまに投稿します。受託開発を生業としてますが、リモートワークを通じて、今までにない組織形態での働き方を模索、実践しています。note.comUZUMAKIではRailsエンジニアを絶賛募集中です。採用情報これを実践するには、通常の社会で求められる上司による部下の管理が必要という前提が不要になってきます。時間管理をしない、圧倒的な性善説で動く、メンバーは自発的に動くということをUZUMAKIでは当たり前のように行っております。...job.uzumaki-inc.jp是非応募宜しくおねがいします!。