1 Mythosとサンドイッチ事件
Mythosの限定公開について
AnthropicのClaude Mythosが脆弱性を発見する能力が段違いに優秀であり、そのために、限定されたユーザのみでの利用に限定され、一般公開話さないということが報道されています。
- 「アンソロピック、次期AIを限定公開 サイバー対策優先で一般提供せず」(日経新聞 4月8日)
- 「⼈智を超えた「Claude Mythos」限定公開開始、サイバーセキュリティの歴史的転換点での「AIレッドチーム」とは」
その上で、自らが開発した手法の詳細を、外部のWebサイトに投稿し始めたといを報道をされています。
このプレビューのプログラムへのアクセス権が不正ユーザーの手に渡っているという報道がなされています。
また、Open AIも 対抗するAIモデルの提供を始めたという報道もされています。
そして、実際にFirefoxの脆弱性が、多数発見されて、それに対応したバージョンが公開されています。
Anthropicの発表
本家、Anthropicの発表としては
サンドイッチ事件
サンドイッチ事件というのは、
Anthropic社が開発したAIモデル「Claude Mythos（ミトス）」の安全評価テスト中に発生した、AIが隔離環境から自律的に脱出した事件
ということになります。
有名にしたKevin Rooseのツイートは、こちら。
影響についての評価
これらの経緯のなかで、
という報道もでています。
Youtubeだと「【速報解説】AnthropicがClaude Mythosを公開しない理由とは？Opus 4.6超え / サンドボックスから自力で脱出 / 脆弱性を数千件発見 / 安全保障に影響？」あたりでしょうか。
あと、サンドイッチ事件からAIの危険性までだと「最新AI「Claude Mythos」がSFすぎる件 研究者の作った”牢”を脱出、悪用懸念で一般公開なし──まるで映画の序章」も参考になります。
2 脆弱性発見ツールの法的位置づけ
ということで、個人的には、「AI」 の危険性というよりも、自動的な脆弱性発見ツールというのが、それ自体、どのように位置づけられるべきなのか、という観点から考えたいとお思います。まずは、お約束の脆弱性の定義から。
2.1 脆弱性とはなにか
私のブログとしては、
など多数です。あと、脆弱性研究委員会の脆弱性早期警戒パートナーシップでの対応の手引きともなっている
- 情報処理推進機構「情報システム等の脆弱性情報の取扱における法律面の調査 報告書 改訂版」(平成31年度) (以下、便宜上 法律面の報告書といいます)
も必読です。
脆弱性の概念については、法律面の報告書 の1.3.2 脆弱性の意義でふれています。これに関して、日本における公的な定義としては、
- サイバー対処能力強化法の定義(同法42条)
- ソフトウエア製品等の脆弱性関連情報に関する取扱規程
の両方にふれる必要があります。
強化法の定義は、
電子計算機のサイバーセキュリティを害するおそれがある電子計算機又は電子計算機に組み込まれるプログラムに含まれる要因（当該電子計算機の通常予見される使用形態によらないことにより生ずるものを除く。)
とされてます。
一方、取扱規定は
コンピュータウイルス、コンピュータ不正アクセス等の攻撃によりその機能や性能を損なう原因となり得る安全性上の問題箇所（ウェブアプリケーションにあっては、アクセス制御機能により保護すべき情報等に不特定又は多数の者がアクセスできる状態を含む。）をいう。
とされています。
比較した場合に、
- 「当該電子計算機の通常予見される使用形態によらないことにより生ずるものを除く」というのが、どのようなものなのか、また、「攻撃により」セキュリティ上の問題を引き起こすこととどれだけ異なるのか、という問題
- 要因というのは、問題箇所というのと同一か
ということになるかと思います。解釈論としては、強化法の定義のほうが、もともと、攻撃によらないでもセキュリティ上の問題を備えていたとしても含まれるという観点から、より広いのではないかという懸念もありますが、この点については、今後検討したいと思います。
2.2 協調された脆弱性開示と脆弱性発見ツール
枠組
協調された脆弱性開示(CVD)については、いままでブログでも何回か触れています。上で触れたもの以外にも
などがあります。
ところで、ツールを用いて脆弱性発見するというのは、この枠組のなかで、どこかに位置づけられるのでしょうか、ということになるかと思います。
早期警戒パートナーシップ(日本)
日本の早期警戒パートナーシップの枠組においては、発見者すなわち、
脆弱性関連情報を発見又は取得した者
を基準としていて、そこでいう「脆弱性関連情報」というのは、
- 脆弱性情報
- 脆弱性が存在することを検証する方法
- 脆弱性を悪用するプログラム、指令又はデータ及びそれらの使用方法
をいうことになります。ここで、「脆弱性が存在することを検証する方法」というのは、
脆弱性が存在することを調べるための方法のことです。例えば、特定の入力パターンにより脆弱性の有無を検証するツール等が該当します。
となります。ここで、およそ、一般的に、ソースコードから、その脆弱性の存在する可能性を推定して、それぞれ検証するという作用をするツールは、この定義に該当するのかということになります。そうだとすると、脆弱性の有無を検証しうるツールがすべて、「脆弱性関連情報」というとして取り扱われる(結果として、発見者に対する規定が適用される)というのは、あまり合理的ではないように思います。その意味で、そのツールの用途のうち、主たるものが、脆弱性の有無の検証であるという場合に限って、脆弱性関連情報の規定の適用を見るというのが合理的に思えます。
その他の協調された脆弱性開示の枠組
その他のCVDに関する国際規格（ISO/IEC 29147, 30111, TR 5895）、CERT/CCガイド、EU規制（NIS2指令Art. 12, CRA）を含む現行のCVD枠組があります。これらについての詳細は省略します。
が、いずれにしても、自動的脆弱性発見ツールについて、
- ツールの利用者や提供者という概念をさだめて、その行動規範を提唱すること
- ツールの利用者に対して、発見者と同様に扱うとする規範を提唱すること
はなされてはいません。
3 自動的脆弱性発見ツールの問題
3.1 自動的脆弱性発見ツールの発展
ここで自動的脆弱性発見ツールという観点からみるとき、調べてみると従来のCVDは人間のセキュリティ研究者がボトルネックでしたが、構造的転換が起きているとされます。
従来の技術的なアプローチとしてファジング（Fuzzing）の高度化をひとつの例としてあげることができます。GoogleはOSS-FuzzにLLM機能を導入し、272のC/C++プロジェクトで37万行以上の新規コードカバレッジを達成しましたた。(Google、OSS向けファジングサービス「OSS-Fuzz」をLLMで改善)
また、GoogleのProject Zeroというのは、Big Sleepを用いて、SQLiteのスタックバッファアンダーフローをリリース前に発見したことが、2024年11月に公表された(Google の AI セキュリティ Big Sleep の快挙：SQLite のゼロデイ CVE-2025-6965 を自律的に検知／特定)。これはAIエージェントが実際に広く使用されているソフトウェアに既知でないエクスプロイタブルな脆弱性を発見した最初の公例とされています。
そのうえで、Mythosのもたらす影響は、上でみたとおりです。
3.2 自動的脆弱性発見ツールの挑戦
自動的脆弱性発見ツールの発展によって、従来の人間が脆弱性を発見して、それを報告して、修正して公開というCVDの基本的な枠組がなりたたなくなってきています。これは、「CVE提出数の爆発的増加とNVDの機能限界」と「ディスクロージャーウィンドウの実質的無効化」という二つの観点から指摘されています。
CVE提出数の爆発的増加とNVDの機能限界：
CVE提出数は2020年から2025年にかけて263%増加し、2026年第1四半期はさらに前年同期比約3割増で推移している。NISTは2025年に42,000件超のCVEをエンリッチしたが、それでも処理能力を超えており、NVDにおける「Not Scheduled」ステータスのCVEが10万件以上に積み上がっている(NIST、ついに“脆弱性の全件分析”を断念 CVE爆増でパンク状態、方針転換)。
CVEプログラム関係者は「AI生成レポートが氾濫する中でレポートの質が深刻な懸念事項となっている」と指摘しています(AIによる低品質な脆弱性レポート連発でcURLがバグ報奨金プログラムを停止)。
ディスクロージャーウィンドウの実質的無効化：
公開開示から大規模悪用までの歴史的な時間的ギャップが著しく縮小しています(「侵入4分後にデータが消える」 AI悪用で“攻撃が速過ぎる”今、セキュリティチームが勝つには)。
3.3 自動的脆弱性発見ツールとAI規制
ここで、このような自動的脆弱性発見ツールについてEUにおいてAI法(AI Act, Regulation (EU) 2024/1689)がどのように規制しているのか、というのをみてみます。まずは、定義からみます。ちなみに、CRICの日本語訳は、こちらです。
AI法における定義は、「機械学習、論理・知識ベースのアプローチ、統計的アプローチを使い、入力から出力を生成するシステム」と定義しています()。そうすると、LLM/GPAIモデルを用いたコード審査ツール（Big SleepやClaude Mythosのようなもの）→ 定義に明確に該当、AIを組み込んだファジングツール（OSS-Fuzz + LLM等）→ 該当に対して、ルールベースのみの従来型スキャナー（SAST/DASTで純粋に静的なもの）→ 定義外の可能性ということがいえます。
ここで、毎度おなじみのAI法のリスクベースの図です。
ここで、高リスク用途ですが、重要分野及びユースケースの1つ以上に該当するAIシステムは、自然人の健康、安全又は基本的権利に害を及ぼす重大なリスクをもたらす場合や環境に害を及ぼす重大なリスクをもたらす場合には高リスクであるとみなされています(6条1項)。附属書Ⅲは、「6条2項に定める高リスクAIシステム」として、バイオメトリック及びそのシステム、重要インフラの管理及び運営、教育及び職業訓練、雇用、労働者管理及び自営業へのアクセス、重要な民間及び公共のサービス及び給付へのアクセス及びその享受、法執行、移民・難民等の庇護及び国境管理、司法の運営及び民主的なプロセスの分野に関連するものが、高リスクであることを示しています。
そうだとすると、自動脆弱性発見ツールは原則としてAnnex IIIの列挙事項に直接該当しないのが原則となります。
もっとも、例外的に該当し得る重要な場面があります。
- Annex III第2項は「重要デジタルインフラの管理・運用における安全コンポーネントとして使用されることを意図したAIシステム」を高リスクとして列挙しています。 したがって、電力・金融・医療等の重要インフラ事業者がこのツールを安全管理の一部として組み込む場合は高リスクに分類される可能性があります。
- 法執行目的での利用：国家機関がサイバー犯罪捜査に使用する場合。
となります。
高リスクのシステムの場合は、リスク管理態勢を定め、実施し、文書化し、維持しなければならないとさています(9条)。また、データおよびデータガバナンスについて訓練用、検証用、テスト用のデータセットが使用されるごとに、品質基準を満たすこれらのデータセットを基礎として、開発されなければならないとされます(10条)。その上、技術文書の作成・維持(11条)、記録保存(12条)、透明性(13条)、人間による管理(14条)、制度・堅牢性・サイバーセキュリティ(15条)の規定があります。
また、同規則の適用上、「実施者（deployer）」について、人間による監督の実施、そのためのリソースの確保、堅牢性とサイバーセキュリティの対策の監視・調整・更新、モニタリング、一定の場合における高リスクAIの使用の通知等の義務を定めています（26条）。また、高リスクAIの利用については、影響評価の実施義務もある（27条）。
また、LLMの一般的な技術については、「汎用Aiモデル」として
「汎用 AI モデル」。AI モデルが大規模な自己教師を用いて大量のデータで訓練される場合を含む、AI モデルであり、著しい汎用性を示し、モデルが上市される方法を問わず、幅広い範囲の異なるタスクを適切に実行することができ、かつ、川下にあるさまざまなシステムまたはアプリケーションに組み込まれ得るもの。 ただし、上市前に研究、開発、または試作の各活動のために使用されるAI モデルを除く；
と定義されています。この場合、訓練・テストプロセスを含む最新の技術文書を維持・提供し、Commissionおよび各国当局に協力し、著作権関連法を遵守しなければならない義務(53条)、システミック・リスクを示す場合には、標準化されたモデル評価の実施、システミックリスクの評価・軽減、重大インシデントの追跡・AI Officeへの報告、サイバーセキュリティ保護の確保という追加義務(55条)が定められています。
自動的脆弱性発見ツールが、汎用AIモデルを技術として採用しているのであれば、上記53条などの義務を負うということになります。
3.4 脆弱性発見ツールとEU法のその他の規制
サイバーレジリエンス法と脆弱性規律について
EUサイバーレジリエンス法(デジタル要素を有する製品の水平的サイバーセキュリティ要求事項及び規則、CRA)は2024年12月10日に発効しています。主要条文は2027年12月11日から完全適用されますが、例外として、適合性評価機関の通知に関する第IV章は2026年6月11日から、脆弱性・インシデントの報告義務を定めるArt. 14は2026年9月11日から先行適用されます。
この構造は、以下で図示できます。
規制対象は、デジタル製品です。これはさらに、わかれます。図示は、こちら。
「デジタル要素を有する製品」とは、ソフトウェア又はハードウェア製品及びその遠隔データ処理ソリューションを意味し、個別に市場に投入されるソフトウェア又はハードウェア・コンポーネントを含むとされる（3条(1)）。
「デジタル要素を有する重要な（important）製品」は、附属書IIIに定められた製品カテゴリの中核機能を有するデジタル要素を有する製品として定義されます（7条1項）。この製品は、クラスⅠとクラスⅡに分けられます。
クラスⅠとされる製品の例としては、アイデンティティ管理システム及び特権アクセス管理ソフトウェア及びハードウェア（生体認証リーダを含む認証及びアクセス制御リーダを含む）、ブラウザ、パスワード管理システム、悪意のあるソフトウェアを検索、削除、又は隔離するソフトウェア、VPN（仮想プライベートネットワーク）の機能を有するデジタル要素を含む製品などが挙げられています。
クラスⅡとされる製品は、オペレーティングシステムや同様の環境の仮想化実行をサポートするハイパーバイザーやコンテナランタイムシステム、ファイアウォール、侵入検知・防止システム、耐改ざんマイクロプロセッサ、耐改ざんマイクロコントローラです。
なお、クラスⅠとクラスⅡでは適合性評価手続の内容が異なります。クラスⅠの製品については、製造者が調和規格を完全に適用している場合に限り自己適合性評価を行うことができ、それ以外の場合は被通知機関による第三者評価が必要となります。クラスⅡの製品については、被通知機関による適合性評価手続が一律に義務付けられます（32条2項・3項）。
また、「デジタル要素を有するクリティカルな製品（critical product with digital elements）」という概念も定められています（8条・附属書Ⅳ）。これは、附属書Ⅳに記載されたカテゴリの中核機能を有するデジタル要素を有する製品です。具体的なものとしては、セキュリティボックス付きハードウェアデバイス、スマートメータゲートウェイや安全な暗号処理用を含む高度なセキュリティ目的のその他のデバイス、セキュアエレメントを含むスマートカード又は同様のデバイスが挙げられています。これらの製品については、委任法によって、「相当な（substantial）」保証レベル以上の欧州サイバーセキュリティ認証の取得を義務付けることができます（8条1項）。委任法が採択されるまでの間は、32条3項に定める適合性評価手続に服することになります。
デジタル製品の脆弱性についての規定
設計・開発段階の要件（附属書I第1部）
製造業者は、製品を市場に投入する際、附属書Iに定める基本的なサイバーセキュリティ要件を満たすよう、設計・開発・製造を行わなければなりません（6条）。
脆弱性に直接関連する要件としては、製品が市場に投入される時点で既知の悪用可能な脆弱性が存在しない状態で提供されること、デフォルトで安全な構成が確保されること、セキュリティ・アップデートを通じて脆弱性に対処できる仕組みを備えること、などが求められます。これらの要件はリスク評価（13条2項）に基づいて適用され、製品の特性や用途に応じた比例的な対応が期待されます。
ライフサイクル管理における脆弱性取扱要件（附属書I第2部）
製造業者は、製品の市場投入時からサポート期間（一般的な最低期間は5年）を通じて、脆弱性を効果的にハンドリングしなければなりません。具体的には以下の義務が課されています。
（1）脆弱性・コンポーネントの文書化とSBOM
製品に含まれる脆弱性とコンポーネントを特定・文書化することが義務付けられており、少なくともトップレベルの依存関係を網羅したSBOM（ソフトウェア部品表）の作成が求められます。SBOMは市場監視当局の要請に応じて提出する義務がありますが、公開は必須ではありません。
（2）セキュリティ・アップデートの提供
発見された脆弱性は遅延なく修正・緩和され、技術的に可能な場合はセキュリティ・アップデートを機能アップデートとは別途提供しなければなりません。セキュリティ・アップデートはサポート期間中または最低10年間のいずれか長い方の期間、無償で引き続き提供される必要があります。
（3）テストとレビュー
製品のセキュリティに関する効果的かつ定期的なテストとレビューを実施しなければなりません。
（4）修正済み脆弱性情報の公開
セキュリティ・アップデートが提供された後は、脆弱性の説明、影響を受ける製品の特定情報、深刻度、修正方法などを含む情報を公開しなければなりません。ただし、公開によるセキュリティ上のリスクがその利点を上回ると判断する正当な理由がある場合には、ユーザが関連するパッチを適用できるようになるまで公開を遅延させることができます。
（5）CVDポリシーの策定
協調的な脆弱性開示（CVD）に関するポリシーを導入・実施することが義務付けられています。ユーザや外部研究者が脆弱性を報告できる単一の窓口の設置も求められます。
（6）第三者コンポーネントへの対応
自社製品に統合された第三者製品やオープンソースのコンポーネントに脆弱性を発見した場合は、当該コンポーネントの開発・管理主体に報告するとともに、自社製品における脆弱性の修正も行わなければなりません。修正のためにコードや文書を作成した場合は、当該主体にそれらを共有することも求められます。
（7）アップデートの安全な配布
セキュリティ・アップデートを安全に配布するメカニズムを提供し、該当する場合は自動的な方法による修正・緩和を確保しなければなりません。セキュリティパッチは遅延なく無償で配布され、ユーザへの勧告メッセージを添付することが求められます。
当局への報告義務（14条・2026年9月11日から先行適用）
製造業者は、自社製品において積極的に悪用されている脆弱性（actively exploited vulnerability）または製品のセキュリティに影響を与える重大インシデントを認識した場合、ENISAが運営するシングルレポーティングプラットフォーム（SRP）を通じて、以下の段階的報告義務を負います。
期限内容認識後24時間以内早期警告：主たる事業所所在国のCSIRTおよびENISAへの通知認識後72時間以内詳細な脆弱性通知（技術的詳細を含む）緩和措置提供後14日以内最終報告書（根本原因分析、是正措置、再発防止措置を含む）
なお、ユーザへの通知義務も課されており（14条8項）、製造業者が適時に通知しない場合は所管CSIRTが当該情報を自ら公表できます。また、善意のセキュリティ研究者が発見した脆弱性はこの報告義務から除外されており（Recital 35a）、CVDの実践との整合性が図られています。
技術文書（31条・附属書VII）
製造業者は、製品の設計・開発・製造・脆弱性処理プロセスに関する記述、サイバーセキュリティリスク評価、整合規格・共通仕様、適合性検証試験の結果などを含む技術文書を作成・維持しなければなりません。技術文書は製品の上市後10年間またはサポート期間のいずれか長い方の期間、市場監視当局の閲覧に供する必要があります。
CRA法と発見ツールの位置づけ
結局、CRA法自体は、自動的脆弱性発見ツールについて直接に述べているところはないということになります。
3.5 脆弱性発見ツールと輸出規制
では、このような脆弱性発見ツールと輸出規制はどうなっているのかということになります。この点についてのベースは、ワッセナーアレンジメントになります。
ワッセナー・アレンジメントは、正式には、「通常兵器及び関連汎用品・技術の輸出管理に関するワッセナー・アレンジメント（The Wassenaar Arrangement on Export Controls for Conventional Arms and Dual-Use Goods and Technologies）」といい、通常兵器及び関連汎用品・技術の責任ある輸出管理を実施することにより、地域の安定を損なう虞れのある通常兵器の過度の移転と蓄積を防止することを目的として、1996年7月に成立した新しい国際的申し合わせに基づく国際的輸出管理体制のことをいいます。
これは、WAは法的拘束力を有する国際約束に基づく国際的な体制ではなく、通常兵器及び機微な関連汎用品・技術の供給能力を有し、かつ不拡散のために努力する意志を有する参加国による紳士的な申し合わせとして存在しており、（イ）輸出管理および、（ロ）情報交換を行っています。
輸出管理は、（a）汎用品リストと（b）軍需品リストにもとづいてなされています。このうち、汎用品リストは、一般的な注釈 、9カテゴリーに分類された基本リスト及び基本リストの中でもより機微なものと位置づけられる汎用品・技術を抜粋した機微リスト（ Sensitive List）、極機微リスト（Very Sensitive List）からなりたっている。また、（b）軍需品リスト（ MUNITIONS LIST）は、22項目にわたり武器（通常兵器）を全般的に網羅している。
これらの選択の基準に関して、両用用品（dual use items ）は、「管理されるべき両用製品および技術とは、主たる（major）もしくは主要な（key）要素が、そもそも（indigenous ）軍事能力の開発、生産、使用もしくは拡張のものをいうと定義されています。そして、この定義に該当するかどうかについて、参加国以外における利用可能性、対象品の有効な管理の可能性、使用の明確化・客観化の可能性、他の体制による管理の観点から判断されます。
このワッセナーシレンジメントにおいて、2013年12⽉にウィーンにおいて開催されたワッセナー・アレンジメント（WA）の第19回総会において、2013年においては、偵察及び法執⾏のための機器、情報収集のための機器並びにインターネット・プロトコルの監視システム⼜は機材において新たな輸出管理に合意しています。これは、いわゆる西側諸国の企業が開発した「FinFisher」などのサーベイランス・ソフトウェアが独裁的政権に購入され国民の監視抑圧目的に使われていたことが判明したことから、そのような「ソフトウエア兵器」にあたるものも輸出規制をするべきという機運が高まったことによる。FinFisherという英国企業が高度なスパイウェアや監視システムをバーレーンやトルクメニスタンの各国政府に輸出し、それが反政府分子その他の活動家の活動の諜報に使用されていたことが明らかになったことを受け、かかる高度なスパイウェアや監視システムの輸出を規制しようと英国が提案し、成立したものです 。
(以下、Claudeによります)
現在の規定については、ワッセナー・アレンジメントのデュアルユース品目リスト（WA-LIST）は2025年12月に最新版（WA-LIST (25) 1）が公表されており、2025年プレナリーの合意を反映しています。侵入ソフトウェアに関連する規制は、2013年の導入後、2017年および2024年プレナリーで重要な改正がなされました。
侵入ソフトウェアの文言および定義
カテゴリー４（コンピュータ）においては、”侵入ソフトウエア（intrusion software）”に関するシステム等がリストとして指定されています。具体的には以下の通りです。
4. A. SYSTEMS, EQUIPMENT AND COMPONENTS（システム、設備、コンポーネント）において、
「4. A. 5. ”侵入ソフトウエア”の作成、指揮統制（command and control）若しくは配信又は当該ソフトウエアとの通信を行うように特別に設計若しくは改造されたシステム、設備及びそれらのコンポーネント」と定められています。
また、4. D. ソフトウェアにおいては、
「4. D. 4. ”侵入ソフトウエア”の作成、指揮統制若しくは配信又は当該ソフトウエアとの通信を行うように特別に設計若しくは改造された”ソフトウエア”。」
と定められています。
さらに、4. E. 技術においては、
「4. E. 1. c. ”侵入ソフトウエア”の”開発”に係る”技術”。」
とリストが定められています。
なお、4.E.1に関しては重要な除外規定が設けられており、脆弱性開示（vulnerability disclosure）またはサイバーインシデント対応（cyber incident response）のために輸出される技術はこの規制対象から除外されます。この除外は、CVD（協調された脆弱性開示）実務との整合性を確保するために2017年改正で導入されたものです。
“侵入ソフトウエア”の定義（ワッセナー・アレンジメント定義部）は以下の通りです。
「”Intrusion software”（侵入ソフトウエア）：コンピュータ又はネットワーク対応機器の’monitoring tools’（監視ツール）による探知を防止するため、又はコンピュータ又はネットワーク対応機器の’protective countermeasures’（保護措置）を無効にするために特別に設計又は改造した”ソフトウエア”であって、次のいずれかを実行するもの：
a. コンピュータ若しくはネットワーク対応機器からのデータ若しくは情報の抽出、又はシステム若しくはユーザーデータの改変；或いは
b. 外部から与えられる命令の実行を可能にするため、プログラム又はプロセスの標準的な実行パスの改変。」
この定義に対する注釈において、以下のものは”侵入ソフトウエア”から除外されます。
注釈1 ”侵入ソフトウエア”は、次のものを含まない：
a. ハイパーバイザー、デバッガー、若しくはソフトウェアのリバースエンジニアリング（SRE）ツール；
b. デジタル著作権管理（DRM）”ソフトウエア”；又は
c. メーカー、アドミニストレーター又はユーザーによってインストールされるように設計した”ソフトウエア”であって、資産管理若しくは資産回収を目的とするもの。
注釈2 ネットワーク対応機器には、モバイル機器及びスマートメーターを含む。
技術的注釈として、関連用語は以下のように定義されます。
‘Monitoring tools’（監視ツール）：
デバイス上で動作しているシステムの挙動又はプロセスを監視する”ソフトウエア”又はハードウェア機器。これには、アンチウィルス（AV）製品、ネットワーク端末のセキュリティ製品、パーソナルセキュリティ製品（PSP）、侵入検知システム（IDS）、侵入防御システム（IPS）又はファイアウォールを含む。
‘Protective countermeasures’（保護措置）：
コードの安全な実行を確保するための技術（例えば、データ実行防止（DEP）、アドレス空間配置のランダム化（ASLR）又はサンドボックス化）。
輸出規制と脆弱性自動発見ツール
結局、侵入ソフトウエアの概念は、データ若しくは情報の抽出、又はシステム若しくはユーザーデータの改変やプログラム又はプロセスの標準的な実行パスの改変という概念をコアにしてしいます。結局、自動発見ツール自体が、潜在的に、サイバーセキュリティの脅威になりうるのではないか、という観点からは整理されていない。
(Claude ここまで)
4 考察
ここでの考察を図示します。
4.1 既存の法規制の枠組
結局、このような考察のもとでは、
- 法的な規制において、脆弱性は、その悪用された場合において、その情報について共有する枠組を定めているのがせいぜいであって、脆弱性の自動発見ツールについて法的な枠組(輸出規制を含む)を準備するということはされていない。
- CVDに関する枠組、特に、国家組織が関与して脆弱性について調整する枠組において、脆弱性の自動発見ツールについてその提供者や利用者に対する行為規範は与えられていないこと
がわかります。
しかしながら、サイバーセキュリティの重要性・特に脆弱性情報の発見・流通・悪用防止等の観点から、この脆弱性の「自動的発見ツール」という概念をベースにして、そのツールの提供者・利用者に関して、一定の法的な責任(行動責任・結果責任)の枠組を準備していくことが、今後、必要なものと考えます。原則としては、発見された脆弱性についての発見者等の基準による対応ということで対応ができるだろうとは思いますが、むしろ、自動的脆弱性検証ツールということを考えた場合に、技術の進歩に応じて、それが、人間を関与をきわめて乏しいままで実際に利用されることになり、また、その性質的にきわめて高度なものが開発されるようになった場合には、いままでの枠組が対応しきれなくなってきているということがいえるだろうと思います。
4.2 概念の基本要素
自動的発見ツール
結局、ルールベースであろうとなかろうと、脆弱性を識別してくれるツールとそれによる脆弱性の発見・対応の困難性が、枠組について新たな考察の必要性をささえているので、脆弱性の自動的発見ツールというのを枠組のキーにするのが合理的だろうと考えます。
提供者・利用者
この場合、最小限費用回避者は、提供者もしくは、利用者ということなのだろうと思います。
4.3 法的責任
行動責任
利用者については、結局、脆弱性の発見者となると考えられますが、自動的発見ツールについては、発見する前から、義務を付すというアプローチもありそうです。具体的な内容については、今後の課題でしょう。そもそも、本当に高度なツールについては、だれでも利用できるのが妥当なのか、という問題が提起されていると思われます。
提供者についてはAI法で定められている技術文書の作成・維持(11条)、記録保存(12条)、透明性(13条)、人間による管理(14条)、制度・堅牢性・サイバーセキュリティ(15条)、影響評価の実施義務（27条）などは、有効な視点となりうるものと考えられると思います。さらに、利用者を限定するべき義務があるのではないか(良くdual use toolにいわれている話です) 、悪用の連絡があった場合については、通知窓口を設けて、その評価と安全対策をとる義務というのは、追加されるべきように思います。まさに、通知から、「相当の注意義務(due diligence)」が具体化するということがいえます。
結果責任
脆弱性の自動的発見ツールが悪用されて、攻撃者が取得した脆弱性を悪用して、金融機関に対して攻撃をしかけ、その金融機関から、資産を奪ったとしましょう。その金融機関は、その自動的発見ツールの提供者に対して、損害賠償を求めうるでしょうか。攻撃について、容易にしているのではないか、提供者が悪用されないための相当な注意を払っていなかったとすれば、損害賠償をする責任を負うのではないかという問題になります。このような事案については、具体的な攻撃に悪用された脆弱性の特定、そのツールが、攻撃者の攻撃を容易にした事実の特定・証明が難しいものと考えられます。しかしながら、もし、事実として、そのようなツールで攻撃が容易になったという事実があれば、損害賠償の責任を肯定することはありうるだろうと思います。では、提供者は、そのような悪用に対して、最終的に保険でその責任を転嫁できるのか、損害が多額になりうるのではないか、保険がなりたちうるのか、などという問題もかんがえないといけないかもしません。
