PHP の深刻な脆弱性に関する情報が公開されたとき、「主要なシステムは PHP で書いていない」というだけでは、影響がないと判断する根拠として足りない。
企業がある技術を直接選んでいなくても、その技術が企業のシステムに入っていないとは限らない。サードパーティー製品に含まれていたり、実行環境として、業務部門からは見えない機能を支えていたりする可能性がある。オランダ国家サイバーセキュリティセンター NCSC-NL が PHP2Shell 向けに整備した資料リポジトリにも、PHP に依存する、あるいは PHP を組み込んだサードパーティー製品を調べるための情報が含まれている。[1]
企業が使うソフトウェアを見るには、少なくとも三つの視点が必要だ。自社で何を開発したか、何を購入し、何の開発を委託したか、そして、それらのソフトウェアがさらに何に依存しているかだ。
三つ目は、前の二つとは別に存在するソフトウェア群ではない。前の二つの内部にある。OS、言語の実行環境、オープンソースのコンポーネント、ベースイメージ、さらにそれらが依存する別のコンポーネントだ。
調達記録が答えるのは「何を買ったか」であり、依存関係が答えるのは「何に支えられて動くか」だ。この二つは同じリストではない。
契約はもちろん重要だ。誰が情報を提供し、誰がパッチを届け、誰がサポートを担うかを定められる。しかし、技術的な影響範囲は契約だけでは判断できない。あるコンポーネントに問題が起きたら、依存関係をたどって実際のシステムまで調べる必要がある。ベンダー名がわかったところで止めてはいけない。
一、コンポーネント名を並べるだけで終わらせない
SBOM（ソフトウェア部品表）は、ソフトウェアがどのコンポーネントで構成されているかを企業が把握する助けになる。いわばソフトウェアの「成分表」であり、企業の全業務、デプロイ先、責任者まで自動的に網羅する台帳ではない。[2]
そのため、「ベンダーから SBOM を集めた」だけでは、出発点に立ったにすぎない。資産管理や脆弱性管理と結びつけて初めて、一件の脆弱性情報から、該当するコンポーネントを含む導入済み製品をたどれるようになる。CISA などの機関が示す SBOM の活用ガイドは、まさにこうしたつなぎ方を説明している。[3]
企業の管理に落とし込むなら、もう一歩踏み込んで問える。コンポーネントが見つかった後、次は誰にたどり着けるのか。
ある製品に PHP が含まれるとリストに記載されていたとしよう。企業はさらに、その製品がどこにデプロイされているか、今も使われているか、どの入口が外部に公開されているか、どの業務を支えているか、どのチームが保守し、誰が一時的なアクセス制限を決められるかを知る必要がある。
これらの関係がつながっていなければ、セキュリティチームが受け取るのは単なる技術用語であり、業務部門にはまた一通、転送待ちのメールが届くだけだ。
リストは納品時の検収だけに使うものでもない。ソフトウェアのバージョン、実際の配備状況、保守の責任分担が変わったら、関連する記録も併せて更新すべきだ。そうしなければ、書類がいくら整っていても、本番環境の今の状態に答えられるとは限らない。
役に立つリストは、脆弱性を最終的に、対応に着手できるシステムへ結びつけるものであるべきだ。コンポーネント名の一行に結びつけるだけでは足りない。
二、「このコンポーネントがある」と「このシステムは影響を受ける」の間には、まだ証拠が必要だ
コンポーネントが見つかっても、すぐに両極端の結論を出してはいけない。システムが攻撃可能な状態だと一律に断定することも、まだ攻撃が見つかっていないからリスクはないと判断することもできない。
CISA の VEX 技術文書では、脆弱性に関する状態を「影響あり」「影響なし」「修正済み」「調査中」に分けている。「影響なし」とするには、その根拠となる理由や影響に関する説明が必要だ。この区別が示すように、コンポーネントのリストと影響の判断は同じではない。[4]
今回の PHP の脆弱性を例に取ると、2026 年 10 月 21 日に公式に公開された修正版は 8.2.35、8.3.36、8.4.27、8.5.12 だ。認証なしでのリモートコード実行につながり得る二つの深刻な脆弱性に対応している。10 月 23 日には、セッション設定と実行時の切り替えのまれな組み合わせについて、追加のリスク情報も公式に公開された。[5]
つまり、調査はバージョン番号を書き写すだけでは終わらない。公開情報が対象とする脆弱性、実際の製品、デプロイの方法、適用条件まで照合する必要がある。
バージョン番号も、それだけで意味を判断できるわけではない。一部のディストリビューターは、サポート中の旧バージョンにセキュリティ修正を移植する。これが backport（バックポート）だ。Red Hat はこの手法を明示している。したがって、上流の修正版より古く見えるベンダー提供パッケージも、未修正とは限らない。逆に、「ベンダーがバックポートしているはずだ」という推測も証拠の代わりにはならない。具体的なパッケージのバージョンと、ベンダーのセキュリティ情報を確認する必要がある。[6]
まだ判断の根拠が得られていないシステムは、「調査中」とするのが最も誠実だ。
ベンダーが PHP を使っているか不明だからといって、使っていないことにはならない。脆弱性の通知を受け取っていないからといって、影響がないと確認できたわけでもない。ベンダーから「評価中」と一言返ってきたからといって、企業が状況の確認をやめてよいわけではない。
「不明」の項目にも、担当者と次回の確認日時を付けるべきだ。報告の中で、いつの間にか「安全」に数え入れてはいけない。
三、迅速な対応には、どこまでの負担を受け入れるか決める人が要る
システムに影響があるとわかっても、それだけで企業が行動に移れるとは限らない。
外部向けのサービスに修正が必要になったとしよう。技術チームはアップグレードを準備できるが、作業には短時間の停止が必要かもしれない。業務部門は受注への影響を避けたく、ベンダーの検証もまだ終わっていない。このとき足りないのは、もう一つの技術的な助言ではなく、明確に指名された意思決定者かもしれない。
リスクの高いアクセス経路を一時的に閉じる判断は誰が承認できるのか。短時間のサービスレベルの低下を誰が受け入れられるのか。アップグレードを見送るなら、残るリスクを誰が確認し、いつ再評価するのか。
こうした問いには、平時から答えを用意しておくべきだ。緊急対応の会議になってから、決裁権を持つ人を探すのではない。
今回の PHP の問題について、CERT-EU は影響を受ける IT 資産の即時修正を推奨している。迅速な修正ができない場合には、修正を適用して検証するまで、インターネット向けのアプリケーションを公開ネットワークから隔離することを検討すべきだとしている。[7]
ここで重要なのは「すべてのシステムを一律に停止すること」ではない。「今はアップグレードできない」を「今は何もしなくてよい」と解釈しないことだ。実際に攻撃にさらされる範囲、業務への影響、公式の推奨内容を踏まえ、実行可能な暫定措置を選び、その限界も明らかにする必要がある。
暫定的な防御策は、対応の時間を確保するためのものだ。無期限に先送りする理由にしてはいけない。パッチを待つという判断にも、責任を持つ人と見直しの時期が必要だ。
四、「パッチを入れた」後にも、本当の完了確認がある
ベンダーが公開した、運用担当がインストールした、チケットをクローズした。それぞれが示すのは、別の工程だ。どれも、それだけで現在の稼働状態を確認したことにはならない。
NIST の企業向けパッチ管理ガイドは、検証を手順に明確に組み込んでいる。パッチのインストールだけでなく、その修正が有効になったことも確認する。状況によっては、ソフトウェアの再起動、再デプロイ、設定変更が必要になる場合があり、防御措置が解除されていないことも継続して確認する。[8]
そのため、修正を確かに裏づける記録は、次の問いに答えられるものであるべきだ。稼働中のどのインスタンスに修正を適用し、どれが未完了なのか。重要な業務は正常に動いているか。暫定的な防御策を残す必要はまだあるか。ロールバックすると、未修正のバージョンを再び持ち込むことにならないか。
完了を確認すべき対象は、業務を支えて稼働している環境だ。正常終了したインストールコマンドではない。
もう一つ、別に問わなければならないことがある。修正前に、すでにシステムへ侵入されていなかったか。
Microsoft は、2021 年の Exchange の問題に関する公式の対応ガイドで、セキュリティ更新をインストールしても、すでに侵入した攻撃者を排除することはできないと明記している。ここで参照しているのは対応の原則であり、今回の PHP の問題で特定のシステムが攻撃されたと断定しているわけではない。侵入が見つかった場合や疑われる場合は、脆弱性の修正とインシデント調査を並行して進める必要がある。パッチ適用の成功を、調査や攻撃者の排除に代えることはできない。[9]
修正でふさぐのは侵入口だ。調査で確かめるのは、過去に何が起きたかだ。復旧時に確認するのは、この環境を今も信頼できるかどうかだ。この三つは互いの代わりにはならない。
五、ベンダーが届けるものを、自社の対応につなげる
実務に落とし込むなら、責任分担をもう少し具体的に設計できる。
ベンダーは、製品が影響を受けるか、その判断の根拠は何か、どのバージョンに修正が含まれるか、デプロイとロールバックにどのような制約があるかを説明する必要がある。社内では、実際の利用範囲を確認し、変更を手配し、結果を検証し、まだ修正できない例外を扱う人が必要になる。具体的な分担は異なってよい。ただし、その間に誰も引き受けない空白があってはいけない。[10]
「外部委託したシステムだ」という情報は、適切な対応経路を見つけるために使うべきだ。そこで対応を止める理由にしてはいけない。
同じように、保守が終了した製品も、「当面はアップグレードしない」という注記だけで済ませるべきではない。例外ごとに、現在の防御策、明確な責任者、見直しの日付、置き換えや廃止の計画を求めるという方法がある。これは管理上の選択肢であり、古いシステムをすべて直ちに停止せよという話ではない。
この仕組みが本当にあるかを確かめるなら、まず業務フロー図の完成度を調べる必要はない。実在する脆弱性を一件選び、対応の道筋をたどってみればよい。
- 該当するコンポーネントが含まれる実際のシステムを特定できるか。
- 影響がある、またはないと判断した根拠を示せるか。
- 対応方法を決める権限を持つ人にたどり着けるか。
- 稼働状態を示す証拠で、修正の完了を説明できるか。
その途中で改めて誰かに聞き回らなければ進めない箇所があれば、そこが優先して補うべきところだ。
使っているコードのすべてを、自社で書き、レビューし、保守することはできない。それでも、重要な業務が何に依存し、問題が起きたら誰が対応し、何を根拠に対応完了を確認するのかは、少なくとも把握しておくべきだ。
セキュリティ管理で本当につなぐべきなのは、「脆弱性情報—メール—チケット」ではなく、「依存関係—影響—意思決定—稼働結果」だ。
次に重大な脆弱性が見つかったとき、企業がするべきなのは、すでに整えたこの道筋に沿って対応することだ。「このコードをいったい誰が使っているのか」と、初めて探し始めることではない。
私の考え
技術的な影響範囲は、調達や外部委託の区分だけでは判断できない。企業は、依存関係、影響、意思決定、稼働結果をつなぎ、個々のリスクについて対応の道筋を追え、完了の証拠を確認できるようにする必要がある。