Califは、Patch the Planetイニシアチブの一環としてGPT-5.6 Solを使い、Webサイトやウェブアプリケーションの実行に使われるオープンソースのプログラミング言語、PHPの重大な欠陥を特定しました。PHPには重大な脆弱性が2件あり、Wizも独立して、その両方を発見し報告しています。今回のPHPの件は、AIがインターネット規模の影響を持つセキュリティ上の欠陥を見つけ得ることを示しています。一方で、同じ能力は攻撃者が攻撃ツールやエクスプロイトを素早く開発するのにも役立ち得ます。欠陥の深刻さとPHPが広く使われていることから、筆者らはこれを近年で最も影響の大きいセキュリティ問題の一つと考えています。筆者らの知る限り、フロンティアAIは攻撃者より先にこれらの脆弱性を見つけました。これにより、メンテナーとセキュリティプロバイダーが開示前に修正と防御策を準備できる「Defender’s Window」が生まれました。
PHPのメンテナーが修正とリリースを主導しました。公開前の防御策の準備では、WizやCloudflareなどのパートナーと自社チームが、研究、技術支援、調整で貢献しました。PHPを使う組織にとっての今の優先事項は、修正を適用することです。
運用者が脆弱な可能性のあるPHPのバージョンを特定する助けとして、Codex skillとしてPHP version checkerが共有されています。このツールは、PHPやプロバイダーのガイダンスと合わせて、どの更新が該当するかを判断するために利用できます。
広範な対応のための5段階フレームワーク
一部の発見では、研究者がソフトウェアのメンテナーと直接協力して問題を調査し、修正を開発できます。一方で、他の発見にはより広範な対応が必要となる場合があります。多くの製品に影響する場合や、ディストリビューターやサービスプロバイダー(service providers)が更新と防御策を準備するための時間を必要とする場合です。フロンティア能力が広く利用可能な能力からそれほど先行していない場合には、この時間が不足するおそれがあります。より広範な対応が必要な場合、提案フレームワークは、メンテナーが誰を関与させるべきかを特定し、作業を調整するのに役立ちます。この対応は5つの段階からなり得ます。
提案フレームワークの5段階のうち、上流(upstream)の脆弱性を検証・修正する段階では、メンテナー、研究者、不可欠な技術パートナーが発見内容を確認し、影響を評価して、修正を開発しテストします。このプロセスには、パッチを回避する方法や関連する脆弱性の変種を探すための、フロンティアモデルを使った敵対的テスト(adversarial testing)が含まれます。次に、影響を受ける組織に対応の時間を与える段階では、保護の準備のために事前情報を必要とする組織を考えるための提案フレームワークを示しますが、誰を関与させるかはメンテナーが決めることとされています。この段階で筆者らは、アウトリーチ、情報共有契約、チーム間の調整を支援します。例として、ディストリビューターが古いリリース向けに修正を適応させたり、ホスティングプロバイダーが緩和策(mitigation)をテストしたり、セキュリティプロバイダーがWebアプリケーションファイアウォール(WAF)ルールなどの検知・防御策を準備したりすることが挙げられます。
政府パートナーとの連携は、重要システムを守るための段階です。政府機関は、より広範な対応を調整し、重要インフラやその他の必須サービスを担う組織にセキュリティガイダンスが届くよう支援する上で、不可欠な役割を果たします。PHPの件では、パートナーと協力して、ホワイトハウスのSuper Intelligence Force、国家サイバーディレクター室(ONCD)、サイバーセキュリティ・インフラストラクチャセキュリティ庁(CISA)などの米国政府の複数の部門と、国際パートナーに働きかけ、その取り組みを支援しました。提案フレームワークの5段階のうち、影響を受ける製品全体で更新を準備する段階では、修正・ガイダンス・開示(disclosure)計画が安定してきたら、メンテナーは追加のディストリビューター、ホスティング・サービスプロバイダー、対応チーム、オペレーターを関与させ、更新を準備して対応範囲の抜けに対処できます。
パッチが利用可能になったら、ガイダンスを公開してデプロイを支援します。公開ガイダンスは、自分の露出の評価、信頼できる更新や暫定的な緩和策(interim mitigation)の発見、修正が稼働していることの確認に役立ちます。オペレーターが更新をデプロイし、支援が必要な点を報告する間も対応は続きます。Patch the Planetのウェブサイトは、公開された開示情報とガイダンスをまとめ、オペレーターが影響を受けるシステムの特定、適切な更新の発見、更新したソフトウェアが正しく稼働していることの確認を行えるようにします。PHPについては、Patch the Planetのウェブサイトは、メンテナーによる公式のパッチとアップグレード手順、およびパートナーの技術調査へのリンクを示しています。また、Patch the Planetのガイダンスは、暫定的な緩和策、プロバイダーや専門家を関与させるべき時期、バックアップと復旧も扱います。暫定的な保護はリスクを減らせますが、筆者らはその限界と運用上のトレードオフを明確に示します。
提案フレームワークは、組織の保護上の役割（自組織のシステムと顧客の保護を含む）、対応に必要な時間、機微な情報を扱う能力を考慮します。同等の組織には同じ基準が適用されることになり、開示前に誰を関与させるかはメンテナーが決めます。各参加者は保護作業に必要な情報を受け取りますが、その範囲は、侵害指標(indicators of compromise)を含むネットワークログから、より機微な動作するproof-of-concept exploitまで及びます。限られた詳細でも脆弱性が明らかになりうるため、共有のリスクと、それによって可能になる保護を比較衡量します。また、システムを運用するオペレーターは、どれだけ早く対応するかの優先順位を状況の変化に応じて再評価すべきであり、恒久的な修復に至る明確な道筋を持つべきです。
オペレーターは、露出度、悪用状況、および潜在的影響に基づいてどれだけ迅速に対応すべきかを評価するために、CISAのガイダンスによる優先順位付けと修復に関するガイダンスを利用できます。CISAのガイダンスに基づく対応には、緊急パッチ適用、即時の緩和策、または計画的なアップデートが含まれることがあります。あわせて、必要に応じてフォレンジック・トリアージを行い、システムがすでに侵害されているかを評価することも含まれます。
広く使われるソフトウェアの重大な脆弱性への対応について、AI時代に適した提案フレームワークが共有され、セキュリティコミュニティにその改善への協力が求められています。このフレームワークは、モデル、セキュリティの専門知識、メンテナーを結びつけ、発見を防御に変え、AI能力の進歩に合わせて拡張できる対応を築く助けとなります。脆弱性の修正を実際に使われる状態にするには、古いリリース向けに修正を適合させることや、プロバイダーの緩和策を準備すること、多くの組織のシステムを更新することといった作業が必要になることがあります。再現可能なプロセスは、さらに多くの脆弱性が見つかる中で、こうした作業に当たるチームが素早く動く助けになります。今回のPHPのバグは、筆者らがすでに見つけて修正に取り組んでいる重大な脆弱性のうちのいくつかです。筆者らは、今後数か月で同様の発見が急増すると見込んでいます。Patch the Planetを通じて、筆者らはPHPへの対応のためにセキュリティの専門知識とモデルへのアクセスを提供し、メンテナーや研究パートナーと協力して修正をテストし、ガイダンスを準備しました。また、影響を受けるシステムの防御策についてインフラプロバイダーとの調整を支援し、ガイダンスが重要な組織に届くよう政府のサイバー機関に働きかけました。
防御側への投資、メンテナー支援、悪用対策
AIの高度な能力は業界全体で進歩しており、筆者らは、防御側が脆弱性を見つけ、システムを監視し、脅威に対応するうえでAIが果たす役割は拡大すると見込んでいます。筆者らは、防御側がその能力を実際に活用できるよう、モデル、ツール、パートナーシップに投資しています。この投資には、Codex for OSSを通じたすべてのメンテナー向けのサブスクリプションと、メンテナーや技術的作業を支えるためのRust Foundationなどのプロジェクトへの直接スポンサーシップが含まれます。各プロジェクトは自らの優先順位を決定します。
このフレームワークに従うチームは、メンテナーと協力して防御側に準備の時間を与えます。悪用が実際に確認された場合や、漏えい、パッチが公開されて内容が露呈する場合、あるいは修正が滞ってユーザーのリスクが高まる場合には、タイムラインを再評価します。グローバルな連携は、ソフトウェアを保守する人々に依存します。多くのプロジェクトは小規模なチームが運営しており、通常の開発と並行してセキュリティ報告を確認しています。そうしたチームは、新しい問題と重複の切り分け、影響の評価、サポート対象のリリース全体での修正のテストについて支援を必要としています。再利用可能なテストとセキュリティワークフローは、今後の発見事項に対処するための労力を減らせます。オープンソースプロジェクトは、実地の支援を受けるためにPatch the Planetに応募できます。筆者らは、資金、高性能なモデルへのアクセス、実地のエンジニアリング支援によって、こうしたチームの作業を支えています。
筆者らは、Daybreakの悪用の可能性を減らすために、追加のブロッキング分類器(blocking classifier)を調整しています。悪用を防ぐための安全対策は正当なセキュリティ作業もブロックしうるため、難しいトレードオフが伴います。高性能なモデルへの幅広いアクセスと、悪用に対する効果的な保護は、どちらも重要です。筆者らは、防御側が脆弱性を見つけて修正するために必要な能力を維持しつつ、有害な利用を抑えることを目指しており、能力が進歩し、これらのツールがどう使われるかから学ぶのに応じて、この維持と抑制のバランスを改善し続けるとしています。
より安全なソフトウェアを作る取り組み
モデルの能力が高まるにつれ、個々の脆弱性の発見と修正にとどまらない機会が広がります。筆者らは、エンジニアが最初からより安全なソフトウェアを構築できるよう支援したいと考えています。広く使われるコンポーネントを改善すれば、多くの製品やサービスでバグを防いだり、その影響を抑えたりできます。AIは、エンジニアが既存のコードを理解し、変更を準備し、テストを開発するのを助けることができ、その際、メンテナーとセキュリティ専門家が、その変更がユーザーの依存する挙動を保っていることを確認します。
コーディングモデルは、開発者がより安全なデフォルトを選び、セキュリティライブラリを正しく使い、コードを書く際に危険なパターンを検出するのを助けることができます。開発中に脆弱性を防ぐことで、メンテナーとユーザーにとっての緊急修正が減ります。重要なコンポーネントをメモリ安全な言語(memory-safe language)へ移行すると、よくある種類のメモリエラーをなくせますが、AIは移行を支援でき、挙動と互換性の確認にはテストと専門家によるレビューを使います。形式検証(formal verification)では、数学的証明によって、重要なコンポーネントが、述べられた前提のもとで指定されたセキュリティ特性を満たすことを示せます。広く使われるコンポーネントにこの手法を適用すれば、それらに依存するサービスや重要インフラ全体で、脆弱性の種類を排除する助けになりうります。
強力な分離として、システムにはまだ発見・修正されていない脆弱性への防御が必要です。信頼できないファイル、画像、またはメディアを処理するソフトウェアを厳しく制限されたサンドボックスで動かせば、侵害された場合の被害を抑えることができます。AIは、エンジニアが広く使われるサンドボックス技術のテストと強化を行うのを助け、多くのアプリケーションの保護を改善できます。
フィードバックを求める論点
開示期間(disclosure window)に関する論点では、メンテナー、オペレーター、防御側が信頼できる修正を準備して展開するのにどれだけの時間が必要かを問うています。また、一部のユーザーを他より早く保護できる場合を中心に、どのような証拠があれば早期の開示の引き金とすべきかも問うています。
筆者らは、メンテナー、研究者、対応チーム、プロバイダー、運用者がこのアプローチを実現可能なものにする手助けをできるよう、アプローチを共有しています。このアプローチがどこで役立ち、どこで遅延や負担を増やしうるか、そして何を見落としているかを知りたいと考えています。筆者らは、このアプローチへのフィードバックとして、過去の脆弱性開示の事例が特に役立つと考えています。また、このアプローチをレビューし、前提に異議を唱え、抜けを見つけてくれる独立したセキュリティ専門家の推薦も歓迎しています。寄せられた意見は、対応を洗練させ、支援の優先順位を決めるのに役立ちます。
緊急パッチ適用(emergency patching)に関する論点では、政府や他のオペレーターが、管理者アクセスを失った後に、自らが所有または管理を許可されたシステムにパッチを当てるために脆弱性を使うべき場合があるとすればそれはいつか、またどのような安全策を適用すべきかを問うています。筆者らは、既知の脆弱性をインターネット全体で常時スキャンし、検出時にサイト所有者へ通知するか、そのシステムにパッチを当てるという最終状態を想像できるとしています。
意見募集の論点の一つである事前通知(Early notice)では、有用な防御行動をとるために事前警告が必要なのは誰か、見落としうる防御側を含む対象について問うています。また、段階的な通知が、より広い集団に一度に通知するより有効なのはいつか、カバー範囲と漏えいリスクをどう比較衡量すべきかも問うています。
意見募集の論点の一つであるセキュア・バイ・デフォルトのソフトウェアパッケージ(Secure-by-default software packages)では、アップストリームの修正が保留中の間にダウンストリームパッケージの脆弱性を特定・修正する方法、またはセキュリティ更新を受けなくなった古いバージョンへ修正をバックポートする方法について問うています。適時のアップグレードが現実的でない場合に、セキュア・バイ・デフォルトのソフトウェアパッケージを信頼できる選択肢にするにはどのようなテストと保守が必要かも問うています。