正式にPHPフリーになりました。10月が教えてくれたこと(現時点まで)

2026年10月19日から24日の週(月曜から土曜)には、業界全体で深刻なセキュリティニュースが相次ぎました。見逃した方は、その週の振り返り記事で詳細をお読みいただけます。要点を言えば、いくつかのケースで、攻撃者は修正よりも先に動いたのです。

このような一週間があっても、私たちが設計を白紙に戻すことはありません。しかし、すでに引いてある線はいっそう鮮明になります。原則を掲げることと、その原則が欠けている場所で何が起きるかを一件ずつ目の当たりにすることは、別のことです。そこで技術的な手順を列挙する代わりに、私たちが拠り所とする原則を説明したいと思います。お客様にとっては、個々のアップデートよりも、その取り組み方のほうが重要だからです。そして、その原則の一つがちょうど節目に到達しました。私たちは今、正式にPHPフリーです。

なぜ事後のパッチ適用は負け戦なのか?

長年、標準的なアドバイスは単純でした。すばやくパッチを当てれば大丈夫、というものです。しかし趨勢はすでにそのアドバイスに逆行していました。GoogleのMandiantチームは、脆弱性が知られてから悪用されるまでの平均期間を測定しています。2018年から2019年は63日、2021年から2022年は32日、2023年には5日(外れ値を除いた平均)でした。

5日というのは2023年、つまりAIツールが日常的なソフトウェア開発の一部になる前の数字です。今月、この競争の新たな測定値が得られました。2026年10月21日のPHP2Shell公開をめぐって、3つの異なる観測点から取られたものです。

Amazonの脅威インテリジェンスチームは、公開の4日前にあたる10月17日にPHP2Shellの悪用の試みを観測したと述べ、情報公開制限が解除されてパッチがリリースされると、数時間以内にさらなる概念実証エクスプロイトが現れたとしています。F5 Labsは、2件のCVEが公開される5時間以上前に最初のPHP2Shellスキャンを観測し、公開から数時間のうちにセンサーが数千件の悪用の試みを記録しました。CloudflareのCEOであるMatthew Princeは、10月22日の投稿で、Cloudflareが発表前に数千件、発表後45分で数万件、2時間以内に数十万件、そして投稿時点までに数百万件の試行を観測したと述べています。これらは試行であって、侵入が確認されたものではありません。しかし、ドアがどれほど速く試されていたかを示しています。その窓は今や分と時間の単位で測られ、一部にとってはパッチが存在する前に閉じてしまったのです。

修正が存在する前の悪用も、珍しいことではありません。2023年には、Mandiantが追跡した悪用済み脆弱性の70%、138件中97件がゼロデイとして悪用されました。つまり、修正がまったく存在しない段階での悪用です。

悪用がパッチの提供前に始まりうるうえ、パッチ公開から数分で大量に押し寄せるのであれば、どれほど規律正しくパッチを当てても、それだけでは計画の全体にはなりえません。それだけに頼る防御側は、始まる前に勝敗が決まっていることの多い競争に参加していることになります。だから私たちは、この競争に時には負けることを前提とし、負けた場合を想定して設計しています。この前提は3つの問いに変わります。欠陥が開いている間、私たちのシステムのどれだけが攻撃されうるか。何かが攻撃された場合、どれだけが失われうるか。そして修正が存在したら、どれだけ速く復旧して穴を塞げるか。私たちの掲げる原則はすべて、このいずれかの問いに答えるものであり、以下の内容もこの3つの問いを軸に構成されています。

なぜ回避策で守るのではなく、ソフトウェアそのものを取り除くのか?

最初の問い、どれだけ攻撃されうるか、から始めましょう。どんな組織にも、劣化したソフトウェアが溜まっていきます。メンテナーが去ってしまったツール、他の何かが依存しているせいで古いバージョンに固定された部品、誰も触りたがらないコード。よくある対応は、そうしたソフトウェアを回避策とファイアウォールのルールで包み、無事を祈ることです。

私たちは違う見方をします。最新に保てないソフトウェアは、回避策で囲うのではなく、取り除きます。一時的な修正で延命させることはしません。メンテナンスされていないコードへの一時的な修正は、いずれ破られる約束だからです。コンポーネントは、運用する限り更新し続けられるか、そうでなければ一切動かさないか、のどちらかです。

なぜ回避策は失敗するのでしょうか。回避策が防げるのは、すでに知られている欠陥だけだからです。メンテナンスされていないソフトウェアは、メンテナーが去った日を境に弱点を持たなくなるわけではありません。研究者と攻撃者は年々新しい弱点を見つけ続け、しかも修正を書く人はもう誰もいません。発見のたびに、もう一つのルール、もう一つのフィルター、前の層の上に重ねられるもう一つの層が必要になり、積み重なるほど構造は脆くなります。遅かれ早かれ、どの外側の層でも遮断できない欠陥が現れるか、2つの層が互いに干渉し、防御は静かに崩れます。回避策は時間を稼ぐものですが、見捨てられたコードの上では、その時間を使う意味のある対象がありません。根本の問題は決して修正されないからです。

先ほどの、今や分と時間で進む競争を思い出してください。メンテナンスされているソフトウェア相手なら、競争は過酷に短いとはいえ、少なくとも走ることはできます。見捨てられたソフトウェア相手には、そもそも競争が存在しません。競争を終わらせるはずの修正が、永遠に届かないからです。文章にすると当たり前に聞こえます。実際にはこちらのほうが困難な道です。何かを取り除くことは、通常、それに依存していたものを作り直すことを意味するからです。私たちはその費用を払う価値があると考えています。もはや存在しないシステムの弱点を、攻撃者が悪用することはできません。

小さな攻撃対象領域とは実際どのようなものか?

取り除くことは、攻撃されうる範囲を縮小するもっとも率直な方法です。その背後にあるより広い習慣には技術的な名前があります。攻撃対象領域(アタックサーフェス)を小さく保つ、というものです。攻撃対象領域とは単純な概念で、攻撃者が錠に鍵を差し込んでみることのできるすべての場所の総和です。公開されたサービス、サードパーティのライブラリ、プラグインの一つひとつが、守るべき錠を一つ増やします。私たちの考える良いセキュリティはここから始まります。最強のコードとは実行しないコードであり、最も安全なデータとは最初から保存しなかったデータです。

サードパーティのライブラリやプラグインが実際には何なのか、考えてみてください。開発者がそれを取り込むとき、見知らぬ誰か、多くは無報酬のボランティアに、そのコードが動く限り安全を保ってくれると信頼を預けているのです。ライブラリには独自の更新、独自のセキュリティ修正、注意を払い続ける独自のメンテナーが必要です。そのメンテナーが興味を失ったり、転職したり、単に返事をしなくなったりしても、コードは動き続けます。しかし、もう誰も見張っていません。その後に見つかった欠陥は永久に開いたままです。これは前の節で述べた放置の問題が、横のドアから入ってくるのと同じことです。これを、典型的なアプリケーションが依存する数多くのコンポーネントの分だけ掛け合わせれば、全体像が見えてきます。依存関係の一つひとつは、会ったこともない誰かによる小さな約束であり、その一部は静かに期限切れになります。依存を減らすことは、自分の安全を預ける見知らぬ相手を減らすことなのです。

お客様がサインインし、支払いを行い、当社のアプリが通信するシステムはGoで書かれています。PHPは撤廃済みで、PHPアプリケーションが引きずりがちなライブラリ、プラグイン、依存関係の長い尾も一緒に消えました。

最も重要なシステムにGoを選んだのは、依存関係の問題に言語レベルで答えてくれるからです。Goはメモリ安全な言語です。言語がプログラマーに代わってメモリを管理するため、バッファオーバーフローのような一群のバグを根本から排除します。CISA(米国サイバーセキュリティ・インフラセキュリティ庁)は、文書「The Case for Memory Safe Roadmaps」の中でGoをメモリ安全な言語の一つに挙げています。この一群は思った以上に大きく、Chromiumプロジェクトによれば、深刻なセキュリティバグの約70%がメモリ安全性の問題です。Goの標準ライブラリは暗号を含め、ウェブサービスに必要なものの多くをカバーしているため、Goのサービスはサードパーティのパッケージを必要とする場面が少なく、見知らぬ相手からの約束に頼る数も減ります。暗号は真剣に扱われており、Go自身の暗号モジュールは米国政府のFIPS 140-3標準で検証済み(CMVP証明書 #5247)です。そして、より広いエコシステムで欠陥が表面化した場合も、Goのセキュリティチームが脆弱性データベースを整備しており、そのgovulncheckツールは、プログラムが実際に呼び出すコードの中にある脆弱性だけを報告するため、警告はノイズが少なく、行動につなげやすいものになります。

これが重要なのは、PHPの導入がいかに広範で、いかに古いかという事情があるからです。W3Techsの報告によれば、サーバーサイド言語が判明しているウェブサイト全体の69.2%がPHPを使用しており、PHPサイトの26.6%がいまだにPHP 7、7.7%がPHP 5のままです(2026年10月27日時点の測定)。PHPプロジェクト自体は、各リリースブランチに対して2年間のバグ修正とセキュリティ修正、その後さらに2年間は重大なセキュリティ修正のみを提供しています。PHP 7とPHP 5はそのすべてを過ぎています。ウェブの大きな割合が、作り手自身がもはや守っていないコードの上で動いているのです。これは、最初の節で述べた負け戦に、自ら進んで参加していることにほかなりません。

当社のウェブサイトは事前に構築された静的ページで、訪問時にサーバー側のコードがページを生成することはありません。ただのファイルにすぎないページには、攻撃できる場所がほとんどありません。どれだけ攻撃されうるかという問いへの私たちの答えはこうです。可能な限り少なく。

私たちはお客様のどんなデータを保持しているのか?

小さな攻撃対象領域は、攻撃者の侵入経路を限定します。2番目の問いは、それでもいつか誰かが侵入してしまった場合、何が見つかるかを尋ねるものです。私たちの答えは、見つかるものをできるだけつまらなくすることです。データは少なく、保持期間は短く。

私たちはアカウントの運用に必要なものしか求めません。プライバシーポリシー(英語)に明記されているのは、ユーザー名、メールアドレス、暗号化されたパスワード、登録時に使用されたIPアドレスです。決済は第三者の決済代行業者を通じて行われるため、カード情報は、その保護を生業とする専門業者のもとにあり、当社にはありません。

時間の経過に伴う扱いも引き締めています。長期間使われていない古いアカウントは今後、自動的に削除されるようになります。存在しないデータは、漏えいすることも、盗まれることも、要求されることもありません。何年も前に放置したアカウントが、あなたの名前のついた負債として残り続けるべきではありません。万一、私たちの側でこの競争に負けることがあっても、卓上の賞品は可能な限り小さくしておくべきなのです。

同じ論理は私たちの外側にも当てはまります。他の企業も競争に負けることがあるからです。人々が被る漏えいの多くは、ずっと前に登録したショップ、フォーラム、サービスで起きています。だからこそ私たちはデータ漏えい警告を提供しています。当社のData Breach Scannerは、既知のデータ漏えいにお客様のメールアドレスが含まれていないかを確認し、見つかればメールでお知らせします。漏えいが悪用される前にパスワードを変更できるようにするためです。

それでも何かが壊れたらどうなるのか?

3番目の問いには2つの側面があります。復旧することと、穴を塞ぐことです。まず復旧から。良いセキュリティ計画は、悪い日が来ることを前提とします。ハードウェアは故障し、サプライヤーは変わり、時にはあるインフラから単純に立ち去ることが正解になることもあります。

当社のシステムは、必要に応じて作り直したり、別の場所に移したりできるように構築されています。お客様にとってこれは、障害や、当社の基準を満たさなくなった拠点が、長時間の停止に直結する必要はないということを意味します。影響を受けたシステムは再構築や移転ができるからです。ある環境がもはや十分でないと判断すれば、私たちはそこと交渉するのではなく、立ち去ることができます。

レジリエンス(回復力)は劇的な性質ではありません。その多くは、物事が動き続けるという形で現れます。この枠組みの中では、1ラウンドの敗北をシーズン全体の敗北にしないためのものです。

修正はどれくらい速く私たちのシステムに届くのか?

3番目の問いのもう半分は速さです。ここまで述べたことのどれも、パッチの必要性をなくすわけではありません。変わるのは、パッチが背負わなければならない重さです。攻撃対象領域が小さく、ソフトウェアが最新であれば、修正の適用は一大プロジェクトではなく日常業務になります。

私たちのルールは単純です。修正が存在した時点で直ちに更新を配信する。10月の測定値がその理由を物語っています。悪用の試みが修正の公開から数分、数時間で届き、時には修正が存在する前に届くのなら、適用を待っている修正は誰も守りません。私たちはリリースされたパッチをスタートの号砲として扱います。修正が存在してから適用されるまでの区間は、この競争の中で防御側が完全にコントロールできる唯一の部分です。だからこそ、そこだけは絶対に譲りません。

そして、当社のスタックが小さいために、そもそもパッチを当てる対象が少ない。ここで3つの問いが交わります。攻撃されうるものが少ないほど、穴は速く塞がるのです。

問いと、それに答える原則を並べると、次のようになります。

これらすべてはお客様にとって何を意味するのか?

それは、3つの問いに、実感できる答えがあるということです。お客様とアカウントの間に立つコードが少ないので、何かがうまくいかなくなる場所も少ない。お客様のデータが存在する量が少ないので、最悪の場合でも露出するものはわずかです。そして当社のシステムは再構築できるので、当社にとっての悪い日が、お客様にとっての長時間の停止になる必要はありません。

この取り組みの限界についても正直にお話しします。冒頭で述べた競争に、確実に勝ち続けることは、私たちにも誰にもできません。欠陥は、誰も存在に気づく前に悪用されることがあり、どんなアーキテクチャもそれを変えられないからです。リスクゼロを約束できるプロバイダーは存在せず、それを約束する者は、セキュリティではなく安心感を売っているのです。私たちが約束できるのは、損失の形です。侵入経路は少なく、奪えるものはわずかで、戻る道は速い。すべてのラウンドで勝つことは保証できません。しかし、1つ負けてもお客様の代償が可能な限り小さくなるように構築してきました。そして、一貫して守られるこの約束は、守れない大胆な約束よりも価値があると考えています。

セキュリティは共同作業でもあります。私たちが築ける最強の体制も、お客様側の良い習慣があればさらに生きてきます。実践的なステップを知りたい方は、オンラインセキュリティを高める方法(英語)のガイドから始めてください。そしてVPNを選ぶときは、当社であれ他社であれ、何を売っているかだけでなく、どう考えているかをプロバイダーに尋ねてください。その答えは、静かな週も、騒がしい週も、どのように過ぎていくかを多く物語ってくれます。