「脆弱性報告数が別次元に」 Mythos一般公開を恐れる前に、推奨される7つの優先対策：Mythos未満レベルのAIモデルでも脆弱性は見つかる

Anthropicは、サイバー脅威アクターがAIモデルを用いて攻撃を加速させている状況を受け、企業のセキュリティチームが取るべき対策をまとめたブログ記事を公開した。

[＠IT]

　Anthropicは2026年4月10日（米国時間、以下同）、サイバー脅威アクターがAIモデルの利用により、ソフトウェアの脆弱（ぜいじゃく）性を発見し、悪用するために必要なリソース、時間、スキルを急速に削減し、攻撃を加速させている状況を受け、企業のセキュリティチームが取るべき対策をまとめたブログ記事を公開した。

　Anthropicはこれに先立つ4月7日、最新AIモデル「Claude Mythos Preview」を発表し、「Project Glasswing」の立ち上げも明らかにしている。Claude Mythos Previewは、従来モデルとは別次元の強力なサイバーセキュリティ能力を持つとされている。Project Glasswingは、こうしたAIモデルが今後、続々と登場するとの見通しに立ち、それらが脅威アクターに悪用される前に、Mythosの能力を防御目的に活用し、重要なシステムの保護体制を確立するために、AnthropicがIT他社や金融機関と共同で開始したものだ。

• Claude Mythosのヤバすぎる実力を検証　脆弱性を連結して攻撃経路を生成（＠IT）
• Claude Mythosが1万件超の脆弱性を発見　その裏で開発者コミュニティーに走る緊張（＠IT）
• Claude Mythosの登場に危機感　政府が新防衛構想「Project YATA-Shield」を始動（＠IT）

Mythos未満レベルのAIモデルでも発見できる脆弱性がある

　Anthropicは今回のブログ記事で、「既に一般公開されているMythos未満レベルのAIモデルでも、従来のセキュリティレビューで長期間見過ごされていたソフトウェア脆弱性を発見できる状況にある」との認識を示す。さらに、今後24カ月以内にMythosのような高度なモデルが広く利用可能になり、サイバー攻撃者がそれらを用いて、これまで潜んでいた膨大な脆弱性を発見し、実用的なエクスプロイト（攻撃コード）を作成するようになると警鐘を鳴らしている。

　だが、攻撃側がAIを用いて攻撃を迅速化できるだけでなく、防御側もこうした状況に対処するためにAIツールを活用できる。Anthropicは、自社のセキュリティチームや研究者が、最先端AIモデルを用いてコードベースやシステムを保護する過程で得た知見に基づき、セキュリティに関する実践的な推奨事項を記事で紹介している。

Mythos一般公開を恐れる前に、推奨される7つの優先対策

　それらの多くは、セキュリティ規格の「SOC 2」（Service Organization Control Type 2）や「ISO/IEC 27001」の要件と合致しているが、Anthropicは、AI主導のサイバーセキュリティ時代における有効性という観点から、優先順位を付けている。また、Project Glasswingの今後の進展を踏まえ、これらのガイダンスを更新していくとしている。

　Anthropicが紹介しているセキュリティ推奨事項の概要は以下の通り。

1．パッチ適用の遅れを解消する

　AIモデルは、公開されたパッチを解析して攻撃コードを作る作業を得意としているので、脆弱性の公表とパッチのリリース後、攻撃が行われるまでの時間が短縮されている。Anthropicは、次のような対応を推奨している。

• CISA（米国国土安全保障省サイバーセキュリティインフラストラクチャセキュリティ庁）の「KEV Catalog」（Known Exploited Vulnerabilities Catalog：悪用が確認された脆弱性カタログ）に掲載された脆弱性については、直ちにパッチを適用する
• それ以外については、FIRST.orgが管理するオープンな「EPSS」（Exploit Prediction Scoring System：脆弱性の悪用予測スコアリングシステム）を使って優先順位を決める
• インターネットに面したアプリケーションについては、攻撃コードが出回ってから24時間以内にパッチを当てる
• 停止リスクが許容できる範囲でパッチ適用を自動化する

2．大量の脆弱性報告に備える

　今後約2年間で、自社のコードとベンダーから購入したソフトウェアの両方で、脆弱性の発見数が格段に増加する見通しだ。それらの受け付け、分類、優先順位付け、修正、追跡は、手作業では対応し切れなくなる。

　Anthropicは、「OpenSSF Scorecard」（オープンソースプロジェクトのセキュリティリスクチェックツール）などのツールを使って、オープンソース依存関係の安全性を確認するとともに、取引先ベンダーにも同じ水準の対応を求めるよう勧めている。

　また、以下のような工程にAIを活用できるとしている。

• 重複報告の除去
• 影響範囲の推定
• 修正チケットの下書き作成
• ロックファイルの分析による冗長な依存関係の特定
• パッチの生成と動作検証
• メンテナンスが十分でない小規模な依存関係の自前での再実装

3．リリース前にバグを見つける

　バグを含むコードが本番環境に展開されると、遅かれ早かれ攻撃者に発見されてしまう。そのため、開発ライフサイクルの早い段階で、以下の対策を実施する。

• CI（継続的インテグレーション）パイプラインに静的解析とAIによるコードレビューを組み込む。確度の高い指摘がある場合は、マージを止める
• CD（継続的デリバリー）パイプラインに自動ペネトレーション（侵入）テストを組み込む
• ビルドパイプライン自体も、「SLSA」（Supply-chain Levels for Software Artifacts）などのフレームワークで保護する
• コードの新規作成では、RustやGoといったメモリ安全な言語を既定として採用する

　さらにAnthropicは、攻撃者が使うのと同じ種類のAIモデルで、攻撃者より先に自社のコードをスキャンすることが何よりも重要だと強調している。フロンティアモデルは、スキャナーが検出した問題の修正案も提示できるため、開発者の仕事は、「バグを理解して修正を書く」から、「提示された修正の正しさを検証する」に変わるという。

4．既存コードに潜む脆弱性に対処する

　長期間稼働している既存コードでも、最新のAIモデルを用いたスキャンと解析を受ければ、未知の脆弱性が発見される可能性がある。以下のコードをスキャンと解析の重点的な対象とすべきだ。

• 外部入力を処理する部分
• 認証・認可の判定を行う部分
• インターネットに接続された機能

　レガシーコード、つまり当初の開発者が既に離職しているようなコードは、AIスキャンによるセキュリティ向上の恩恵が特に大きい。発見後の修正に要する工数も、あらかじめ見積もっておく必要がある。

5．侵害されることを前提に設計する

　攻撃者はどこかで足場を築こうとする。防御側は、攻撃者がそこから到達できる範囲を制限する必要がある。

　攻撃の手間を増やして妨害する対策は、無尽蔵の忍耐を持つ相手には効果が薄い。Anthropicは、次のような対策を推奨している。

• 全ての通信を無条件には信頼せず、常に検証を行うゼロトラストアーキテクチャを採用する
• 「FIDO2」やパスキーなど、ハードウェアにひも付いた強固なMFA（多要素認証）を利用してアクセス権を管理する
• 静的なAPIキーや共有サービスアカウントのパスワードは、ID（アイデンティティー）管理基盤が発行する、有効期限の短いトークンに置き換える
• ビルドサーバが侵害されても本番データベースに問い合わせできないように、サービスは、暗号学的な識別子で相互に隔離する

6．外部に露出する資産を減らし、棚卸しする

　存在を認識していないシステムを守ることはできないので、インターネットに面した全てのホスト、サービス、APIエンドポイントの最新インベントリ（資産リスト）を維持することが基本となる。

　使用されておらず、明確な管理者がいないレガシーサービスがあった場合は、廃止する。こうしたサービスは通常、パッチも適用されていない。

　各サービスの公開範囲は最小限に抑え、内部ネットワークへのインバウンドトラフィックはデフォルト（既定）で拒否する。露出しているアタックサーフェス（攻撃対象領域）が小さいほど、攻撃対象が少なくなるからだ。

　さらに、AIを利用して、以下の取り組みを効率的に進めることもできる。

• 不要なコードやシステムの特定、整理
• 自律的な外部レッドチーム演習

7．インシデント対応時間を短縮する

　パッチが公開されてから数時間で攻撃コードが現れる現状においては、インシデント対応に数日かかるのは遅過ぎる。

　SIEM（Security Information and Event Management：セキュリティ情報イベント管理）基盤への読み取り専用アクセスを与えたAIトリアージエージェントを、アラート対応に配置するとよい。これによって一次調査を自動化することで、対応時間を劇的に短縮できる。

　インシデント発生時には、AIに記録、証拠収集、並行調査、事後分析の下書きといった作業を任せ、人間は封じ込め、公表、顧客対応の判断などに専念すべきだ。

　またAnthropicは、以下を推奨している。

• 検知範囲は「MITRE ATT&CK」（攻撃者の攻撃方法や行動、目的を明文化したフレームワーク）を基準に可視化し、横展開と認証情報への攻撃を優先的にカバーする
• 机上演習は、同じ週に5件のインシデントが同時発生する想定で行う
• 緊急対応手順を事前に確立しておく。本番環境へのパッチに2週間の承認フローを要するような体制は、それ自体がセキュリティリスクとなる

外部に脆弱性を報告する際の推奨事項

　自社の依存ライブラリ、オープンソースプロジェクト、ベンダー製品をスキャンし、結果を上流に報告する場合、受理されるかどうかは報告の質で決まる。メンテナは低品質なAI生成報告を既に無視し始めている。

　報告は、人間が内容を検証し、実名で責任を持てる状態になってから送るべきだ。そのための要件としては、「バグとその影響を平易な言葉で説明している」「コードの処理経路を示している」「再現可能なコードを提供している」「修正パッチ案を添付している」「AIが関与している場合は、冒頭に明記している」などが挙げられる。

専任のセキュリティチームがない場合

　Anthropicは、専任のセキュリティ部門がない組織や、個人開発者、オープンソースメンテナ向けの推奨対策として、以下を挙げている。

• 全ての自動更新機能を有効化する
• セルフホスティングよりマネージドサービスを選ぶ（パッチ適用の負担をプロバイダー側に移せる）
• サポートされている全てのアカウントでパスキー、ハードウェアセキュリティキーを使う
• GitHubの「Dependabot」、シークレットスキャン、「CodeQL」といった無料ツールを有効化する
• オープンソースプロジェクトのメンテナは、連絡先と対応方針を明記した「SECURITY.md」ファイルを公開する