過去 2 か月にわたり、私たちはメンテナー、研究者、セキュリティ事業者の連携を主導し、ウェブサイトやウェブアプリケーションの実行に使われるオープンソースのプログラミング言語 PHP の重大な脆弱性に対処してきました。Calif は、私たちの Patch the Planet（新しいウィンドウで開く） の取り組みの一環として、GPT‑5.6 Sol を使って重大な欠陥を特定しました。また、Wiz も独自に両方の脆弱性を発見し、報告しました。PHP のメンテナーが修正とリリースを主導し、私たちのチームや Wiz、Cloudflare などのパートナーが調査、技術支援、調整に協力して、情報公開に先立って防御策を準備しました。
PHP を利用する組織にとって、今の最優先事項は修正の適用です。運用担当者が脆弱性のある可能性がある PHP バージョンを特定し、PHP や利用先の事業者のガイダンスと併せて必要な更新を判断できるよう、PHP バージョンチェッカーを Codex スキルとして公開しています（新しいウィンドウで開く）。
これらの欠陥の深刻さと PHP の普及度を踏まえ、私たちは今回の問題を、近年で最も影響の大きいセキュリティ問題の一つと捉えています。今回の事例は、AI がインターネット規模の影響を及ぼすセキュリティ上の欠陥を発見できることを示しています。ただし、同じ能力が、攻撃者による攻撃ツールやエクスプロイトの迅速な開発にも役立つ可能性があります。
私たちの知る限り、フロンティア AI は攻撃者より先にこれらの脆弱性を発見しました。その結果、メンテナーやセキュリティ事業者は、公開前に修正や防御策を準備できる防御側の猶予期間を得られました。
より多くの防御側がこうした能力を活用できるよう、私たちは Daybreak for Frontline Defenders を通じて、Daybreak の利用に 10 億ドルの助成を行うことを約束しています。支援の重点は、限られたセキュリティリソースで社会に不可欠なサービスを守る組織に置いています。
今回のバグは重大ですが、私たちがすでに発見し、修正に取り組んでいる複数の重大な脆弱性の一部にすぎません。今後数か月で、同様の発見が急増すると見込んでいます。これまでの経験を踏まえ、広く使われているソフトウェアの重大な脆弱性に対処する、AI 時代にふさわしいアプローチを提案します。この枠組みを改善するため、セキュリティコミュニティの協力を求めています。この枠組みは、私たちのモデルとセキュリティの専門知識、そしてメンテナーの力を結集し、発見を防御につなげ、AI の能力向上に合わせて拡張できる対応体制の構築を支援するものです。
修正を実際の運用に反映するには、旧リリースへの対応、事業者による緩和策の準備、多くの組織にまたがるシステム更新が必要になることがあります。繰り返し使えるプロセスがあれば、脆弱性の発見が増えても、各チームは迅速に行動できます。
私たちは Patch the Planet を通じて、セキュリティの専門知識とモデルへのアクセスを提供し、PHP の対応を支援しました。また、メンテナーや研究パートナーと協力して修正をテストし、ガイダンスを準備しました。影響を受けるシステムの防御策についてインフラ事業者との調整を支援するとともに、政府のサイバーセキュリティ機関に働きかけ、重要な役割を担う組織にガイダンスが届くようにしました。こうした活動がメンテナー主導の対応を支え、他の防御側の準備にも役立ちました。
発見された問題によっては、研究者がソフトウェアのメンテナーと直接協力して調査し、修正を開発できます。一方、多くの製品に影響する場合や、配布元やサービス事業者が更新や防御策を準備する時間を必要とする場合は、より広範な対応が必要です。ただし、フロンティアの能力と広く利用可能な能力との差が小さい場合、準備時間は限られる可能性があります。こうした場合、提案する枠組みは、メンテナーが関与を求めるべき相手を特定し、作業を調整するうえで役立ちます。対応は、次の 5 段階で進められます。
上流の脆弱性の検証と修正メンテナー、研究者、不可欠な技術パートナーが発見内容を確認し、影響を評価したうえで、修正を開発してテストします。このプロセスには、フロンティアモデルを使い、パッチを回避する方法や関連する脆弱性の亜種を探す、攻撃者の視点に立ったテストも含まれます。
影響を受ける組織の対応時間の確保私たちは、防御策の準備に向けて事前情報を必要とする組織を検討するための枠組みを提案します。どの組織に関与を求めるかは、メンテナーが決定します。私たちは、関係者への連絡、情報共有に関する合意、チーム間の調整を支援します。配布元は旧リリース向けに修正を移植し、ホスティング事業者は緩和策をテストし、セキュリティ事業者はウェブアプリケーションファイアウォール（WAF）のルールなど、検知や防止の対策を準備することが考えられます。
重要システムの保護に向けた政府機関との連携政府機関は、より広範な対応を調整し、重要インフラやその他の不可欠なサービスを担う組織にセキュリティガイダンスを届けるうえで、欠かせない役割を果たします。PHP の事例では、パートナーと協力し、ホワイトハウスの Super Intelligence Force、国家サイバー長官室（ONCD）、サイバーセキュリティ・インフラセキュリティ庁（CISA）など米国政府の複数の部門や、国際的なパートナーとの連携に取り組み、この活動を支援しました。
影響を受ける各製品の更新準備修正、ガイダンス、公開計画が固まってきた段階で、メンテナーはさらに多くの配布元、ホスティング・サービス事業者、対応チーム、運用担当者に関与を求め、更新の準備や対応範囲の抜け漏れの解消を進められます。
パッチ提供開始後のガイダンス公開と適用支援公開ガイダンスは、利用者がリスクにさらされている状況を評価し、信頼できる更新や暫定的な緩和策を見つけ、修正が適用されていることを確認するのに役立ちます。運用担当者が更新を適用し、支援が必要な点を報告する間も、対応は続きます。
提案する枠組みでは、自社のシステムや顧客の保護を含む組織の防御上の役割、対応に必要な時間、機密情報を適切に扱う能力を考慮します。同等の組織には同じ基準を適用し、公開前にどの組織に関与を求めるかはメンテナーが判断します。
各参加者には、侵害指標を含むネットワークログから、より機密性の高い、実際に動作する概念実証用エクスプロイトまで、それぞれの防御活動に必要な情報を提供します。限られた情報でも脆弱性が明らかになる可能性があるため、共有のリスクと、それによって可能になる防御の効果を比較検討します。
この枠組みに沿って動くチームは、メンテナーと協力して防御側の準備時間を確保します。また、実環境での悪用、情報漏えい、脆弱性を推測できるパッチの公開、修正の停滞による利用者リスクの増大があれば、スケジュールを見直します。
Patch the Planet のウェブサイト（新しいウィンドウで開く）には、公開情報とガイダンスをまとめています。運用担当者が影響を受けるシステムを特定し、適切な更新を見つけ、更新後のソフトウェアが正常に動作していることを確認するために役立ちます。PHP については、メンテナーによる公式パッチとアップグレード手順、パートナーの技術調査を案内しています。ガイダンスでは、暫定的な緩和策、事業者や専門家への相談が必要なタイミング、バックアップと復旧についても説明しています。暫定的な防御策はリスクを軽減できますが、その限界と運用上のトレードオフも明確に示します。
運用担当者は、CISA の優先順位付けと修復に関するガイダンス（新しいウィンドウで開く）を使い、リスクへの露出状況、悪用の状況、想定される影響に基づいて、対応の緊急度を評価できます。状況に応じて、緊急のパッチ適用、即時の緩和策、計画的な更新を行い、必要であればフォレンジック調査の初期評価も実施して、システムがすでに侵害されていないかを確認します。恒久的な修復への道筋を明確にしつつ、状況の変化に合わせて優先順位を見直す必要があります。
世界規模の連携を支えるのは、ソフトウェアを保守する人々です。多くのプロジェクトは少人数のチームで運営され、日常的な開発業務と並行してセキュリティ報告を確認しています。こうしたチームには、新たな問題と重複報告の切り分け、影響の評価、サポート対象リリース全体での修正テストを支える支援が必要です。私たちは、資金、高性能なモデルへのアクセス、エンジニアリングの実務支援を通じて、こうした作業を支えています。
業界全体で AI の能力が高まるなか、脆弱性の発見、システムの監視、脅威への対応を支える AI の役割は、ますます大きくなると考えています。私たちは、防御側がこうした能力を実際に活用できるよう、モデル、ツール、パートナーシップに投資しています。
その一環として、Codex for OSS を通じたすべてのメンテナーへのサブスクリプション提供や、Rust Foundation（新しいウィンドウで開く） などのプロジェクトへの直接的な資金援助により、メンテナーと技術的な作業を支援しています。優先順位は、各プロジェクトが独自に決定します。再利用可能なテストとセキュリティワークフローは、今後発見される問題への対応に必要な労力を減らせます。オープンソースプロジェクトは、Patch the Planet に応募（新しいウィンドウで開く）して、実務的な支援を受けられます。
また、悪用の可能性を減らすため、Daybreak に追加するブロック用分類器の調整も進めています。これには難しいトレードオフがあります。悪用を防ぐための安全対策が、正当なセキュリティ業務まで妨げる可能性があるためです。高性能なモデルを広く利用できることと、悪用を効果的に防ぐことは、どちらも極めて重要です。私たちの目標は、有害な利用を制限しながら、防御側が脆弱性の発見と修正に必要とする能力を維持することです。能力の向上や、ツールの利用実態から得られる知見を踏まえ、このバランスを引き続き改善していきます。
モデルの能力が高まるにつれ、活用の可能性は個々の脆弱性の発見や修正にとどまらなくなります。私たちは、エンジニアが最初からより安全なソフトウェアを構築できるよう支援したいと考えています。広く使われているコンポーネントを改善すれば、多くの製品やサービスでバグを防いだり、その影響を抑えたりできます。
AI は、エンジニアによる既存コードの理解、変更の準備、テストの作成を支援できます。一方、メンテナーやセキュリティ専門家は、その変更によって利用者が依存する動作が損なわれないことを検証します。私たちは、いくつかの分野に可能性を見いだしています。
開発当初からの安全なコードコーディングモデルは、開発者がより安全なデフォルト設定を選び、セキュリティライブラリを正しく使い、コードを書く段階で危険なパターンを見つけるのに役立ちます。開発中に脆弱性を防げれば、メンテナーや利用者が緊急の修正に追われる機会を減らせます。
メモリ安全なソフトウェア重要なコンポーネントをメモリ安全な言語に移行することで、よくある種類のメモリエラーを排除できます。AI は移行を支援できます。その際は、テストと専門家によるレビューで動作や互換性を確認します。
形式検証数学的な証明によって、重要なコンポーネントが明示された前提のもとで、指定されたセキュリティ特性を満たすことを示せます。広く使われているコンポーネントにこうした手法を適用すれば、それらに依存するサービスや重要インフラ全体で、特定の種類の脆弱性を排除できる可能性があります。
隔離の強化システムには、まだ発見も修正もされていない脆弱性に対する防御も必要です。信頼できないファイル、画像、メディアを処理するソフトウェアを、厳しく制限されたサンドボックス内で実行すれば、侵害された場合の被害を抑えられます。AI は、広く使われているサンドボックス技術のテストや強化を支援し、多くのアプリケーションの防御を改善できます。
私たちがこのアプローチを公開するのは、メンテナー、研究者、対応チーム、事業者、運用担当者の協力を得て、実際に機能するものにするためです。どのような場面で役立つのか、どこで遅延や負担が増えるおそれがあるのか、何を見落としているのかを把握したいと考えています。特に、過去の脆弱性公開の事例が参考になります。
とりわけ、次の点についてご意見を求めています。
公開までの猶予期間メンテナー、運用担当者、防御側が信頼できる修正を準備し、適用するには、どれほどの時間が必要でしょうか。特に、一部の利用者を他の利用者よりも早く保護できる場合、どのような証拠をもとに公開を前倒しすべきでしょうか。
緊急のパッチ適用政府やその他の運用主体が、自ら所有する、または管理権限を持つシステムへの管理者アクセスを失った場合、脆弱性を利用してパッチを適用すべき状況はあるのでしょうか。あるとすれば、どのような場合でしょうか。どのような安全対策を設けるべきでしょうか。将来的には、インターネット全体で既知の脆弱性を常時スキャンし、検出したらサイト所有者に通知するか、システムにパッチを適用する仕組みも考えられます。
事前通知私たちが見落としている防御側も含め、有効な防御策を講じるために事前の警告を必要としているのは誰でしょうか。広い範囲に一斉に通知するより、段階的な通知が有効なのはどのような場合でしょうか。また、通知範囲と漏えいリスクをどのように比較検討すべきでしょうか。
デフォルトで安全なソフトウェアパッケージ。 上流の修正を待つ間に下流パッケージの脆弱性を特定・修正したり、セキュリティ更新が終了した旧バージョンに修正をバックポートしたりするには、どのような支援ができるでしょうか。速やかなアップグレードが難しい場合に、これらのパッケージを信頼できる選択肢にするには、どのようなテストと保守が必要でしょうか。
また、このアプローチをレビューし、その前提を問い直し、抜け漏れを特定できる独立したセキュリティ専門家の推薦も歓迎します。皆さまのご意見は、対応の改善と支援の優先順位付けに役立ちます。こちらからご意見をお寄せください（新しいウィンドウで開く）。
