最近、PHPをはじめとして、さまざまなソフトウェアの脆弱性が話題になることが増えています。

PHPというと、Webアプリケーションを開発している人だけの話に聞こえるかもしれません。

しかし実際にはそうではありません。

世界中で使われているWordPressもPHPで動いていますし、ごく普通の企業ホームページでも、問い合わせフォームやアクセス解析、ちょっとした動的処理などでPHPが使われています。

私自身もPHPが好きなので、単純なWebページであっても、少し動的な処理が必要になるとPHPを使います。

データベースを使うほどではない処理でも、PHPなら数行書くだけで済むことがあります。

つまりPHPは、いわゆる「Webシステム」だけではなく、現在のインターネットを広い範囲で支えている技術の一つです。

脆弱性が出たとき、すぐ直せるサイトと直せないサイト

今回のようにPHPに大きな脆弱性が見つかると、各社の対応状況に大きな差が出ます。

比較的新しいPHPを使っていて、継続的にメンテナンスしているサービスは、修正版が公開されれば比較的早く対応できます。

一方で、なかなか復旧できないシステムを見ると、かなり古いPHPを使い続けているケースが少なくありません。

では、なぜ古いPHPのままなのでしょうか。

理由は単純です。

PHPを新しくすると、今まで動いていたプログラムが動かなくなるからです。

PHPだけではありません。

Laravel、CakePHPなどのフレームワーク。

Composerで管理されている各種ライブラリ。

データベース接続。

帳票生成。

メール送信。

認証処理。

こうしたものが複雑につながっています。

ベースとなるPHPを変更すると、その上に乗っているものにも次々と影響が出ます。

だから、

「今動いているのだから触らない方がいい」

という判断が生まれます。

その気持ちは分かります。

しかし私は、この考え方こそが問題なのではないかと思っています。

「安定しているから古いバージョンを使う」という言葉

開発の世界では、昔からよく聞く言葉があります。

「新しいバージョンはまだ安定していない」

「実績のあるバージョンを使った方が安全だ」

「今動いているものをわざわざ変える必要はない」

一見もっともらしく聞こえます。

しかし、この考え方を何年も続けたらどうなるでしょうか。

最初は1世代古いだけだったものが、2世代、3世代と遅れていきます。

そして、ある日突然重大な脆弱性が発見されます。

そのときになって、

「最新版に上げなければならない」

となる。

しかし、いきなり何世代も飛び越えて更新しようとすると、大量のエラーが発生します。

フレームワークも動かない。

ライブラリも動かない。

自社で書いたコードも動かない。

そして、

「最新版にするとシステムが動かないから更新できない」

という話になります。

しかし、それは最新版が悪いのでしょうか。

私はそうは思いません。

何年も更新を先送りしてきた結果です。

開発者には「追従する責任」があると思う

もちろん、経営者から

「改修費用がかかるなら更新するな」

と言われたのであれば、最終的な判断は経営側の責任でしょう。

しかし、そもそも開発者から経営側へ、

「このバージョンはいずれサポートが終了します」

「次のバージョンへの対応には、この程度の改修が必要です」

「今のうちに移行した方が、将来の負担は小さくなります」

という話をきちんと上げていたのでしょうか。

私は、ここが非常に重要だと思っています。

何も知らせずに古い環境を使い続け、重大な問題が起きたときに初めて、

「実は古いバージョンなので更新できません」

では遅いのです。

ソフトウェアを開発・保守する側には、基盤となるソフトウェアの変化を追いかける責任があると思います。

フレームワークを使えば解決するわけではない

PHPの世界では、長い間、

「素のPHPを書くのは良くない」

という議論もありました。

コードが属人化する。

可読性が悪くなる。

セキュリティ対策を自分で実装しなければならない。

SQLインジェクション対策。

XSS対策。

CSRF対策。

認証。

セッション管理。

こうした部分をフレームワークに任せることで、一定の品質を確保できる。

これはその通りだと思います。

PDOでプリペアドステートメントを使う。

出力時のエスケープを徹底する。

そうしたものを毎回自分で考えるより、フレームワーク側で標準化することには大きな意味があります。

しかし、フレームワークを使ったからメンテナンスから解放されるわけではありません。

LaravelもCakePHPも、その下ではPHPが動いています。

PHPが変わればフレームワークも変わります。

フレームワークが変われば、その上で利用しているライブラリも変わります。

つまり部品が増えれば増えるほど、依存関係も増えていきます。

便利になる一方で、更新すべき対象も増えるのです。

ソフトウェアには「レイヤー」がある

今回の話で特に重要なのが、レイヤーという考え方だと思っています。

一番下にはハードウェアがあります。

その上にOSがあります。

その上にWebサーバーやデータベースがあります。

その上にPHPのような実行環境があります。

その上にフレームワークがあります。

さらにその上にライブラリがあります。

そして一番上に、私たち開発者が作ったアプリケーションがあります。

私たちが作っているのは、かなり上位のレイヤーです。

下のレイヤーが変われば、その上に乗っているものも合わせて変える必要があります。

これは当たり前の話です。

ところが現実には、

「今のアプリケーションが動いているから下を変えないでほしい」

という逆転した話が起きます。

私は、本来順番が逆だと思っています。

OSが変わる。

PHPが変わる。

フレームワークが変わる。

それなら、その上で動く自分たちのプログラムを変える。

これが基本ではないでしょうか。

PHP4からPHP5へ変わった頃も同じだった

この問題は最近始まったものではありません。

私がPHPを始めた頃まで遡っても、似たような話はありました。

当時、PHP4が広く使われていて、PHP5が登場したばかりでした。

PHP5をLinuxに入れようとすると、インストールやビルドでつまずくことがありました。

PHP4なら簡単に入る。

PHP5だとエラーになる。

そこで、

「4なら動くから4でいい」

となる。

しかし私は、その考え方に違和感がありました。

PHP5がこれからのバージョンなのであれば、どうすればPHP5を動かせるのかを調べるべきではないか。

実際、当時の書籍やインターネット上の情報はPHP4向けのものが圧倒的に多かったと記憶しています。

それでも私は、できるだけPHP5の情報を探しました。

なぜなら、いずれPHP4は使われなくなるからです。

これは今でも変わらないと思っています。

「新しいから情報がない」は当然

新しい技術を使うと困ることがあります。

情報がありません。

検索しても出てこない。

生成AIに聞いても、古いバージョンの情報を返してくることがあります。

しかし、それは当然です。

新しいのですから。

私も何度も経験しています。

PHPのバージョンが上がり、それまで使えていたコードが非推奨になる。

最初はNoticeだったものがWarningになる。

そして次のバージョンではErrorになり、完全に動かなくなる。

そのたびに修正してきました。

面倒です。

しかし、それを繰り返していると、次のバージョンへの移行はそれほど大きな作業ではなくなります。

問題なのは、5年、10年と放置してから一気に移行しようとすることです。

phpMyAdminでも何度も同じことを経験した

私がよく使ってきた外部ソフトウェアの一つがphpMyAdminです。

PHPのバージョンが大きく変わると、phpMyAdmin側が追いつかず、エラーが出たり、まともに動かなかったりすることもありました。

しかし、それを理由にPHPそのものを古いままにしておこうとは思いませんでした。

phpMyAdminが動かなければ、しばらく別の方法を使えばいい。

少し待てば、phpMyAdmin側も新しいPHPに対応してきます。

私はそう考えてきました。

ベースとなるものが変わったら、その上のソフトウェアが追従する。

自然な順番です。

PHPExcelからPhpSpreadsheetへの移行もそうだった

ExcelファイルをPHPから扱うライブラリでも、大きな変化がありました。

かつて広く使われていたPHPExcelから、PhpSpreadsheetへ移行する時期です。

古いライブラリをそのまま使い続ける方が楽です。

ネット上にもPHPExcelの情報が大量にあります。

一方で、移行直後のPhpSpreadsheetは情報が少ない。

サンプルも少ない。

調べるのも大変です。

それでも、今後はこちらが主流になると分かっているのであれば、そちらへ移行する。

私はその方が長期的には楽だと思っています。

「新しいものは不安定」という考え方を疑った方がいい

もちろん、新しいソフトウェアに不具合がないとは言いません。

リリース直後に問題が見つかることもあります。

しかし、そこで考えたいことがあります。

PHPのような世界規模で利用されているソフトウェアは、非常に多くの開発者や利用者によって検証されています。

問題が見つかれば修正されます。

次のリリースも出ます。

それに対して、自社だけで開発したプログラムはどうでしょうか。

本当にPHP本体よりも厳密なテストをしているのでしょうか。

本当に世界中の開発者からレビューを受けているのでしょうか。

「新しいPHPは不安定だから怖い」

と言いながら、その上で自分たちが書いたコードについては絶対に安全だと考える。

私は、少し不思議に感じます。

Windowsでも同じことが繰り返されてきた

この話はPHPだけではありません。

分かりやすいのがWindowsです。

新しいWindowsが登場すると、企業では必ずと言っていいほど、

「まだ対応していない」

というソフトウェアが出てきます。

だから古いWindowsを使い続ける。

そしてサポート期限が近づくと突然、

「新しいWindowsに移行しなければならない」

と騒ぎ始めます。

Windows 7の頃には、特にひどい例をたくさん見ました。

Internet Explorerでしか動かない。

特定のActiveXが必要。

特定のWindowsでなければ業務システムが起動しない。

行政関連のシステムでも、こうしたものが長く残っていました。

しかし私は、OSメーカーだけの責任ではないと思っています。

新しいOSが出たのであれば、その上で動くソフトウェアを作っている会社が対応しなければなりません。

それがソフトウェア会社の仕事だからです。

サポート終了直前まで使うことが「安定運用」なのか

私は昔から疑問に思っています。

なぜ、多くの企業はサポート終了ギリギリまで古いソフトウェアを使うのでしょうか。

Windowsのサポート終了が近づく。

半年前になって騒ぐ。

数か月前になって移行を始める。

そして、

「業務ソフトが対応していない」

と言う。

本来であれば、新しいOSが出た段階から対応を始めればいいのです。

すぐ全面移行する必要まではないでしょう。

しかし、

「いつでも移行できる状態にしておく」

ことは必要だと思います。

PHPでもまったく同じです。

最新版が出た瞬間に本番環境を切り替える必要はありません。

しかし、検証環境では動かしてみる。

自分たちのコードが動くか確認する。

非推奨になった機能を修正する。

ライブラリの対応状況を見る。

そうしておけば、本当に移行が必要になったとき、慌てなくて済みます。

セキュリティは「鍵を増やせばいい」という話ではない

セキュリティについても、私は同じことを感じています。

世の中では、

「セキュリティを強化する」

というと、とにかく鍵を増やそうとします。

認証を増やす。

ウイルス対策ソフトを入れる。

アクセス制限を増やす。

監視ツールを増やす。

もちろん必要なものもあります。

しかし、根本となるレイヤーに穴が開いていれば意味がありません。

家の窓が割れているのに、玄関の鍵を三つに増やしているようなものです。

どこに脆弱性があるのか。

どのレイヤーの問題なのか。

そこを理解することが重要です。

昔の「メールを開くだけでウイルス感染」も同じ

昔、

「メールを開いただけでウイルスに感染する」

という話がありました。

実際、そうした脆弱性は存在しました。

しかし、本質的にはメールという仕組みそのものが危険なのではありません。

メールソフト側の脆弱性です。

メールを受信する。

開く。

添付ファイルを実行する。

リンクをクリックする。

ブラウザを開く。

それぞれ違う処理です。

現在では、メールソフト、OS、ブラウザ、セキュリティ機能など、複数のレイヤーで防御されています。

にもかかわらず、

「メールは危ない」

という一言で全部まとめてしまう。

PHPについても似ています。

「PHPは危ない」

「WordPressは危ない」

ではありません。

どのバージョンなのか。

どの脆弱性なのか。

どの条件で攻撃が成立するのか。

どのレイヤーの問題なのか。

本来、技術者であればそこまで見なければならないと思います。

世間が全部理解する必要はない。しかし開発者は理解しなければならない

一般の利用者が、OS、Webサーバー、PHP、フレームワーク、ライブラリ、アプリケーションの違いを理解する必要はありません。

利用者からすれば、

「セキュリティ上の問題があった」

で十分です。

しかし、プログラムを作る側まで同じ理解では困ります。

PHPはどの位置にいるのか。

OSはどの位置にいるのか。

フレームワークは何をしているのか。

どこに依存しているのか。

下のレイヤーが変わったとき、どこまで影響するのか。

開発者であれば、少なくともこの構造は理解しておく必要があります。

私はプログラミング能力が特別高いわけではない

私は、自分自身を高度なプログラマーだとは思っていません。

しかし、長くPHPを触ってきました。

PHP4からPHP5へ変わった時代。

PHP5からPHP7へ大きく変わった時代。

それまで普通に動いていたコードが突然動かなくなる経験。

ライブラリが対応しなくなる経験。

警告だったものがエラーに変わる経験。

そうしたものを何度も経験してきました。

だからこそ思います。

新しいバージョンが怖いのではありません。

長期間更新しないことの方が、後からはるかに怖いのです。

バージョンアップ対応は「特別な仕事」ではない

ソフトウェアを作ったら終わり。

私は、そうではないと思っています。

OSが更新される。

PHPが更新される。

ブラウザが更新される。

データベースが更新される。

ライブラリが更新される。

APIが更新される。

それに合わせて自分たちのプログラムも更新する。

これは追加作業ではなく、ソフトウェアを維持するという仕事そのものです。

もちろん費用はかかります。

手間もかかります。

テストも必要です。

しかし、それを含めてシステムなのだと思います。

最新版へ即座に本番移行する、という意味ではない

誤解のないように書いておくと、

「最新版が公開されたその日に、何も考えず本番環境へ入れればいい」

という話ではありません。

検証は必要です。

互換性確認も必要です。

重要なシステムであれば、段階的な移行も必要でしょう。

私が言いたいのは、

「新しいものを避けることを運用方針にしてはいけない」

ということです。

新しいバージョンが出たら確認する。

動かしてみる。

問題点を洗い出す。

自分たちのコードを修正する。

いつでも移行できる状態へ近づけておく。

その継続が重要なのです。

何年も放置されたシステムなら、作り直した方が早いこともある

そしてもう一つ。

あまりにも古いシステムについては、無理に延命するより作り直した方が早い場合もあります。

10年以上前のPHP。

サポートが終わったフレームワーク。

更新されていないライブラリ。

誰が書いたのか分からないコード。

仕様書もない。

担当者もいない。

こうしたシステムを、無理やり最新版へ対応させようとすると、膨大な工数がかかることがあります。

その場合は、

「このプログラムをどう直すか」

ではなく、

「今必要な機能は何なのか」

から考え直した方がいい。

当時は数万行必要だったプログラムでも、現在ならもっと簡単に作れることがあります。

技術も変わっています。

サービスも変わっています。

生成AIもあります。

古いプログラムを必死に延命することだけが正解ではありません。

開発者の宿命は、変化に追従し続けること

今回のPHPの問題を見て、改めて思いました。

ソフトウェアを作る人間にとって、

「今動いているから触らない」

は、安全策ではありません。

むしろ将来の負債を積み上げているだけかもしれません。

OSが変わったら追従する。

PHPが変わったら追従する。

フレームワークが変わったら追従する。

ライブラリが変わったら追従する。

ブラウザが変わったら追従する。

下のレイヤーが変われば、その上のレイヤーを作っている私たちが合わせる。

それがソフトウェア開発なのだと思います。

新しいものに変えれば、当然苦労します。

エラーも出ます。

今まで使えたコードが使えなくなることもあります。

情報が少なくて困ることもあります。

しかし、その苦労を毎回少しずつ引き受けるからこそ、大きな問題が起きたときにも動けます。

重大な脆弱性が公開されてから慌てて数世代分を更新するのではなく、普段から少しずつ前へ進んでおく。

私はその方が、結果として圧倒的に安全だと思っています。

「古いバージョンの方が安定している」

その言葉が、本当に技術的な判断なのか。

それとも単に、更新作業を先送りするための言葉になっていないか。

ソフトウェアを作る側の人間ほど、一度考えてみてもいいのではないでしょうか。