Wiz CTOが警告：インターネットの老朽化コードに「脆弱性の末日」が迫る

編集者注：オープンソース言語は現代インターネットの基盤を支えているが、その老朽化とメンテナンスの欠如が、「パッチの日」を繰り返しシステム的なセキュリティインシデントへと変えつつある。PHPの脆弱性騒動は表面上収まったように見えるが、真の問題はようやく浮かび上がってきたばかりだ。

先週、オープンソース言語PHPに2つの重大な脆弱性が発覚し、サイバーセキュリティ界に連鎖反応を引き起こした。PHPは世界のウェブサイトの約70%を支えており、個人ブログ、コンテンツ管理システム、企業ポータルに至るまで、この「古くて」しかしどこにでも存在する技術スタックで動いている可能性がある。脆弱性が公開された後、多くの組織が緊急でシステムの点検とパッチの適用を行い、一部のチームはリスクが管理可能だと確認できるまでサイトを一時的にオフラインにすることを選んだ。

TechCrunchの報道によると、この騒動はWizの最高技術責任者から「Vulnpocalypse」——「脆弱性の末日」と表現された。やや誇張した表現ではあるが、指し示す現実は誇張ではない。インターネットの多くのインフラが依存する老朽化したコードが、脆弱性の集中露出サイクルに入りつつあるのだ。

PHPの一度の衝撃が、なぜインターネット全体を揺るがすのか

PHPは新しい技術ではない。1990年代に誕生し、長らくWeb開発の主要言語の一つであり続けた。WordPress、Drupalなどのコンテンツ管理システムや大量の従来型エンタープライズアプリケーションは、PHPエコシステムの上に構築されている。普及範囲が広く、歴史的な負債が重いがゆえに、PHPのコアや一般的なコンポーネントに高危険度の脆弱性が見つかった場合、それは「特定の製品」の問題にとどまらず、ウェブサイトのサプライチェーン全体の問題となる。

2つの重大脆弱性が組織を慌てさせた理由は、修正が単に「パッチを当てる」ほど簡単ではないことにある。企業はまず資産台帳を確認する必要がある。どのシステムがPHPを使っているか？バージョンは何か？パブリックネットワークに公開されているか？サードパーティのコンポーネントが同じ依存関係を導入していないか？大規模な組織では、これらの問いに即答できることはほとんどない。そのため、脆弱性公開後の最初の数日間、セキュリティチームは不完全な資産マップ上での「手探り修復」を余儀なくされた。

「PHPの今回の衝撃は情報の流れから薄れていったかもしれないが、後始末は遠く終わっていない。」——この一連の脆弱性インシデントが残す核心的な教訓は、修復とは一度のクリックではなく、継続的なシステムエンジニアリングであるということだ。

「脆弱性の末日」の背後にある老朽化コード危機

Wiz CTOの警告はPHPだけを対象としたものではない。過去数年間、Log4jからOpenSSL、npmエコシステムからPythonパッケージリポジトリに至るまで、オープンソースサプライチェーンの脆弱性は繰り返し証明してきた。インターネットの最も重要なコードは、少数のメンテナーが余暇の時間を使ってメンテナンスし、安定した資金やエンジニアリングリソースが不足していることが多い。これらのプロジェクトが数百万のシステムに依存されている場合、どんな欠陥も全球的なイベントへと増幅される可能性がある。

「Vulnpocalypse」とは、むしろトレンドの判断として理解すべきだ。攻撃者の自動化スキャン能力が向上し、脆弱性の公開ペースが加速するにつれ、老朽化コードの脆弱性はより頻繁に露出するようになる。企業が直面するのは、散発的なセキュリティインシデントではなく、絶え間なく押し寄せる脆弱性の洪水だ。人手による緊急対応やサイトの一時停止といったモデルは、長期的に機能しにくい。

さらに厄介なのは、多くの老朽化コードが「目立たない」ことだ。それらはレガシーシステム、内部ツール、コンテナイメージ、あるいはサードパーティSDKの中に潜んでおり、担当者も、アップグレードの計画もない。セキュリティチームが脆弱性を発見した時には、ビジネスチームがそのシステムの存在をとっくに忘れていることもある。修復の窓は引き延ばされ、攻撃対象領域は常に開いたままになる。

緊急シャットダウンからシステム的なガバナンスへ

今回のPHP脆弱性インシデントでは、一部の組織が脆弱性修復まで自サイトをオフラインにすることを選んだ。この「止血」手段は理解できるが、準備不足も露呈した。企業が完全なソフトウェア部品表（SBOM）、明確な資産の帰属管理、自動化されたパッチ適用プロセスを持っていれば、リスクに直面したときに「サイトを閉じて安全を保つ」しかないという状況にはならないはずだ。

業界ではいくつかのコンセンサスが形成されつつある。第一に、資産の可視性がセキュリティの基盤となる。企業は脆弱性が爆発してから台帳を探すのではなく、オープンソースコンポーネントとそのバージョンを継続的に棚卸しする必要がある。第二に、パッチ管理の自動化が求められる。高頻度の脆弱性に直面したとき、CVEの手動照合、互換性テスト、段階的なリリースでは速度がまったく追いつかない。第三に、オープンソースのメンテナンスにはより多くの投資が必要だ。オープンソースコードを利用する商業企業は、「無料の基盤」を享受するだけでなく、重要プロジェクトへ還元すべきだ。

Wiz CTOの警告は、企業への促しとしても理解できる。次の「脆弱性の末日」が来てから老朽化コードのことを思い出すのでは遅すぎる。PHPは今回も単なる一時の衝撃で終わったかもしれないが、インターネットのコードは老いていく一方で、攻撃者のツールは進化し続けている。クリーンアップ、アップグレード、ガバナンス——早く始めるほど、代償は小さくなる。

本記事はTechCrunchをもとに編集・翻訳したものです。