脆弱性対応は地味な保守？若手エンジニアが経験に変える方法

2026年10月21日、PHPの重大な脆弱性に対する修正版（8.5.12、8.4.27、8.3.36、8.2.35）が公開されました。PHP2Shellと呼ばれているものです。多くの現場が、その日から対象サーバーの洗い出しとバージョンの確認に追われました。

1〜3年目のエンジニアが任されたのは、たいてい確認と更新と動作確認でしょう。手順書どおりに進めて、終わったら報告する流れです。言われたことはやったのに、自分に何が残ったのかよく分からないと感じている人もいると思います。

今回のPHPの件で、現場では何が起きた？

修正版が出る前に脆弱性の詳細が外部に出てしまい、レンタルサーバーの各社が利用者のサイトを一時的に止める対応を取りました。普段より急いだ現場が多かったのは、そのためです。

もう1つ、サポートが終わっている7系と8.1には修正版が出ていません。この2つを使っているシステムを抱えている現場は、別のバージョンへの移行を考えることになります。すぐには移行できないので、通信の制限などで守りながら移行の計画を立てる話になります。

攻撃の手口そのものの説明は省きます。担当者としてやることは、手口を知っていてもいなくても大きくは変わらないからです。

脆弱性対応で、エンジニアは何を判断しているのか

作業の前後でどんな判断をしたかが、経験として残ります。実際、1つの脆弱性対応の中では、こんなことが決められています。

若手に回ってくるのは表の左側にある場面での作業ですが、右側の判断は先輩や上長がしていることが多いはずです。だったら、その判断の理由を聞きに行くといいと思います。「なぜこのサーバーから先に直すんですか」と1つ聞くだけで、自分が記録できる内容が変わります。

米田自身、急ぎの脆弱性対応の経験はあまりなく、サポート終了が分かってから計画的に移行する対応がほとんどでした。緊急かどうかの違いはあっても、影響調査と段取りという中身は共通しています。緊急対応の経験がないことを気にしすぎる必要はありません。

ただのバージョンアップで終わらせない

更新して終わりにせず、判断の理由と手順を記録し、次に同じことが起きたときに別の人でも同じ対応ができる形に残します。ここまでやると、説明できる経験になります。

なぜなら、脆弱性対応は必ずまた来るからです。次に同じ言語やミドルウェアで修正版が出たとき、対象の一覧と確認手順と連絡先がまとまっていれば、チームの動き出しが早くなります。その一覧と手順書を作ったのが自分だと言えるなら、評価面談でも面接でも話せます。

もう1つ、対応の途中で気づいた別の問題を一緒に直せた人は、評価されやすいと思います。バージョンを確認していたら誰も管理していないサーバーが見つかったとか、設定が1台だけ違っていたといった気づきは、作業を自分の目で見ている人にしか拾えません。

代表・米田の視点 今回のPHPの件は、AIで脆弱性を突かれたという話です。だとしたら、こちらもAIで対策を入れるくらいのスピード感じゃないと間に合わないと思うんです。私が「この人は伸びるな」と感じるのは、そこを理解できる人ですね。あとは、脆弱性対応をしていて別の気づきがあって、それも合わせて対策した、という人。それは面談でも面接でもアピールポイントになります。

ENFIでは、キャリアを考えるときに今持っているもの（Have）から書き出してもらっています。スキルや年収の話はそのあとです。保守や脆弱性対応の経験も、書き出せばキャリアを考える材料になります。まだ書き出していないだけ、ということがよくあります。稼働中のシステムを止めずに変更し、問題が起きたら元の状態に戻す段取りを語れる人は、そう多くありません。

今日からできる次の一歩

1. 今週やった脆弱性対応を、判断の理由つきで書き出す。何を確認したか、なぜその順番にしたか、誰にいつ報告したか。30分で書ける範囲で構いません。
2. 書き出したものを、次に同じことが起きたときの手順書の形に直して、チームが見られる場所に置く。レビューをもらえば、抜けていた判断も見えてきます。

書き終えたら、自分の職務経歴に1行足してみてください。「対象サーバーの洗い出しから更新、動作確認までを担当し、次回用の手順書を作成した」と書けるなら、面談や面接で話せる経験として使えます。