月別アーカイブ: 2026年7月

第2回 CSAジャパン関西支部開発者向け海外最新動向紹介

サイバーレジリエンス法(CRA)が企業の脆弱性管理に及ぼす影響

クラウドセキュリティアライアンス(CSA)は、欧州における「クラウドコンピューティングのためのセキュリティガイダンス」や「クラウドコントロールマトリックス(CSA CCM)」の実装・啓発活動を通じて、欧州連合サイバーセキュリティ庁(ENISA)と連携してきた。

2026年5月18日、CSAラボ・スペースは、「ENISA CVE Root:多国籍企業における二元的な脆弱性ガバナンスの構築」と題するブログ記事を公開した(関連情報:ENISA CVE Root: Dual Vulnerability Governance for Multinationals( https://labs.cloudsecurityalliance.org/research/csa-research-note-enisa-cve-root-dual-governance-20260518-cs/))。CSAラボ・スペースは、コミュニティ内のメンバーやグループが、クラウドセキュリティアライアンス(CSA)と連携して展開したい独立したプロジェクトのために用意されたスペースである。

[要約] 2025年11月、ENISAは、脆弱性識別子「CVE」のプログラムにおいて「管理権限組織(Root)」に昇格し、欧州独自の脆弱性統治レイヤーを確立した。これにより多国籍企業は、従来の米国主導(MITRE/NIST)に加えて欧州主導(ENISA)の「二元的な脆弱性ガバナンス」への対応を迫られる。特に、2026年9月11日に先行適用開始となる「欧州サイバーレジリエンス法(CRA)」により、対象製品のメーカーは悪用された脆弱性を24時間以内にENISAの単一報告プラットフォーム(SRP)へ報告する義務が生じる。企業は、NISTとENISA双方のデータベース(EUVD)を相互参照し、異なる報告期限や脅威コンテキストを調整できる新たな運用ワークフローの構築が必要である。

・[要点1] ENISAの管理権限組織昇格による二元管理の発生
・[要点2] 欧州サイバーレジリエンス法(CRA)による厳格な報告義務
・[要点3] 運用ワークフローとデータベースの統合の必要性

ENISAのCVE管理権限組織への昇格がもたらす変化

本ブログ記事は、以下のような構成になっている。

・背景
・セキュリティ分析
-欧州における並行的な脆弱性管理権限
-欧州脆弱性データベース(EUVD):設計の意図と現在の限界
-CRA(サイバーレジリエンス法)の報告義務:動かせない期限
-文化面および運用面における摩擦
・推奨事項
-即座に講ずべきアクション(即時対応)
-短期的な緩和策
-戦略的検討事項
・CSAリソースとの整合
・参考文献

本ブログ記事によると、従来のCVEプログラムは、クラウドセキュリティアライアンスと連携している米国MITREを頂点とする階層構造であり、EUの規制や制度的枠組みを反映していなかったため、米欧双方の規制に対応する企業にとってガバナンスの不一致が課題となっていたとしている。

このような状況に対しENISAは、2024年1月、まず欧州のコンピュータセキュリティインシデント対応チーム(CSIRT)等が発見・報告した脆弱性を対象とするCVE採番機関(CNA)に認定された。並行してNIS2指令に基づき、米国立脆弱性データベース(NVD)を補完する「欧州脆弱性データベース(EUVD)」の開発を進め、2025年5月に完全運用を開始して技術的基盤を整えた。そして2025年11月、ENISAは単なる採番機関を超え、傘下のCNAを育成・監督する「Root CNA」へと昇格した。これにより、欧州の国家機関やCSIRTネットワークに属するCNAの監督権限がMITREからENISAへと移管され、欧州独自の脆弱性管理体制が確立された。

さらにENISAは、意思決定機関であるCVEプログラム理事会への参画を見据え、最高位の「TL-Root CNA」への昇格も視野に入れている。この構造的変化は、MITREが全体統括を維持しつつも、EU市場で活動する多国籍企業やグローバルITベンダーの脆弱性管理プロセスに直接的な影響を与えている。

欧米双方で事業展開する企業に求められる脆弱性の二元管理

CVEエコシステムの権限階層は、フラットではなく「階層レイヤー構造」と捉えるのが正確である。最上位のTL-Rootである米国MITREが全体を統括し、その下にCISAやJPCERT/CC、そして新たに加わったENISAなどの「プログラムレベルRoot」が位置し、各ドメインやベンダー固有の「CNA」、さらに「Sub-CNA」を監督する仕組みによって、グローバルな規模拡大と識別子の一貫管理を両立している。

ENISAのRoot昇格は、この構造に欧州独自のレイヤーを挿入した。これにより、ENISAのスコープ内にある欧州のCNA(全510組織中90以上が該当)は、MITREからENISA Rootへ自発的に移管できるようになった。すでに数組織が移行を完了または新規加入しており、今後移行が進むにつれ、各CNAのエスカレーションや調整ワークフローは、MITREのデフォルト基準ではなく、欧州の規制カレンダーやENISAの運用ペースに同期していくと予想される。

このような変化は多国籍企業に「構造的な非対称性」をもたらす。米欧双方に導入されている製品で脆弱性が発生した場合、CVE識別子自体は共通であるものの、管理プロセスはMITRE主導とENISA主導という2つの異なるガバナンスチェーンに同時並行で組み込まれる。結果として、企業の主要拠点の位置や影響を受ける加盟国に応じて、開示義務、メタデータの付与、法的な規制通知などの対応が二分化されることになる。

ENISAが開発した「欧州脆弱性データベース(EUVD)」は、米国のNIST NVDと同様にCVEレコードを集約し、CVSSスコアや欧州独自の脅威インテリジェンス等を付加する仕組みである。NIS2指令下の組織にとっては、EUの通知義務やENISAの既知の悪用された脆弱性(KEV)リストに直結する規制上の公式な基準となる。

しかし、現在の運用上、EUVDは実績のあるグローバルな情報源に比べ大幅な網羅性の遅れが指摘されている。本ブログの分析によれば、主要APIにおいてNVD等より5万件以上もCVEデータが不足しており、企業のセキュリティチームが単一の情報源として依存するには不十分だと指摘されている。そのため、EUVDが成熟するまでは、NVDとEUVDの双方を照合する「デュアル・データベースモデル」の採用が実務的に評価されている。

この二元管理は運用に複雑性をもたらすことになる。欧州の研究者が報告した脆弱性はNVDと異なるメタデータが付与される可能性があり、欧州特有の脅威を反映した悪用フラグは米CISAのKEVカタログとも乖離する可能性がある。結果として、NVDで低優先度とされる脆弱性が、EUVDでは欧州インフラへの攻撃を理由に高緊急度と評価される事態も起こるため、セキュリティチームはこれら乖離したシグナルを統合・調整できるツールやプロセスを備える必要があるとしている。

欧州サイバーレジリエンス法(CRA)とNIS2による厳格な報告義務

しかしながら、欧米双方で事業展開する企業にとって最も差し迫った課題は、ENISAのCVE Root昇格そのものよりも、同機関が運営を担う欧州サイバーレジリエンス法(CRA)の通知フレームワークへの対応である。CRA第14条に基づき、EU市場にハードウェア、ソフトウェア、接続サービスなどの「デジタル要素を持つ製品」を販売する製造企業は、2026年9月11日より、以下のような期限設定で、悪用された脆弱性や重大な影響を及ぼすセキュリティインシデントを報告する法的義務を負う。

・24時間以内: 悪用された脆弱性を覚知した後の「早期警戒通知」
・72時間以内: 詳細を網羅した「完全な通知」
・14日以内: 是正措置(パッチ等)が利用可能になった後の「最終報告」

さらにENISAは、これらの通知を受け付ける「単一報告プラットフォーム(SRP)」を構築・運営する任務を負っている。提出された報告は、製造元がEU域内に置く主要拠点の国における「国家CSIRTコーディネーター」およびENISAに、同時で共有される。

報告を受け取った国家CSIRTは、その製品が流通している他のEU加盟国のCSIRTや、関連する市場監視当局に対して遅滞なく情報を共有・分散する義務がある。ただし、特に機微な報告についてはセキュリティ上の理由から初期の共有を保留することが認められており、その場合もENISAに通知され、リスクがシステム全体に及ぶと判断されれば、ENISAの権限でより広範な共有を推奨することができる。

EU域内に「製品の製造基盤」と「自社のインフラ」の両方を持つ多国籍企業にとって、CRAの報告義務と、並行して走る「ネットワークおよび情報システム指令2(NIS2指令)」(第23条)の要件との相互作用は、運用の複雑さをさらに増大させることになる。

NIS2では、重要主体に対し、重大なインシデントの発生から24時間以内の初期報告と72時間以内の包括的評価を求めており、このタイムラインはCRAの製品脆弱性報告の時計とほぼ重なり合う。企業は発生した事象が、CRA(製品レベルの脆弱性、SRP経由でENISAへ)に該当するのか、NIS2(組織レベルのインシデント、加盟国の指定CSIRT経由)に該当するのか、あるいはその双方に同時に該当するのかを即座に判断し、どちらの報告チェーンも遅延させない仕組みを確立しなければならない。

これら2つの法的枠組みは、以下の通り、それぞれ独立していながらも相互に補完し合う強力なペナルティ構造を敷いている。

・NIS2指令:重要主体に対し、最高1,000万ユーロ、またはグローバル年間総売上高の2%のいずれか高い方の制裁金。
・サイバーレジリエンス法(CRA):核心的義務(第14条の報告義務を含む)に違反した場合、最高1,500万ユーロ、またはグローバル年間総売上高の2.5%のいずれか高い方の制裁金。

この極めて高いペナルティの上限は、欧州一般データ保護規則(GDPR)の構造を模したものであり、EUの立法府が脆弱性の開示遵守を、単なる管理上の手続きではなく、最高レベルの規制義務として重く捉えている明確なシグナルと言えるとしている。

文化面および運用面の摩擦への対応がグローバル脆弱性管理の課題に

ENISAの権限昇格は、単なる組織構造や法規制の次元を超えて、EUが「脆弱性開示」という行為そのものをどのように捉えるかという、現在進行形の大きな文化的シフト(意識改革)を反映している。これに伴い、EU市場に関わるすべての組織は、その姿勢の根本的な転換を迫られることになる。

これまで多くの伝統的な産業セクターにおいて、脆弱性の開示は「防御的」あるいは「消極的」に扱われてきた。企業の法務チームは、企業のレピュテーションリスクや法的責任・損害賠償リスクへの懸念から、セキュリティ上の欠陥を公に認めることに対して極めて慎重であり、結果として形式的な脆弱性開示ポリシー(VDP)すら存在しないか、あっても形骸化しているケースが一般的であった。

しかし、NIS2指令および欧州サイバーレジリエンス法(CRA)の登場によって、この構図は一変した。これらの法制により、「協調的な脆弱性開示(CVD)」を、単なる推奨されるベストプラクティスから「明確な法的義務」へと昇格させた。特にCRAにおいては、附属書I(Annex I)に規定される必須のサイバーセキュリティ要件の一部として、製品の製造元に対し「協調的な脆弱性開示に関するポリシーを策定し、確実に実施・強制すること」を明確に義務付けている。

ENISAが2026年4月に発表した見解(関連情報:New CVE Numbering Authorities Under ENISA Root(https://www.enisa.europa.eu/news/new-cve-numbering-authorities-under-enisa-root))の中でも、この文化的・組織的な移行には相応の時間がかかることが認められている。特に、これまでセキュリティ研究者(ホワイトハッカーなど)のコミュニティと密接な関わりを持ってこなかったセクターにおいては、そのギャップが顕著になっている。具体的には、金融サービス、医療、産業用制御システム(ICS/OT環境)、そしてその他の重要インフラ分野が該当する。これらのセクターに属する企業の多くは、NIS2指令において「重要主体(必須または重要な組織)」に指定されており、インフラ運用者としての義務を負うと同時に、製品のサプライヤーとしてCRAの適用も受けるという、二重の網をかけられた状態にある。

これらの組織にとって、CRAが求める運用上の開示要件を満たすためには、単にITシステムや手順書をアップデートするだけでは不十分である。社内におけるセキュリティインシデントの上層部への報告や承認のプロセス自体に、本質的な変革を起こす必要がある。

従来のトリアージ(優先度判定)やインシデント対応のワークフローでは、外部への一切の通知・開示を行う前に、まず法務チームや広報(PR)チームによる綿密なリーガルチェックおよび対外コミュニケーションのレビューを挟むことが一般的であり、ここに多くの時間が費やされていた。しかしCRAの体制下では、脆弱性を覚知してから「24時間以内」に、ENISAのプラットフォームへ第一報(早期警戒通知)を送信完了していなければならない。

したがって企業は、従来の「リスクを隠蔽・遅延させる承認プロセス」を完全に排し、法的リスクを管理しつつも、24時間の時間制限内に自動的かつ確実にENISAへの通知を出力できる、極めて迅速でダイレクトな内部トリアージ体制を再設計することが求められるとしている。

欧米進出企業の運用ワークフローと脆弱性データベースの統合に向けて

最後に本ブログ記事では、多国籍企業が2026年9月の欧州サイバーレジリエンス法(CRA)先行適用までに講ずべき対策と戦略の推奨事項として、以下のように提示している。

・即時対応策
EU市場に上市している全製品の棚卸しを行い、SaaSなどの対象範囲を確認する。報告先となる国家CSIRTを決定するため、EU域内の「主要拠点」を早期に確定させる必要がある。また、脆弱性管理ツールを改修し、網羅性に遅れのあるEUVDとNVDの双方を相互参照して、データの乖離を検知できる体制を整える。

・短期的な緩和策
24時間以内の早期警戒通知に対応できるよう、従来の数日かかる承認フローを排したCRA準拠の協調的脆弱性開示ポリシー(VDP)を策定する。インシデント対応の手順書を更新し、NIS2(組織レベル)とCRA(製品レベル)の報告基準を明確に区別させ、法務や広報、セキュリティ部門間で承認権限を事前に合意しておく。また、欧州ベンダーのCNAがENISA Rootへ移管するかどうかも注視する。

・戦略的検討事項
EUVDの成長に伴い依存度を高める計画を策定する。さらに、ENISAが最高位の「TL-Root」へ昇格すれば、世界の脆弱性管理の基準自体が欧州主導で変化する可能性があるため、長期的な動向を追跡する必要がある。

なお、ENISAのCVE Root昇格と欧州の脆弱性ガバナンスの拡大に関しては、クラウドセキュリティアライアンスの基盤的なフレームワークと直接的に連動している。具体的には、以下の通りである。

・AIコントロールマトリクス(AICM):
欧州サイバーレジリエンス法(CRA)の適用で新たなコンプライアンスの課題が生じやすい「AI製品やサービス」を対象に、サプライチェーンの整合性や脆弱性管理の管理策を提供する。脆弱性開示義務がAIモデルやインフラに拡大する中、AICMはCRAの技術要件とCSAのAIセキュリティ基準の双方を満たしているかを監査する構造的基盤となる。

・STAR(Security Trust Assurance and Risk)プログラム:
NIS2指令に準拠した管理策をカバーしており、CRAの適合性を証明する第三者保証メカニズムとしての活用が評価されている。企業はSTARレジストリを参照することで、CRA第14条の開示要件を満たす脆弱性管理の成熟度を確認できる。

・ゼロトラストガイダンス:
「侵入を前提(Assume Breach)」とし、継続的な検証を行う原則は、CRAが求める「後手に回らない積極的な脆弱性監視」に合致し、24時間・72時間以内の迅速な報告の実現を支える。

CSAジャパン関西支部メンバー
DevSecOps/サーバーレスWGリーダー
笹原英司

フロンティアAI脅威対応はセキュリティ現場に追い風

2026年7月26日
SaaSセキュリティリーグ 諸角昌宏

第7回SaaSセキュリティリーグ会議

「SaaSセキュリティリーグ」は、SaaSユーザー企業の実務者同士で情報交換を行う取り組みである。SaaS管理者やセキュリティ担当者を横串でつなぎ、知見交換を行うことで、セキュリティレベル向上に貢献していくことを目的としている。ここでは、「SaaSセキュリティリーグ」が行った第7回会議の内容をまとめて公開する。なお、今回は会議の内容をベースに情報セキュリティの基本対策について筆者の考えとしてまとめた。

議論の概要

フロンティアAI(高性能AI)がシステムの脆弱性を短期間・大量に自動発見する能力を持ち始め、サイバー攻撃の質と速度が根本的に変容しつつある。大量パッチが一斉提供される事態を想定した早期対応が急務と判断。金融庁と日本銀行が連名で金融機関等に緊急要請を発出した(https://www.fsa.go.jp/news/r7/sonota/20260522-5/01.pdf)。
今回のSaaSセキュリティリーグでは、この要請の内容をもとに、フロンティアAI脅威対応を検討する情報システム部門の方々でディスカッションを行った。

金融庁と日本銀行による要請の概要

以下、9項目について、おおむね1か月以内に対応することが求められた。

  1. 経営課題として位置づけ
    フロンティアAIへの対応を経営上の優先事項とし、経営層が直接指揮・関与する体制を構築する。IT・セキュリティ部門任せにせず、経営トップが全社的課題として主導する。CIO・CISOら経営層が対応方針の策定から状況把握まで継続的に関与すること。
  2. 優先対象システムの特定
    社会的影響が大きいサービス・システムを優先リストアップし、対応順位を明確化する。リソース拡充には限界があるため、リスクベースで優先度を決める。特にインターネットバンキング等、重要業務を支える外部公開システムを最優先とし、共同運営システムでは責任分担を事前に明確化する。
  3. 技術的負債の解消
    優先対象のEOS製品・脆弱構成・サポート切れソフトウェアを洗い出し排除する。2で特定したシステムのソフトウェア・ネットワーク構成を再確認し、脆弱性発見時に即座に対象を特定できる状態にする。不要ポートの閉塞、特権IDの削除、サポート終了製品の更新なども実施。
  4. パッチ適用人員の確保
    大量パッチ適用を短期間で処理できる人的リソースを追加・再配置する。他部門からの応援も含め人員を増強し、ベンダー側のリソース確保状況も事前に確認する。脆弱性の優先度評価体制も併せて強化する。
  5. ベンダー契約の確認
    保守契約のSLA・パッチ提供範囲・対応時間を確認し不備があれば改定交渉する。パッチ適用が契約範囲・役割分担に含まれているか、夜間・休日対応が可能か、SLA/SLOが遵守できるリソースがベンダー側にあるかを確認。ひっ迫時の絞り込みやリスク受容プロセスも整備する。
  6. リスクベースのパッチ運用
    CVSSスコア一辺倒を脱却。自社システムへの影響度・攻撃可能性を加味して優先付けする。CVSSスコアだけでなく攻撃成立の蓋然性も踏まえて優先順位を判断する。パッチ適用前テストについても、障害リスクと未適用リスクを比較し、合理的な縮小を検討する。
  7. 多層防御の強化
    パッチ適用以外の手段(WAF・ネットワーク分離・特権アクセス制限等)も並行強化する。パッチ適用が困難・遅延する場合、WAFによる仮想パッチ、ボット対策、ネットワーク分離、特権IDへの多要素認証、EDR等の多層防御で補う。これらは恒久策ではなく、残存リスクを踏まえたリスク受容手続が必要。
  8. BCP・代替手段の整備
    優先サービスの停止を前提にしたBCPを見直し、代替手段・縮退運転の手順を整備する。防御が破られる可能性を前提に、能動的なシステム停止の判断基準・手順をあらかじめ検討。BCPの有効性、顧客対応手順、緊急連絡体制も点検する。テスト縮小に伴う障害増加やサードパーティ製品の停止リスクにも備える。
  9. 外部連携の強化
    NISC・金融ISAC等との情報共有体制を維持・強化し、早期警戒情報を活用する。金融ISAC、業界団体、当局等から情報を積極的に収集する。自組織の対応状況も共助コミュニティで共有し、業界全体の強靭性向上に貢献する。

ディスカッションポイント

ここでは、SaaSセキュリティリーグでディスカッションされた内容をリストアップする。

  • 9項目の対策は、全体的に当たり前の対策を行うことを求めている。新しく何かやっていくということではないし、特別に何かやるということではない。今まで手が回っていなかったことを、きちんと実行していくという認識である。
  • パッチ適用は各オーナーの対応となっている。システム管理者の判断により、パッチにどのように対応するかが決まっている。したがって、ミュトスの前後で特に何も変わってない。
  • 経営者は、ミュトスという脅威があるが具体的にどのような対策が必要なのかは理解できていない。逆に、アサヒビール、KADOKAWA、ニチレイ等の事象を脅威ベースで捉え、積極的に対策を求めている。これらの事象は、BCPあるいはレジリエンスの問題としてとらえやすいため、そのための対策を求めている。
  • 9項目の要請は、基本的にセキュリティハイジーンの強化を求めている。セキュリティハイジーンは、必要性は分かっていてもなかなか実施できていないところであり、このような要請により業界の認識が高まって行けば良いと考えられる。セキュリティ部門にとっては追い風と言えるかもしれない。
  • 経産省も、所管する重要インフラ事業者に対して要請をしている(https://www.nikkei.com/article/DGXZQOUA302PI0Q6A430C2000000/)。重要インフラからセキュリティハイジーンの強化が徹底されて、それがさらに一般企業に落ちてくるような流れができると、情報セキュリティのレベルの底上げにつながることが期待できる。
  • 金融ISACでは、様々な角度から情報セキュリティの検討が進められている。この情報が、一般にも広められうようなことができると全体的な底上げにつながるのではないだろうか。

まとめ

ここからは、ディスカッションの内容をベースに筆者としての見解として整理してみたい。

対策9項目は、経営者と現場でなぜ十分に取り組まれてこなかったのか?

9項目について、何故対応が進まないかについて整理すると以下のようになると考えられる。あくまで、筆者としての意見であり、すべての組織に通じるものではないことを述べておく。

  1. 経営課題として位置づけ
    経営者:具体的インシデント事例には前向きに動くが、抽象的な脅威にはなかなか動かない。「守れて当たり前」の話にお金や労力をかけたがらない。
    現場: 難しい技術の話を偉い人に分かるように説明するのが大変。言われても本気で取り合ってもらえないことが多かった。
  2. 優先対象システムの特定
    経営者: 「このシステムは後回し」とはっきり言うと、後で問題が起きたときに責められる。だから決めたがらない。
    現場: 自分の部署のシステムが「後回し」にされると、予算や人員を減らされる前触れに見えて反発が起きる。
  3. 技術的負債の解消
    経営者: 今動いているものに手を入れる投資は「無駄遣い」に見えやすく、他のことにお金を使いたがる。
    現場: 古いシステムほど詳しい人がいなくなっていて、触ると壊れる不安が大きく、みんな避けてきた。
  4. パッチ適用人員の確保
    経営者: セキュリティはお金を生まない部門なので、人を増やすことに二の足を踏みがち。
    現場: パッチ適用は各オーナーが対応している状況で現状特に問題ない。適用スピードを上げた場合のリソース不足への対応は今後の検討課題。
  5. ベンダー契約の確認
    経営者: 契約を見直すと値上げ交渉になりやすく、コストが増えるのを嫌う。
    現場: 法務や調達を巻き込む面倒な手続きが必要で、今の契約の甘さがバレて気まずい思いをすることもあった。
  6. リスクベースのパッチ運用
    経営者: テストを省いて後で障害が起きたら自分の判断ミスになるので、はっきり決めたがらない。
    現場: 品質を落とす判断は技術者として抵抗があり、過去に急いで直して逆に壊れた経験もあって慎重になっている。
  7. 多層防御の強化
    経営者: 「保険」のような投資で成果が見えにくく、後回しにされやすい。
    現場: 導入すると誤警報が増えたり、既存の仕組みと合わなかったり、利用者から「面倒くさい」と文句が出たりして負担が増える。
  8. BCP・代替手段の整備
    経営者: まだ実害が出ていない段階で自ら止める予防的な判断は、結果的に何も起きなければ「過剰対応だった」と批判されかねず、様子見をして先送りしたい。
    現場: 「誰が止める判断をするのか」がはっきりしないまま、責任だけ押し付けられるのが怖い。
  9. 外部連携の強化
    経営者: 外部との情報発信・連携は、規制当局から明確に要請されない限り動き出さない受け身の姿勢が実情。自ら進んで他業界・他組織に知見を発信していく発想が弱い。
    現場: 金融ISAC等の既存コミュニティ内での情報交換自体は行われているが、そこで得た知見を組織の枠を超えて広く共有・発信するところまでは踏み込めていない。

まとめると、効果が目に見えにくい、何かあったときの責任が特定の人にのしかかる、古いシステムや知識が特定の人に頼りきりになっている、という3つの構造的な事情が根っこにあるものと考える。

具体的な対策例

ここでは、9項目の要請に対する筆者が考える代表的な実装例として以下を上げる。今後の対策、検討の参考としていただきたい。

  1. 経営課題として位置づけ
    経営会議・取締役会での定例報告化、経営トップを本部長とする緊急対策本部の設置、CISO直轄タスクフォースの編成、対応予算の緊急予備枠確保。
  2. 優先対象システムの特定
    外部公開資産の棚卸し(アタックサーフェス管理)、資産管理台帳(CMDB)の整備、ビジネスインパクト分析による重要度ランク付け、ネット取引・決済・顧客DB等を最優先リスト化、共同運営システムの責任分担を契約書で明文化。
  3. 技術的負債の解消
    ソフトウェア部品管理表(SBOM)の整備、不要なポート・サービスの洗い出しと閉塞、特権IDの棚卸しと削除、EOL(サポート終了)製品のリストアップとアップグレード計画策定。
  4. パッチ適用人員の確保
    脆弱性対応の臨時専任チーム編成、他部門からの応援ローテーション、MSSPの活用拡大、ベンダーへの増員要請と体制確認。
  5. ベンダー契約の確認
    維持保守契約のパッチ対応条項レビュー、夜間・休日対応のSLA明記、複数組織で同時発生した場合の代替対応策の検討、クラウド事業者からの報告体制の確認。
  6. リスクベースのパッチ適用
    CVSSに加えEPSS(悪用予測スコア)やKEV(実際に悪用済みの脆弱性リスト)を併用した優先順位付け、深刻度別のパッチ適用期限設定(重大:24時間以内、高:72時間以内など)、システムの重要度に応じたテスト範囲の簡略化ルール策定。
  7. 多層防御の強化
    クラウド型WAFによる仮想パッチ、EDR/XDRの導入拡大、特権アカウントへの多要素認証必須化、ネットワークセグメンテーション、ボット対策(レート制限等)の導入。
  8. BCP・代替手段の整備
    BCP/DRの机上訓練実施、能動的サービス停止の判断基準・承認フローのマニュアル化、顧客向け緊急連絡テンプレートの事前準備、緊急時エスカレーション体制の整備。
  9. 外部連携の強化
    ISACへの加入・積極参加、業界内の脅威インテリジェンス共有会合への参加、IPA等からの情報の定期収集、自組織の対応事例の匿名化共有。

まとめのまとめ

金融機関等への緊急要請の中で触れられている「AI性能の高度化を踏まえたサイバーセキュリティ対策の強化について ~Project YATA-Shield~」では、「重要インフラ事業者等においては、高性能AIの悪用リスクに備えたサイバーセキュリティ対策の実施や、より高速かつ大量に脆弱性が発見・修正されることを前提とした対策強化を行うとともに、ベンダ等においては、高性能AIの活用を含め、より早期の脆弱性の発見・修正等の実施」を求めている。あくまで重要インフラ・防衛産業に限定された要請であるが、筆者は、一般企業へは①サプライチェーン圧力、②ベンダー主導の標準化、③インシデント報道による自主対応という経路で広がる可能性があると考える。

このような要請が一般企業に広まるかどうかに関わらず、情報セキュリティ部門にとって、この緊急要請の9項目はいままでやりたくてもなかなかできなかった基本対策やセキュリティハイジーンであるといえる。今回の要請は、これまで優先順位を上げにくかった基本対策を経営課題として位置付ける契機となり得る。セキュリティの基本対策の整備から、継続的に改善するセキュリティハイジーンに取り組むことで、組織のセキュリティレベルを大きく向上させることができるチャンスと捉えることが重要であると考える。

以上

BioShocking:フィクション設定によるAIブラウザのガードレール突破 ~ 間接的プロンプトインジェクションによるエージェント型ブラウザからの認証情報窃取

2026年7月15日
AIWGメンバー 諸角昌宏

本ブログは、CSAI FoundationとCSA本部が2026年7月8日に公開したリサーチノート「BioShocking: Fictional Framing Breaks AI Browser Guardrails」の内容を、日本語で要約したものである。本ブログの内容と原文とで差異があった場合には原文が優先される。

1. 要点

セキュリティ企業LayerXの研究者が、「BioShocking」と名付けた手法を公表した。これは、AIブラウザの「エージェントモード」に対してフィクションのゲーム設定を装った文脈を与えることでガードレールによる安全判断を迂回させ、ユーザーのログイン済み認証情報を持ち出させる攻撃手法である。

検証対象となった6つのエージェント型ブラウザ・拡張機能(OpenAIのChatGPT Atlas、PerplexityのComet、AnthropicのClaude Chrome拡張機能、Fellou、Genspark Browser、Sigma Browser)のすべての製品で概念実証(PoC)による攻撃成立が確認された。

この攻撃は攻撃者による追加のコード実行や脆弱性悪用を必要としない、自然言語による文脈操作のみで成立する。そのため、既知の悪意あるコードやシグネチャを検知する従来型のコンテンツフィルタリングやマルウェアスキャンでは、この手法を検知することは困難とみられる。

ベンダーの対応は一貫していない。OpenAIはChatGPT Atlasを修正済み、AnthropicはClaude Chrome拡張機能への修正を試みたが回避手法が依然として報告されている、Perplexityは対策を講じずに報告をクローズ、残る3社(Fellou、Genspark、Sigma)は開示に対して一切応答していない。 CSAは、この問題を個別実装ではなくアーキテクチャ上の課題と評価している。エージェント型ブラウザは、メール、コードリポジトリ、クラウドコンソール、パスワードマネージャーなど、ユーザーの認証済みセッション状態を引き継ぐ一方で、その認証済みコンテキストを、攻撃者が自由に書き換え可能な周囲の会話コンテキストよりも機密性が高いものとして扱う仕組みを、一般的に備えていない。

2. 背景

エージェント型AIブラウザ、つまりLLMがWebページを操作し、リンクをクリックし、フォームに入力し、ユーザーに代わってページ内容を読み取る製品は、この1年で実験的機能から主要AIベンダーの正式製品へと移行した。ChatGPT Atlas、Perplexity Comet、Anthropicの Claude for Chrome拡張機能はいずれも、単にユーザーが読み込んだページを要約するだけでなく、有効な認証済みブラウザセッション内でモデルが自律的に行動する権限を与えている。

この能力拡張こそが、間接的プロンプトインジェクションを危険にしている要因である。モデルはもはやユーザーが貼り付けたテキストについて質問に答えるだけの存在ではなく、リンクの追跡、フォームの送信、非公開データの読み取りといった、実質的な影響を伴う判断を、訪問先のあらゆるページ上に存在するテキスト(攻撃者が完全に制御するページを含む)に基づいて行っている。

LayerXの主任研究員Roy Paz氏は、この手法をビデオゲーム『BioShock』にちなんで「BioShocking」と命名した。同作では、プレイヤーキャラクターが「Would you kindly」という言葉で始まる指示に無条件で従うよう条件付けされており、それらの指示が単にゲームの内部ロジックの一部にすぎないと、本人が気づかぬまま信じ込まされている。

Paz氏の見立てでは、攻撃者がモデルに対して「フィクションあるいはルールが変更された文脈に入った」と信じ込ませることができれば、モデルは現実世界の安全訓練ではなく、そのフィクション文脈のロジックを適用してしまう可能性がある。この傾向は、検証対象となった6つのブラウザすべてにおいて、実際の認証情報を用いて実システムに対して操作している最中であっても確認された。LayerXは2025年10月から2026年1月にかけて影響を受ける6社に開示を行い、2026年6月下旬に技術詳細を公表。The Hacker News、Malwarebytes、SecurityWeekなど複数のメディアが2026年7月上旬にかけて追随報道を行った。

これは、悪意ある指示がWebページや文書、コードコメントなど、モデルが処理するコンテンツの中に隠され、ユーザーが直接入力したものではない「間接的プロンプトインジェクション」として広く議論されている弱点に合致するものである。CSAの見解では、BioShockingが注目に値するのは注入経路そのものよりも、隠しテキストや難読化されたUnicode、エンコードされたペイロードを一切用いない「純粋な物語的フレーミング」だけで、LayerXが検証したすべてのエージェント型ブラウザのガードレールを突破できることを示した点にある。 この違いは防御側にとって重要な意味を持つ。間接的プロンプトインジェクション対策に関する公開議論の多くは、モデルに届く前のページコンテンツを無害化・検知すること(隠しテキストのフィルタリング、異常な書式の除去、既知のジェイルブレイク表現の検出)に焦点を当ててきた。しかしBioShockingのパズルページにはそうした兆候が一切なく、すべての指示は平文で可視、かつ一見ゲームの内容として自然なテキストだった。したがってLayerXが明らかにした脆弱性は、コンテンツフィルタリングよりも下流、すなわち「認証済みコンテキストの中で、その要求を実行してよいか」というエージェント自身の判断に存在しており、これがより優れたコンテンツフィルタだけでは解決できない理由である。

3. セキュリティ分析

LayerXのPoCは、BioShock風のディストピア的パズルゲームを模したWebページを作成し、エージェントモードで動作するAIエージェントにゲームへの参加を促す形で構成された。序盤のパズルでは意図的に客観的に誤った回答(例:「2+2=5」を正解とする)を報酬付けし、そのセッション内でエージェントに「外の世界の通常のルールはこのゲーム内では適用されない」と受け入れさせるよう仕向けた。

この逆転ロジックをエージェントが受け入れた後、最終段階のパズルは、ユーザーが既に認証済みのGitHubリポジトリ内の認証情報(例:SSH鍵)のような機密情報を取得し、それを「解答」として報告するよう指示するものだった。逆転ロジックのフレーミングにセッションが誘導された結果、エージェントは通常であれば拒否するはずの、機密認証情報の抽出・送信という要求にゲーム外の文脈では応じないはずの要求に従ってしまった。

この攻撃連鎖は、現行のエージェント型ブラウザのアーキテクチャにおける3つの複合的な弱点を露呈している。

第一に、これらのエージェントは一般に、メール、ソースコードリポジトリ、クラウドダッシュボード、パスワードマネージャーなど、ユーザーの認証済みセッション全体を、人間ではなくエージェント自身が機密性の高い読み取り・操作を開始する際に、多くの製品では追加確認なしに引き継いでいる。

第二に、モデルの安全訓練は文脈の再フレーミングに対して脆弱であるとみられる。検証された6システムのいずれも、フィクションやゲーム的な設定であっても、実際に有効な認証済みデータに触れる操作である限り、現実世界の結果が停止されるわけではないことを認識できなかった。

第三に、この攻撃全体が通常の外見のページコンテンツに埋め込まれた普通の自然言語で表現されているため、Webセキュリティツールが一般的に依拠するパターンマッチングやマルウェアシグネチャによる防御を回避してしまう。最終的な情報持ち出しの段階まで、悪意あるコードも、注入スクリプトも、異常なネットワーク要求も存在しない。

CSAの見解では、ベンダー対応のばらつきは、エージェント型ブラウザ市場全体でガードレール実装の成熟度に大きな差があることを示唆している。LayerXの報告によれば、OpenAIはChatGPT Atlasに有効な修正を提供した一方、AnthropicによるClaude Chrome拡張機能への修正は回避手法を軽減したものの完全には排除できておらず、Perplexityは修正を実施せずにCometに関する報告をクローズした。小規模な新興ベンダーであるFellou、Genspark、Sigmaは、公表時点でLayerXの開示に一切応答していない。 この差は重要である。なぜなら、これらの製品は「ユーザーに代わって認証済みセッション内で行動できるエージェント」という同一の価値提案で競合しており、特定ベンダーのPoCが修正されていても、根本的なアーキテクチャ上の露出はカテゴリ全体で共有されている可能性が高いためである。

4. ベンダー別 開示対応・修正状況

製品ベンダー開示への対応修正状況
ChatGPT AtlasOpenAI受領し修正を実施LayerXが修正を確認済み
CometPerplexity AI報告をクローズ(未対応)修正未実施
Claude for ChromeAnthropic修正を試行回避手法が依然として存在するとの報告
FellouFellou無応答不明
Genspark BrowserGenspark無応答不明
Sigma BrowserSigmabrowser OÜ無応答不明

この対応状況の広がりは、単一ベンダーの修正内容の発表だけでは、この攻撃クラス全体が業界横断的に解決済みであるとみなせない理由を示している。各製品は、認証済みセッションへの広範かつ常時アクセスをエージェントに付与するという同一の一般的パターンの上に、それぞれ独自のガードレールロジックを実装しているにすぎない。

5. BioShockingが示すもの・示さないもの

BioShockingは、セキュリティ研究企業によって責任ある形で開示された概念実証であり、実際のユーザーに対して野放しで悪用が観測された攻撃ではない。LayerXは攻撃コードを公開していない。

この手法は、エージェントが自律的なブラウジング権限を既に付与された明示的な「エージェントモード」で動作し、かつ認証済みセッションが既に確立されていることを前提としている。すなわち、認証そのものを回避する手法ではなく、機密性の高いアカウントにエージェント権限を付与していないユーザーは、この特定の手法によるリスクにはさらされない。 それでもリスクが重大である理由は、エージェントモードの採用こそが市場が向かっている方向であること、そしてこの攻撃が、ユーザーのエージェントが自律的に閲覧している最中にたまたま訪問するWebページ以上の高度な仕掛けを何ら必要としないことにある。

BioShockingは、LLMそのものの脆弱性というよりも、LLMに認証済みブラウザ操作権限を付与したエージェントアーキテクチャにおける認可境界(authorization boundary)の設計課題を示した研究である。

6. 推奨事項

6.1 即時対応

エージェントモードや自律ブラウジング機能を有効化している組織のセキュリティチームは、ChatGPT Atlas、Comet、Claude for Chromeなど、対象となる製品において現在エージェントが常時アクセス可能な認証済みアカウント・セッションを洗い出すべきである。ソースコードリポジトリ、パスワードマネージャー、管理コンソールは、エージェントモードが監督なしに立ち入るべきではない高機密コンテキストとして扱う必要がある。各ベンダーに対し、BioShocking固有の修正、および文脈再フレーミング攻撃全般への対策が実装済みかどうかを確認すべきである。ベンダーが開示に応答していない、または修正の確認が取れていない場合は、機密性の高い認証済みセッションに対するエージェントモードのブラウジングを、ベンダーの対応状況が明確になるまで無効化することを検討すべきである。

6.2 短期的な緩和策

組織は、セッション全体に対する包括的なエージェントモード権限を付与するのではなく、認証情報・ソースコード・金融システムに触れる認証済みセッション内での読み取り・操作の前に、明示的な人間による都度確認を必須とすべきである。大規模にエージェント型ブラウザを導入する企業は、人間ユーザーアカウントやサービスアカウントに既に適用している最小権限の原則に倣い、エージェントがアクセス可能なドメイン・アプリケーション・認証済みセッションをできる限り狭く限定すべきである。この種の攻撃はマルウェアシグネチャを残さない一方で、観測可能な異常な操作シーケンス(エージェントが想定外のドメインにセッション中に移動する、認証情報ストアの読み取りを試みるなど)を生じさせるため、セキュリティチームはそうした異常挙動の監視体制も構築すべきである。

6.3 戦略的考察

BioShocking系攻撃に対する恒久的な解決策は、モデルレベルのパッチではなくアーキテクチャ上の対応である。エージェントシステムには、攻撃者が自由に操作できる会話・タスクの文脈と、エージェントに許可される認証済みの高権限操作との間に、強固な認可境界が必要であり、会話内でのいかなる物語的な再フレーミングも、それ単独では機密操作を認可できない構造にすべきである。エージェント型ブラウザを開発するベンダーは、「エージェントが通常のルールは適用されないと思い込んでいる」こと自体を、単に内容を評価すべき一つの指示としてではなく、人間へのエスカレーションを要する検知可能なシグナルとして扱うべきである。エージェント型AIブラウジング製品を評価・調達する企業は、LayerXが記録した6製品中6製品という失敗率が、特定ベンダーに限定された実装上の欠陥ではなく、現時点でカテゴリ全体に及ぶ構造的な課題であることを踏まえ、文脈操作への耐性をベンダーのセキュリティ評価基準に組み込むべきである。

7. CSA関連リソースとの整合性

CSAの「Identity and Access Gaps in the Age of Autonomous AI」は、本リサーチノートが取り上げるアーキテクチャ上のパターン、つまりエージェントが独立したエンティティとして管理されるのではなく、人間や共有アイデンティティを借用することで権限の継承と攻撃対象領域の拡大が生じるを、まさにBioShockingがすべてのブラウザで成功した「常時アクセス」の問題として描いている。

CSAの「Securing LLM Backed Systems: Essential Authorization Practices」は、LayerXが特定した根本原因、すなわち信頼された高権限システムが攻撃者の意図通りに動かされる間接的プロンプトインジェクションおよび「confused deputy(混乱した代理人)」攻撃に直接言及し、外部の認可チェックポイント、最小権限のスコーピング、人間参加型の統制を正しいアーキテクチャ上の対応として提示している。

CSAの「The AI Security Gap: Why Protecting Prompts Isn’t Enough」は上記の戦略的提言を裏付けるものであり、プロンプトレベルの防御だけでは実世界への影響力を持つAIシステムを安全にできないとし、モデル自身の判断に依拠するのではなく、モデルを取り巻くランタイムでの検査・強制レイヤーの必要性を訴えている。これはまさに、物語的な再フレーミングによってエージェントに自らの安全訓練を無視させたBioShockingが突いた隙間である。

最後に、CSAの「AI Controls Matrix(AICM)v1.1」は、エージェント型ブラウザの導入範囲を検討する際に組織が適用すべきガバナンス・統制の基準を提供しており、特にそのID・アクセス管理領域は、本リサーチノートが短期的な緩和策として推奨する最小権限・認可境界の実践を体系化している。

参考文献

  • [1] LayerX. “BioShocking AI: ‘Gaming’ the AI Browser and Escaping its Guardrails.” LayerX Security Blog, 2026年6月29日
  • [2] The Hacker News. “New BioShocking Attack Tricks AI Browsers Into Leaking User Credentials.” 2026年6月
  • [3] Malwarebytes. “BioShocking: When ‘Gaming’ AI Agents Is No Longer a Game.” Malwarebytes Labs, 2026年7月
  • [4] SecurityWeek. “‘BioShocking’ Attack Tricks AI Browsers Into Stealing Credentials.” 2026年7月2日
  • [5] Cloud Security Alliance. “Securing LLM Backed Systems: Essential Authorization Practices.” CSA AI Technology and Risk Working Group, 2024年
  • [6] Cloud Security Alliance. “The AI Security Gap: Why Protecting Prompts Isn’t Enough.” CSA Summit 2025 at RSAC, 2025年
  • [7] Cloud Security Alliance. “AI Controls Matrix (AICM) v1.1.” 2026年
  • [8] Cloud Security Alliance. “Identity and Access Gaps in the Age of Autonomous AI.” 2026年3月23日

以上

Root of Trust 体系整理 ~ デバイス・クラウド・アイデンティティ基盤における信頼の起点

ガイダンスWGリーダー 諸角昌宏

クラウドセキュリティに関わっていて、使用している環境は信頼できるのかという疑問にぶつかる。自分のPCなら目の前にある機械そのものを信頼すればよいと言えるが、クラウドでは物理的に見えない・触れない環境で動いているため、何を信頼の根拠にするかが難しい。そこで、この信頼の起点になるRoot of Trustをクラウドに限らず全般的に整理してみようというのがここでの目的である。

Root of Trustという概念は、TPMやHSMといったハードウェア単体の話にとどまらず、クラウドの仮想化基盤、FIPS 140-3やCommon Criteriaといった第三者評価制度、ISMAPやCSA CCMなどのガバナンス基準、OktaやパスキーのようなIDプロバイダ、さらにはJPKI・FPOSのような公的アイデンティティ基盤まで、幅広い層にまたがって登場する。ここでは、これらを個別バラバラに理解するのではなく、「信頼の起点」という一本の軸で串刺しに整理することを目的としている。

TPM/HSM等のセキュリティチップと、クラウド側のRoot of Trust実装の違いを整理したい方、ISMAPやCSA CCMなど、クラウドガバナンス制度がRoot of Trustをどう扱っているか把握したい方、JPKIのようなデジタルアイデンティティ基盤と、企業向けIdPとの役割分担を理解したい方には一読していただきたい。

資料はこちらのリンクより確認してください

ご質問・ご指摘があればこちらのブログに返信してください。