GenAI が招くセキュリティ・リスク:オープンソースの脆弱性は氷山の一角に過ぎない

Open Source is the Tip of the Iceberg: Why Proprietary Software, Hardware and Protocols Face Greater AI-Driven Security Risk

2026/05/06 InfoSecurity — 2026年4月に Anthropic が発表した Project Glasswing では 、そこに参加した 11社の主要企業が Claude Mythos Preview モデルを用いて、重要なオープンソース・ソフトウェアの脆弱性を発見していった。長年にわたり監査されてきたコードベースに潜むバグを発見した Mythos は、サイバーセキュリティ業界から高く評価された。


Glasswing の活動は有益なものであるが、オープンソースの問題は可視化されやすい部分でもある。なぜなら、これまでのオープンソース・ソフトウェアは、常にコミュニティ・レビューの恩恵を受け続けてきたからである。

その一方で、誰にも見られていないソフトウェアである、プロプライエタリのバイナリ/組み込みファームウェア/レガシープロトコル/チップのマイクロコードなどには、未発見の危険な脆弱性が大量に蓄積されている。そして Glasswing を実現した AI 能力は、それらすべてを露出させようとしている。

プロプライエタリ・ソフトウェアは根本的に異なるモデルで動作しており、誰にも見られていないコードの中にバグが蓄積されている。歴史的に見て、そのセキュリティ体制は単純な前提に依存してきた。つまり、攻撃者がソースコードを読むことがなければ、バグを見つけるのも難しくなるという前提である。しかし、これは妥当性のあるセキュリティではなく、隠蔽によるセキュリティである。

バイナリ障壁の崩壊

攻撃者はプロプライエタリ・ソースコードを目にしないため、問題は発生しないとされてきた。彼らが入手できるのは、変数名/コメント/構造が取り除かれたコンパイル済みバイナリのみである。しかし、この考え方は時代遅れになりつつある。

解決されずに残存していたのは、人間というボトルネックである。典型的なセキュリティ監査では、コードベースの一部しか対象にされず、優先順位付けを担う監査者は直感で高リスク領域に集中し、大部分のコードは未検証の状況に置かれる。

しかし、この制約は LLM により排除される。Claude Mythos Preview はクローズド・ソースのバイナリから、妥当なソースコードを再構築し、脆弱性の体系的な分析を可能にする。

すでに存在する証拠:エッジデバイスの現実

これまでに述べてきたことは、理論上のリスクではない。すでに、プロプライエタリ・ソフトウェアの一分野であるネットワーク・エッジデバイスで、この露出が現実化している。

ファイアウォール/VPN ゲートウェイ/ロードバランサー/セキュア・アクセスなどのデバイスで、クリティカルなゼロデイ脆弱性が、前例のない規模で発見されている。Verizon 2025 DBIR によると、エッジデバイス脆弱性の悪用は、この 1年で 8倍に増加した。また、脆弱性の公開から実際の悪用までの中央値は “0日” であり、パッチ適用までの中央値は “30日”となっている。

これらのデバイスは、隠蔽によるセキュリティの典型的な姿を示している。インターネットへの公開を前提とする、プロプライエタリ/ファームウェア/クローズドコード/EDR 導入不可で構成される設計である。

コード解析が困難であることが、安全性の一因と考えられていたが、この前提は崩壊している。さらに深刻なのは、2025年に悪用された脆弱性の 40% 以上が、サポート終了製品に存在していた点である。今後において、それらが修正されることはない。

ロングテール:プロプライエタリ・ソフトウェアの領域

エッジデバイスの問題は、前兆に過ぎない。たとえば、病院の輸液ポンプ/MRI/患者モニターなどには、導入以降において更新されていないプロプライエタリ・ファームウェアで動作しているケースがある。

その他にも、電力網/水処理/製造ラインなどを制御する SCADA や PLC は、1980年代に設計されたプロトコルを実装した、プロプライエタリ・ファームウェアで動作している。現代の車両は、膨大な規模のコードで動いている。さまざまな機能が複数の ECU に分散され、それぞれが複雑なサプライチェーンに依存している。

大規模組織では、SAP/Oracle/カスタムアプリが稼働しており、15年〜20年にわたり更新されていないモジュールも存在する。それらの大半は、外部による監査を受けていない。

ソフトウェアを超えて:修正できないプロトコル

ソフトウェアの脆弱性に対しては、パッチの適用が可能である。しかし、プロトコルの脆弱性は仕様自体に存在するため、根本的に異なる問題を引き起こす。つまり、それを修正するためには、プロトコルの置き換えが必要となる。

  • SS7 は認証を持たない設計である。
  • BGP は経路アドバタイズに検証機構を持たない。

Modbus/DNP3/BACnet などの産業用プロトコルは、信頼された閉域環境を前提として設計されている。RFC 8502 に基づく SNMPv3 上の Modbus や、IEC 62351 に基づく DNP3 セキュア認証といった、セキュアなバリアントも理論上は存在するが、実運用での普及は限定的である。

この前提も、AI が変えていく。LLM は仕様書を読み、ネットワーク情報を関連付け、デプロイメント・トポロジーを理解できるため、プロトコル上の新たな脆弱性を発見する必要がない。脅威アクターにとって必要なことは、既知の弱点を特定して大規模に攻撃を仕掛けることだ。攻撃の経済性は、”1人の攻撃者と 1つの標的” から “1つの AI と多数の標的” へと変化している。

ソフトウェアの低層:チップとマイクロコード

それよりも低位の層には、さらに困難な問題が存在する。チップレベルの脆弱性は、設計情報なしに発見できないという前提は誤りである。これまでの 10年間における、主要な CPU の脆弱性は、すべて設計情報なしで発見されている。

  • Spectre や Meltdown はタイミング測定と推論により発見された。
  • Reptar は命令ファジングにより発見された。
  • Downfall はメモリアクセス命令の挙動検証により発見された。

これらは、LLM が得意とする分析領域である。他の領域との決定的な違いは、チップは簡単に修正できないという点である。マイクロコードの更新は限定的であり、シリコンレベルの欠陥を修正するためには新しいチップの再設計が必要となる。

増幅要因:クロスレイヤ攻撃チェーン

各レイヤの脆弱性は、単独であっても問題を引き起こすが、それらを AI が連鎖させることでリスクが増幅する。今後は、レイヤを跨ぐ攻撃が主流となる。

  • プロトコル実装の欠陥がマイクロアーキテクチャのサイドチャネルを誘発する。
  • ファームウェアの脆弱性が暗号鍵を露出させる。
  • ブラウザの脆弱性が、CPU の投機実行バグを利用してサンドボックスを突破する。

いずれも、人間の攻撃者にとって困難なことであるが、AI であれば実現可能である。

何を変えるべきか

Project Glasswing は称賛されるべき出発点であるが、最も可視化された領域だけしか対象としていない。求められるのは、より広範な領域への対応である。前提とすべきは、隠蔽は防御にならないという考え方である。プロプライエタリ・バイナリ/組み込みファームウェア/カスタム・プロトコルを扱う組織は、AI により脆弱性が発見されることを前提にすべきだ。

すでに Glasswing は、AWS/Microsoft/Cisco/Broadcom/NVIDIA/JPMorganといった大手ベンダーと提携し、独自のコードベース・スキャンを実施し、このアプローチの有効性を証明している。しかし、それらの企業は潤沢なセキュリティ予算を持ち、AI 導入のインセンティブが高いフロントランナーたちである。

真のリスクは、より広範な顧客層に存在する。これまで、レビューを受けたことのないコードや、数十年にわたって稼働しているシステム、そして AI セキュリティ企業との関係を持たない膨大な数の組織である。

修正が困難な領域を優先する必要がある。ソフトウェアは短時間で更新可能だが、ファームウェアやプロトコルの更新は時間を要し、シリコンは修正不能である。長期間にわたって残存する脆弱性に重点を置く必要がある。その一方で、クロスレイヤ攻撃への備えが必要である。分断されたセキュリティ体制では、この種の攻撃に対応できない。

喫緊の問題として、エッジデバイスにおける対応の遅延を補完する必要がある。即時パッチ適用が不可能な場合には、侵害を前提とした制御が必要となる。

隠されたコードが安全であるという時代は終わりつつある。2024年〜2026年に発生したエッジデバイスの危機は、その前兆である。Project Glasswing は一部を可視化したに過ぎず、より大規模なリスクが水面下に残されている。