筆者は、OpenAI・Hugging Face インシデントがサイバーセキュリティにとって転換点であったと述べています。これは、典型的な脅威アクターの能力が今後数か月でどのように進化するかを垣間見せたためです。世界各地で開発されたAIモデルは、現実のサイバー攻撃の一部を自動化する能力を高めています。そのため、人間が書いたソフトウェアの奥深くに潜むバグから忘れられた権限まで、長年存在するセキュリティ上の穴を見つけて悪用することが容易になっています。

Hugging Faceのインシデントは、OpenAIが自社のAIモデルの現実世界でのサイバー能力を過小評価していたことを示しています。これを受けてOpenAIは安全要件を強化しており、その結果、既存の安全研究と社内のセキュリティ業務の緊急性がさらに高まっています。

複数の企業が、サイバー能力がフロンティアから数か月遅れ程度にとどまるモデルを、広く普及する形で公開してきました。筆者によると、こうしたサイバー能力を持つ広く普及したモデルの最新版は8月末に公開される予定とみられ、脅威の状況を大きく加速させそうです。

筆者が過去数週間に話した多くの組織に共通していたのは、前例のない速さでサイバーセキュリティの実務を根本的に引き上げる必要があると各組織自身が認識している、という点です。あらゆる企業の技術的負債(tech debt)が重大な欠陥を覆い隠していることがますます明らかになっており、防御側は攻撃者より先にそれらを発見と修正する必要があります。OpenAI・Hugging Face インシデントでは、エージェント型の集団(agentic collective)が、OpenAIの研究基盤だけでなく別の企業の本番基盤にも自律的に侵入しました。このインシデントにおいて、未知のセキュリティ欠陥からインターネット上に流出したユーザーアカウントの認証情報の利用まで、さまざまな脆弱性が連鎖させられました。

OpenAIは、基盤となるセキュリティ対策に大規模に重点投資しています。具体的には、セキュアなアーキテクチャと統制への投資を続け、多層防御(defense in depth)や最小権限(least privilege)といった戦略を採用し、壊滅的な事態が起きるには複数の独立した統制が同時に失敗しなければならないようなシステムを設計しています。ネットワーク分離(network isolation)、ワークロードの堅牢化(workload hardening)、監視、安全なパッチ適用とデプロイといった従来型のセキュリティ統制は、AI時代の将来において、これまで以上に重要になります。一刻を争う状況であるため、防御側は以下の手順を速やかに進める必要があります。

防御側が速やかに進めるべき具体的な手順

セキュリティリスクは急速に変化しているため、OpenAIは、セキュリティ組織とエンジニアリング組織がこれらのリスクに素早く対処するための支援・パートナーシップ・リソースを持つよう、組織としてのコミットメントと賛同(buy-in)を得ることを推奨しています。また、チームに対してテーブルトップ演習(tabletop exercises)を実施し、セキュリティ上の攻撃が自組織でどのように現れうるか、どう対応するかを模擬的に確認するよう勧めています。さらに、セキュリティチームにエージェント(agent)を持たせることを推奨しています。具体的には、Codex、Codex Security plugin、または他の有能なエージェント型のコーディング・セキュリティツールを使い始めることが挙げられます。

エージェントには、セキュリティチームが評価する必要のあるコードベース、インフラ構成、技術文書への承認済みアクセスを与えるようOpenAIは勧めています。その際、全社展開を待たず、最優先のシステムから始めることが推奨されています。エージェントにセキュリティの専門知識を持たせるには、まずコミュニティが支援するスキルから始めるべきです。これには静的解析、セキュリティ重視のコードレビュー、脆弱性のバリアント分析、ソフトウェアサプライチェーンのリスクなどのワークフローが含まれます。そのうえで、組織のアーキテクチャ、セキュリティ標準、脅威モデル、プレイブックに合わせた独自のスキルを構築します。

自社システムに対するセキュリティ評価をすぐに実行することが推奨されます。まずインターネットに面したサービス、認証フロー、infrastructure as code、デプロイパイプライン、機密情報を扱うシステムを優先し、チームが自信をつけるにつれてスキャンの範囲を広げます。既存の脆弱性バックログ(vulnerability backlog)に取り組むには、コードスキャナーの検出結果、依存関係のアラート、セキュリティチケット、バグバウンティの報告、過去の評価結果をエージェントに渡します。エージェントに対し、それらの検出結果をトリアージし、悪用可能な問題とノイズを区別し、コードベースの他の場所にある関連する脆弱性を特定し、何を先に直すべきか提案するよう依頼することが推奨されています。

セキュリティレビューを開発プロセスに直接組み込むようOpenAIは勧めています。具体的には、マージ前のコード変更のレビューにエージェントを使い、CIでセキュリティチェックを実行します。開発プロセスでのセキュリティチェックでは、認証のミス、アクセス制御のバイパス、露出した認証情報、安全でない依存関係、安全でないデフォルト、本番システムへのアクセスを広げる変更などの脆弱性を探します。エージェントに、見つけた問題の修正も手伝わせることが推奨されます。検証済みの問題については、焦点を絞ったパッチの生成と検証、回帰テスト(regression test)の作成、脆弱性がもう再現しないことの確認を依頼します。影響の大きい変更には人間のレビューを残しつつ、実際の問題の特定から、安全な修正をエンジニアに示すまでの不要な遅れをなくします。

検知のトリアージは段階的に自動化します。自律的なセキュリティオペレーションセンターを作ろうとすることから始めません。まずは1つのリポジトリに対する読み取り専用のセキュリティスキャンの実行、または既存ログへの読み取り専用アクセスでエージェントに過去に解決済みのアラートをレビューさせることから始めます。エージェントには証拠を要約し対応方針を提案させますが、あらゆる判断は人間が行います。自信が深まるにつれて、まず助言型のプルリクエストスキャン、次にライブのアラートのトリアージ、その次に狭く定義した誤検知の自動クローズへと進みます。

必要になる前に、AI支援のフォレンジック調査(forensic investigation)の能力を準備しておくことが推奨されます。具体的には、Trusted Access for Cyberに申請し、インシデント対応、検知エンジニアリング、マルウェア分析などの承認された防御目的の作業でGPT-Daybreak-Blueを使えるようチームの承認を得ます。また、GPT-Daybreak-Blueによる調査能力について、ログ、テレメトリ、セキュリティアラートの分析に使う練習をしておくことが推奨されます。

これからの世界に向けて、あらゆる種類の新しいツールを作り、仕事の進め方を変え、全員の力量を引き上げる必要があります。従業員に実験を奨励し、新しい能力を作るハックウィーク(hack week)を設定して、問題の小さな部分を自動化するループを素早く反復することに集中します。素早い漸進的な進歩は防御の成果を複利的に積み上げ、チームが自信をつけるにつれて自律性を徐々に広げることができます。

筆者は、AIの能力は防御側に弱点を発見して修正する新しい手段を与えるが、防御側は今すぐ動く必要があると述べています。企業が基本の改善とAIによるチームの強化を含めて断固として動けば、インターネットをこれまでで最も安全にできると筆者は述べています。AIを使う攻撃者は多くの既存システムの長年の欠陥をまもなく見つけられるようになりますが、一方でAIは防御側がその同じ欠陥を発見し、優先順位をつけ、修正することもはるかに容易にします。セキュリティは依然としていたちごっこですが、AIはその経済性を防御側に根本的に有利な方向へ変えうる、と筆者は述べています。

OpenAIは、人間を超えるレベルでセキュアなコードを書くよう、自社モデルを特に訓練し始めています。OpenAIのモデルは数学的証明にも非常に優れており、これを応用すれば、人間には手に負えないとされてきた形でソフトウェアのセキュリティを形式的に検証できます。OpenAIはモデルをより安全なコードを生成するよう訓練し続けており、新たに書かれるコードについて、一部の種類のソフトウェア脆弱性をなくすことを目標としています。

筆者の個人サイトでの事例は小さな例ですが、既存のモデルがサイバーガーディアンとして働けることを示しています。既存のモデルは、人間には対応する時間や専門知識がない問題のロングテールを見つけ、適切に調整した展開計画で修正できます。筆者がなんとなく知っているものの、正しい構成方法はすぐには分からないような設定が、この事例では修正されています。

第1の柱は、モデルを使ってコードを守ることです。Codexはセキュリティプラグインを含め、コード変更を検証し、脆弱性を特定し、開発者がデプロイ前に問題を修正するのを助けます。人間による検証が必要なセキュリティ上の発見事項をただ増やすことは、OpenAIにとってのアンチゴールであり、目的は実際の脆弱性を出荷前に捕捉することと、問題の発見から修正の安全なデプロイまでの道のりを短縮することです。

OpenAIのセキュリティ戦略の第2の柱は、モデルを使ってインフラを継続的に防御することです。現在、最初のセキュリティアラートのほぼすべてが、人間が関与する前にAIによってトリアージされています。このトリアージは、防御側の労力を減らし、対応時間を改善し、人間が識別、判断、応用的な専門知識というスキルを最も生かせる部分に時間を使えるようにすることに役立ちます。OpenAIは検知を範囲を限定した自動対応(bounded automated responses)にますます接続していますが、影響が最も大きい判断については人間の責任としています。目標は、セキュリティ問題をマシンの速度で検知し対応できるようにすることです。

OpenAIのセキュリティ戦略の第3の柱は、フロンティアインテリジェンスを使って、攻撃経路の候補を継続的に列挙し、探索し、特定することです。脆弱性、設定ミス、過剰な権限を持つID、意図しない信頼境界を特定することで、OpenAIはこれらが攻撃者に悪用される前に、ギャップをすばやく特定して塞ぐことができます。この継続的な列挙・探索により、OpenAIは自社の製品、インフラ、システム全体で、セキュリティ不変条件(security invariants)を継続的に評価、監視、テストできます。ここで言うセキュリティ不変条件とは、OpenAIが真であると信じているセキュリティ上の性質のことです。

筆者はOpenAIの技術に触れますが、評価すべき競合はエコシステムには多数あります。重要なのは特定のツールそのものよりも、高性能なAIを今すぐ防御側の手に渡すことです。

OpenAIのセキュリティ戦略と柱

OpenAIは、防御側を攻撃者より有利にするために、今年に入ってサイバー能力を信頼できる防御側にのみ公開し始めました。OpenAIは、自社を守るために、基礎的な統制（foundational controls）と、フロンティアインテリジェンスによる防御の強化の両方に大きく投資しており、この戦略には4つの柱があります。

個人サイトでの評価事例と、防御側への呼びかけ

OpenAI・Hugging Face インシデントの後、筆者は公開されているGPT-5.6 Solを使ったChatGPT Workに、gregbrockman.comのセキュリティ評価を依頼しました。このサイトはAWS上でホストされCloudflareをフロントドアとする単純な静的サイトであり、脆弱性の攻撃対象領域は大きくないと筆者は考えていました。

ChatGPT Work（公開されているGPT-5.6 Solを使用）がgregbrockman.comのセキュリティ評価を行ったところ、約15分で13件の問題が見つかりました。例として、DNSレコードは攻撃者が筆者になりすましてメールを偽造するのを防ぐ設定になっておらず、サイトは安全でないバージョンのjQueryを使用しており、CloudflareはAWSへのリクエストを暗号化されていないHTTPで転送していました。これらの問題の多くは単独では悪用できない可能性が高いですが、他の脆弱性と連鎖させれば大きな影響を生みうると筆者は考えています。

ChatGPT Workは、筆者の個人サイトからjQueryを完全に取り除きました。また、サイトをAWSからCloudflare Pagesへ移行し、DMARCの段階的な展開（phased rollout）を開始しました。

筆者は、OpenAIのセキュリティへのアプローチを共有することが他の組織の役に立つことを期待しています。どの企業も単独ではこの課題を成し遂げることはできないと筆者は述べています。そのため、AIラボ、セキュリティベンダー、企業、およびメンテナーに対して、検証済みの発見事項、修正、そして実践的なプレイブックを共有するよう求めています。そうすることで、ある組織の発見がエコシステム全体を強化できると考えています。

防御側のウィンドウは今開いています。今後数か月のうちに、すべての組織が安全を保つために、セキュリティプログラムの大幅な自動化に着手する必要があります。AIが進歩し続けるなか、攻撃側より速く防御側の力を高めるツール、実践、およびプレイブックを定義するために、セキュリティコミュニティは緊急に立ち上がる必要があります。これには前例のない大きな取り組みが必要ですが、皆で結集すれば、以前は想像できなかったほど安全な世界を実現できると筆者は述べています。