PHPのバージョン管理。サポート終了と修正の反映を見落とさない

サポート期間は、枝ごとに確認する

2026年10月26日に確認したPHP公式表では、8.2のセキュリティサポート終了は2026年12月31日です。8.3は2027年末、8.4は2028年末、8.5は2029年末と案内されています。上流の期間と、自社のOS・ホスティング契約による提供条件を同じものとして扱わないことが出発点です。

公式情報：PHP公式：サポート期間（確認 2026-10-26）

サイト名から、実際の実行系へたどる

SONAEは、入口となるURLだけでなく、Webを処理する環境、定期処理、管理用CLIを別々に記録する方法を提案します。架空の会社では広報サイトと受注処理が同じサーバーでも、別のPHPを使う構成が考えられます。「サーバー一台を確認した」という記録を、そこで動くすべての処理の確認に拡張しません。実行方式が不明なら調べる担当を置きます。

SONAEの点検・運用提案。架空例。

版の文字列に、配布元の根拠を添える

更新の判定は、担当者が配布元のセキュリティ情報と、導入パッケージの識別を照合して行う運用にします。数字が同じでも配布元が修正を取り込んでいる場合と、古いままの場合を推測で決めないためです。台帳には根拠URL、確認日、パッケージの識別、反映対象を残します。PHP以外の拡張やライブラリーまで、この一行で確認済みにしないでください。

SONAEの点検・運用提案。架空例。

期限から逆算して、互換性の確認を発注する

移行を始める日と終了期限を別に決めます。架空の受注システムなら、帳票、文字コード、外部連携、夜間処理を確認項目へ挙げます。使わない処理を削除する判断も業務担当と相談します。対応ソフトが新しいPHPへ追従しない場合は、理由、代替案、暫定措置、再判断日を残し、期限の数字だけを毎回書き換える運用にしません。

SONAEの点検・運用提案。架空例。

元へ戻すときの、リスクも決める

SONAEは、移行後の障害で古い版へ戻す必要がある場合に備え、誰が判断し、どこまで公開を制限し、いつ解消するかを計画へ含めることを提案します。バックアップがあることだけで、古い脆弱性を再び公開してよいとは判断できません。試験では架空データと別の復元先を使い、戻した後の版と設定の照合も受入に入れます。

SONAEの点検・運用提案。架空例。

台帳は変更と同時に更新する

新しいサイトや処理、委託先が加わったら、対象を追加する担当を決めます。年度初めの棚卸しだけに頼らず、契約更新・デプロイ・保守引継ぎを見直しの契機にします。台帳が埋まったことは、脆弱性がない証明ではありません。未確認の実行系と、次に確認する人が分かる状態を目標にし、公式のサポート表は実施時点で確認し直しましょう。

SONAEの点検・運用提案。架空例。

台帳を、実際の依頼に使う架空例

架空の会社では、制作会社Aが広報サイト、保守会社Bが夜間集計を管理しています。Aが更新済みと回答しても、BのCLI処理を完了にしません。公開環境の識別、実行方式、担当、サポート終了、更新根拠をそれぞれ記入します。使われていない検証環境は、削除の判断とDNSや契約の終了を別の担当へ渡します。移行の見積もりでは、コード変更の費用と、試験・切替・戻す手順・後日の再確認を分けて確認します。期限内の移行が難しいと分かった時点で業務責任者へ戻し、例外の期限を移行完了と取り違えないようにします。

SONAEの点検・運用提案。架空例。

完了前のチェック

• WebとCLIを別の対象として記録
• 上流と配布元のサポートを分ける
• 更新を戻す場合の公開条件を決める
• 変更のたびに台帳の所有者が更新

一次資料と確認範囲

• PHP公式：サポート期間

資料の対象条件と掲載内容を確認して構成した記事です。顧客への接続や攻撃再現はしていません。資料の改訂を自動追従するものではありません。実施直前に公式資料と配布元の最新案内を再確認してください。