AI を活用した脆弱性発見の規模は、かつてないものです。Anthropic が Mythos モデルを用いて結成した防御型セキュリティパートナーのコンソーシアムの Project Glasswing は、運用開始からわずか 1 カ月で、1,000 を超えるオープンソースプロジェクトにおいて、重大度が「高」または「重大」の脆弱性を 6,202 件発見しました。これらの調査結果のサブセットに対して実施された独立検証では、90.6% の真陽性率が確認されました。2
これらの数字だけでも大きな意味を持ちます。事態を緊急のものにしているのは、脆弱性修正の現実です。Deutsche Telekom の CSO である Thomas Tschersich 氏によると、発見された約 23,000 件の脆弱性のうち、最初の数カ月間にパッチが適用され、文書化されたのはわずか約 75 件でした。同氏はまた、物理的に修正を迅速に取り込めないという理由から、一部のソフトウェアベンダーやメンテナーが Anthropic に報告頻度を落とすよう要請していることにも言及しました。3
2026 年の Verizon Data Breach Investigations Report (DBIR) は、業界レベルでこの傾向を裏付けています。DBIR の 19 年の歴史において初めて、脆弱性の悪用が、認証情報の盗難やフィッシングを抜いて、セキュリティ侵害における主な初期侵入経路となり、全インシデントの 31 ％を占めていることが判明しました。2025 年の脆弱性インシデント件数は 5 億 2,730 万件に達し、2022 年比で 8 倍に増加しました。一方で、完全なパッチ適用までの期間の中央値は 43 日に悪化し、米国の CISA (サイバーセキュリティ・インフラストラクチャ・セキュリティ庁) が把握する既知の悪用された脆弱性のうち、完全に修正されたものの割合は 38% から 26% に低下しました。4
Anthropic は 2026 年 6 月、他の AI 企業や開発者が 6 - 12 カ月以内に同等の攻撃用 AI 機能を開発するだろうと警告しました。サービスプロバイダーが準備を整えるための期間は限られており、その期限も迫っています。5
サービスプロバイダーが特有の脅威にさらされている理由
通信ネットワークは、世界で最も複雑なテクノロジー環境の 1 つです。また、最も攻撃の標的になりやすく、多くの特有の課題に直面しています。
現代のセキュリティモデルが確立される前に構築されたレガシーインフラストラクチャ。BT の Chief Security Authority である Dave Harcourt 氏が 2024 年に指摘したように、現在運用されている通信インフラストラクチャの多くは、今日の脅威環境をまったく想定していなかった時代に設計されたものです。6 サービスプロバイダーは膨大なブラウンフィールド環境を管理しており、長年にわたる拡張、統合、技術移行を通じて、数十年にわたるネットワーク要素、オペレーティングシステム、プロトコルが幾重にも積み重ねられています。これらの環境で発見された脆弱性の 45% 以上は、12 カ月が経過しても依然として修正されていません。4
あらゆる業界の中でも類を見ない広大な攻撃対象領域。 サービスプロバイダーの環境は、顧客リソース管理 (CRM) や課金システム、SIP や Diameter などのコアネットワークプロトコル、5G サービスベースのアーキテクチャのアプリケーション・プログラミング・インターフェース (API)、ルーティングおよび伝送インフラストラクチャ、合法的傍受システム、そして数百万ものネットワークデバイスにまで及びます。その多くは、サービスプロバイダーが独自に監査したりパッチを適用したりできない、ベンダー独自のソフトウェアを実行しています。
高度な手口を用いる脅威アクターによる組織的な標的型攻撃。Salt Typhoon キャンペーンでは、少なくとも 9 社の米国通信事業者のセキュリティが侵害され、100 万人以上のユーザーについての合法的傍受システムや通話詳細記録へのアクセスが行われました。7 最大 2 年間にわたり、攻撃の潜伏期間中、検出されませんでした。シンガポールでは、UNC3886 キャンペーンにより、国内の通信業者 4 社すべてのセキュリティが侵害され、11 カ月間にわたる協調的な対抗措置が必要となりました。9 カナダでは、ある脅威アクターが大手サービスプロバイダーから少なくとも 700 TB のデータを盗み出しました。10 これらは孤立した事件ではなく、通信インフラストラクチャを明確に対象とした、持続的かつ十分なリソースを投入したキャンペーンを反映しています。
共通ベンダーへの依存による相関リスクの発生。世界中のサービスプロバイダーは、無線アクセスネットワーク (RAN) ならびにコアおよび伝送インフラストラクチャに関して、特定の機器ベンダー群に依存しています。したがって、あるベンダーのソフトウェアに脆弱性があれば、複数のサービスプロバイダーが同時に影響を受けることになります。通信事業者間の相互接続は、相関リスクに第 2 の側面を加えます。業界が C2 ISAC を設立した理由について、T-Mobile のサイバーセキュリティ責任者である Mark Clancy 氏は、SIM ボックス詐欺などのケースでは、ある通信事業者が自社ネットワーク上のデバイスを特定できても、コマンド＆コントロールサーバーが別の通信キャリアのインフラストラクチャ上にあることがあり、通信事業者は双方を共同で調査する必要があると指摘しています。11
現在の防御策：大きな進展と重大なギャップ
業界は決して立ち止まってはいません。進化し続ける脅威の状況に直接対応する形で、3つの主要な取り組みが生まれました。いずれも真の価値をもたらす一方で、それぞれが特定の課題に対処できていない点もあります。
Project Glasswing は、参加組織に対し、Mythosを活用した予防的な脆弱性スキャンへのアクセスを提供します。Verizon、AT&T、BT などのサービスプロバイダーを含む、15 カ国の 200 を超える組織が参加しています。Glasswing は、サービスプロバイダーのインフラストラクチャを支えるオープンソースプロジェクトにおいて、すでに数千件もの重大な脆弱性を明らかにしています。しかし、その対象範囲には制限があります。Nokia や Ericsson などの主要なネットワーク機器プロバイダー (NEP) は参加していません。サービスプロバイダーのネットワークの真のバックボーンを形成する RAN、コア、伝送機器上で稼働するプロプライエタリーなソフトウェアは、スキャン対象外となっています。サービスプロバイダーは、このコードを独自に監査したり、パッチを適用したりすることはできません。修正サイクルは依然として、ベンダーのスケジュールに完全に依存したままです。
C2 ISAC は、米国の主要サービスプロバイダー 8 社の CISO を集め、民間セクター限定のリアルタイムなインテリジェンス共有を行っています。これにより重要な連携のギャップが埋まり、侵害の兆候、攻撃者の手法、および対策マニュアルを運用速度で共有できるようになります。初期の成果として、サービスプロバイダーを横断した加入者識別モジュール (SIM) ボックスの検出手法や、住宅用プロキシネットワークに対する協調的な対応などが挙げられます。しかし、C2 ISAC は現在米国を中心としており、米国外のサービスプロバイダーのメンバーはおらず、NEP ベンダーや運用支援システム/業務支援システム (OSS/BSS) ベンダーも参加していません。これはインテリジェンス共有の仕組みであり、修正エンジンではありません。
GSMA T-ISAC (グローバル)、ET-ISAC (欧州)、ICT-ISAC (日本) などを含む地域ごとの ISAC および枠組みは、脅威認識、規制の整合性、国境を越えた協力体制をさらに強化しています。欧州の ET-ISAC は、隔週でコンピュータ緊急対応チーム/セキュリティオペレーションセンター (CERT-SOC) の脅威インテリジェンス会議を開催し、年次セキュリティベンチマークを実施しています。GSMA T-ISAC にはサービスプロバイダーだけでなくベンダーも含まれますが、現在の C2 ISAC にはベンダーが含まれていません。これらは可視性と備えを高めるための有用な枠組みです。しかし、いずれもパッチを提供するものではありません。
3 つの取り組みすべてに共通しているのは、業界が脅威情報を把握し、共有するスピードが向上した点です。しかし、これらの取り組みは、脆弱性が実際に修正されるまでのスピードを加速するものではありません。
Deutsche Telekom の Tschersich 氏は、Glasswing の調査結果に対する直接的な回答の中で、核心的な問題を次のように指摘しました。「AI はかつてないほど迅速に脆弱性を発見します。しかし、発見が早くなったからといって、修正が早くなるわけではありません。パッチ適用にかかる時間を 1 日でも短縮できれば、それは大きな意味を持ちます」3
修正の危機：真のリスクが存在する領域
データは明白です。業界の主要なセキュリティの課題は、検知から修正へとシフトしました。
エンタープライズ・アプリケーション・コードの 90% は、オープンソースまたはサードパーティの依存関係で構成されています。Black Duck が監査した平均的なオープンソースコードベースには、現在 581 件の既知の脆弱性が含まれており、この数はわずか 1 年で倍増しました。12 また脆弱性が悪用されるまでの平均時間はマイナス 7 日となっており、攻撃者はパッチが提供される 1 週間も前に脆弱性を日常的に悪用できることを意味します。13
現在の修正措置では、このペースに追いつくことができません。スキャンツールが、間接的なオープンソース依存関係にある重大な共通脆弱性識別子 (CVE) を検出した場合、通常の対応では、開発者が調査を行い、パッケージの新しいバージョンを取得し、アプリケーションを再ビルドし、互換性を損なう変更がないかをテストし、多くの場合、新しいバージョンに対応するためにコードを書き直す必要があります。サービスプロバイダーがテスト済みかつ認定済みのソフトウェア構成を維持しなければならない規制環境では、強制的なバージョンアップグレードが、認証プロセスの全サイクルを再実施するきっかけとなる可能性があります。
スキャンツールは重要な役割を果たします。これらのツールは、セキュリティチームに問題の所在を伝えます。しかし、脆弱性を修正するわけではありません。スキャナーの出力は、検出結果のダッシュボードにすぎません。そのダッシュボードと、パッチ適用済み、かつ署名済みの本番環境に対応するアーティファクトとの間にあるギャップこそが、リスクが蓄積される場所です。
脆弱性を手動で修正するためにパッケージをフォークしたり、リスクのバックログを容認したり、安定性を維持するためにアップグレードを遅らせたりといった社内の回避策は、それ自体が新たな問題を引き起こします。社内のフォークはすべてアップストリームから分岐するため、恒久的なメンテナンスの負担となります。リスクのバックログは監査不合格へと発展します。アップグレードの遅延は技術的負債を増大させます。AI が毎月何千もの脆弱性を検出する状況において、これらのアプローチはどれも拡張できません。
