AI加速型攻撃に備えるセキュリティプログラムの準備
Anthropic社は、AIが脆弱性の発見・悪用を加速化させる時代に向けて、自社のProject Glasswingの知見に基づき、パッチ適用の緊急性など具体的なセキュリティ対策を推奨するガイダンスを公開した。
キーポイント
AIによる攻撃の加速化
AIモデルは、脆弱性の発見と悪用に必要なリソース、時間、スキルを急速に低下させており、今後24ヶ月以内に多くの潜在的なバグがAIによって発見・悪用される可能性が高い。
防御側のAI活用の重要性
攻撃者がAIを利用する一方で、防御側もAIツールを採用することで自らを守ることが可能であり、AI駆動のサイバーセキュリティ時代への対応が求められる。
具体的な対策：パッチギャップの解消
AIは既知の脆弱性のシグネチャを認識し、パッチからエクスプロイトへの逆変換に優れているため、パッチ公開から悪用可能になるまでの時間が短縮されており、CISA KEVカタログの脆弱性への緊急対応が推奨される。
既存セキュリティ基準との整合性
推奨事項の多くは既存のセキュリティコンセンサスの一部であり、SOC 2やISO 27001などのコントロールに直接マッピングされる。
脆弱性管理プロセスの自動化と優先順位付け
EPSSを活用して脆弱性の優先順位を決定し、インターネット公開システムのパッチ適用を24時間以内に行うことを推奨。クラウドやOSベンダーの自動パッチ適用機能を活用し、コンテナイメージや依存関係のスキャンをCIステップとして組み込む。
脆弱性報告数の大幅増加への対応準備
今後2年間で脆弱性報告数が桁違いに増加するため、受付、トリアージ、修復追跡プロセスを強化する必要がある。スプレッドシートと週次会議だけでは対応できず、自動化と人間の判断を組み合わせたプロセス設計が重要。
サプライチェーンセキュリティの強化
オープンソース依存関係のセキュリティ評価をOpenSSF Scorecardで自動化し、ベンダーにも加速化されたエクスプロイトタイムラインへの対応を要求する。脆弱なコードの到達可能性を評価するツールやサービスを活用し、継続的なソフトウェア更新の自動配信プロセスを構築する。
影響分析・編集コメントを表示
影響分析
この記事は、AIがもたらすセキュリティ脅威の質的変化を具体的なタイムライン（24ヶ月）とともに示し、防御側の実践的な対応策を提示している点で重要である。特に、AIがパッチ解析を効率化することで攻撃の窓が狭まるという指摘は、従来のセキュリティ運用の前提を変える可能性がある。
編集コメント
AIの脅威を抽象的に論じるのではなく、具体的なプロジェクト（Project Glasswing）の知見と実践的な対策に基づいた内容であり、セキュリティ担当者にとって即時アクションに移せる価値がある。
AI加速化する攻撃に備えたセキュリティプログラムの準備
AIは、脆弱性が発見され悪用される速度を変えつつあります。当社は、自社の調査結果とセキュリティ実践に基づき、防御を強化するための初期推奨事項セットを公開します。
ProductClaude Enterprise
Date2026年4月10日
Reading time5分
Shareリンクをコピーhttps://claude.com/blog/preparing-your-security-program-for-ai-accelerated-offense
今週初め、当社はProject Glasswingを発表しました。これは、最新のフロンティアモデルであるClaude Mythos Previewの強力なサイバーセキュリティ能力を防御目的で活用するための緊急の試みです。発表文および付随する技術ブログ記事では、AIモデルがソフトウェアの脆弱性を発見・悪用するために必要なリソース、時間、スキルを急速に削減していることを説明しました。
AIの驚異的な進歩に注目しつつ、同レベルの能力を持つモデルが広く利用可能になるのもそう遠くないことにも言及しました。今後24ヶ月以内に、コード内でおそらく何年も気づかれずにいた膨大な数のバグがAIモデルによって発見され、実用的なエクスプロイト（攻撃コード）へと連鎖的に組み立てられるでしょう。実際、Mythosレベル未満の公開モデルでさえ、従来のレビューが長期間見逃してきた重大な脆弱性を発見できるケースは既に生じています。
幸いなことに、これは両刃の剣です。攻撃者がAIを使って迅速に動ける一方で、防御側もAIツールを採用して自らを守ることができます。この記事では、当社のセキュリティチームと研究者が、実際のコードベースやシステムを保護するためにフロンティアAIモデルを使用して観察・学んだことに基づき、セキュリティに関する推奨事項と実践的なヒントを提供します。AI駆動型サイバーセキュリティの時代に入るにあたり、セキュリティチームやその他の方々がこの助言を有用と感じられることを願っています。
以下の助言の多くは、既存のセキュリティコンセンサスの一部です。当社は、どの管理策が有効に機能し、どの管理策が劣化しているかを確認した上で、それらに優先順位を付けました。お客様の組織がSOC 2やISO 27001に準拠して報告している場合、これらは既に追跡している管理策に直接対応します。
当社およびProject Glasswingのパートナーがサイバーセキュリティ作業を継続する中で、このガイダンスを更新していきます。
- パッチ適用のギャップを埋める
AIモデルは、パッチ未適用システムにおいて、既知の、既にパッチが適用済みの脆弱性のシグネチャ（特徴）を認識するのに非常に効果的です。パッチを逆解析して実用的なエクスプロイトにすることは、まさにこれらのモデルが得意とする機械的な分析です。これは、パッチが公開されてからエクスプロイトが利用可能になるまでの時間的余裕が縮小していることを意味します。
CISA既知悪用脆弱性(KEV)カタログに記載されているすべての脆弱性に直ちにパッチを適用してください。このカタログには、悪用が確認されている脆弱性が含まれています。このリストに記載され、ネットワークから到達可能なものはすべて緊急事態として扱うべきです。
残りの脆弱性の優先順位付けにはEPSSを使用してください。エクスプロイト予測スコアリングシステム(EPSS)は、特定の共通脆弱性識別子(CVE)が今後30日以内に悪用される確率を毎日更新して提供します。まずKEVリストにパッチを適用し、その後、選択したEPSS閾値を超えるすべての脆弱性にパッチを適用することで、数千件の未対応CVEを管理可能なキューに変えるのに役立ちます。
インターネットに接続されたシステムのパッチ適用までの時間を短縮してください。エクスプロイトが利用可能になってから24時間以内にインターネット接続アプリケーションにパッチを適用し、その他の脆弱性については数日以内に適用することを推奨します。
自動更新による障害発生のリスクが許容できる場合、パッチの展開と再起動を自動化してください。手動承認ステップは遅延を生み、今やその遅延が主要なリスクとなっています。
実践的なヒント: ほとんどのクラウドおよびOSベンダーは既にパッチ自動化機能を提供しており、有効化は多くの場合、簡単な設定変更で済みます。コンテナイメージや依存関係マニフェストについては、いくつかのオープンソーススキャナーが単一の継続的インテグレーション(CI)ステップとして実行され、KEVカタログとEPSSからのデータでCVEに注釈を付けるため、優先順位付けが組み込まれています。
- はるかに大量の脆弱性レポートを処理する準備をする
今後約2年間で、脆弱性を受信、優先順位付け、修正するために使用するプロセス（自社のコードとベンダーから購入するソフトウェアの両方において）は、現在よりもはるかに大きな圧力にさらされます。脆弱性管理プロセスは、ベンダーや上流からくるはるかに多くのパッチに対応できるよう計画すべきです。
発見件数の桁違いの増加に備えて計画してください。受付、トリアージ（優先度判定）、修復追跡などの側面は、露呈する脆弱性の増加数に追いつく必要があります。セキュリティ会議がまだスプレッドシートと週次会議を中心に構築されている場合、追いつくことは難しいでしょう。ここでの膨大な量に対処するために、当然のことながら人間が関与しつつ、ある程度の自動化を検討する価値があります。
オープンソース依存関係のセキュリティを確認してください。ほとんどのソフトウェアサプライチェーンは主にオープンソースで構成されています。ほとんどのオープンソースプロジェクトには、高いレベルのセキュリティを維持するためのサービスレベル契約やコミットメントはありません。OpenSSF Scorecardは、ブランチ保護、ファジング（Fuzzing）カバレッジ、署名付きリリース、メンテナの活動状況などのシグナルに基づいて、すべての依存関係を自動的にスコアリングします。これはCIで実行され、メンテナンスされていないパッケージを特定するのに役立ちます。
同じ期待をベンダーにも適用してください。サードパーティリスク管理プロセスでは、サプライヤーに対して、彼ら自身が加速するエクスプロイトのタイムラインにどのように備えているか、また自社のコードをスキャンしているかどうかを尋ねるべきです。
実践的なヒント: 脆弱なコードの到達可能性を評価するオープンソースソフトウェアやサードパーティサービスを調査してください。更新に対して回帰テストを行い、迅速にデプロイできるという確信を得ることで、ITおよび本番インフラストラクチャに新しいソフトウェア更新を継続的に提供する自動化プロセスを構築してください。
上記では、これらのプロセスの自動化について言及しました。AIが支援できる重要な方法がいくつかあります:
トリアージの高速化: トリアージは、専門家によるレビューと分類が必要なため、ボトルネックとなります。フロンティアモデルは、既存のバックログに対して発見を重複排除し、資産に関する知識を使用して影響範囲を推定し、影響を受けるコードパスが事前に特定されている修復チケットを起草できます。
依存関係の冗長性を確認する: ほとんどの大規模なコードベースでは、同じ仕事をする複数のライブラリが蓄積されます（複数のHTTPクライアント、複数のJSONパーサーなど）。これは、機能的な利点がないにもかかわらず、攻撃者により多くの機会を与えます。ロックファイルに対してLLM（大規模言語モデル）を向け、どの依存関係が重複しているか（および移行と統合がどのように見えるか）を尋ねることは、多くの場合効果的な1時間の作業です。
AIによるアップグレード自動化: フロンティアモデルは、脆弱性レポートと一緒に含めるパッチを生成する能力をますます高めています。レポートが明確で徹底的であれば、場合によっては概念実証(PoC)付きであれば、モデルはエクスプロイト経路が閉じられたことを確認するためにパッチを直接テストできます。また、上流のパッチを受け入れ、アップグレードがテストや内部システムを壊さないことを検証するプロセスを直接自動化することもできます。
AIによるベンダリング: 一部の小さな依存関係は、OpenSSF Scorecardで低いスコアになるかもしれません（おそらく、積極的にメンテナンスされていないため）。これらに依存し続けるべきではありません。代わりに、LLMに実際に使用している機能を再実装する独自のコードを書かせることを検討すべきです。
- 出荷前にバグを見つける
予防は常に治療に勝ります。本番環境に到達したバグは最終的には発見されると想定すべきなので、セキュリティテストは十分に前もって行う必要があります。
静的解析とAI支援コードレビューを継続的インテグレーション(CI)パイプラインに追加し、高確信度の発見に対してマージをブロックしてください。誤検知によりこれが非現実的である場合は、チェックは維持すべきですが、ツーリングに対処すべきです。OWASPアプリケーションセキュリティ検証標準(ASVS)は、3つの異なる厳密さレベルでテストを「合格」することがどのように見えるかを定義しています。
自動化されたペネトレーションテストを継続的デリバリー(CD)パイプラインに追加してください。攻撃者が本番システムに対して実行するのと同じスキャンを、ステージング環境に対して実行できます。
ビルドパイプラインを保護してください。コミットとデプロイの間にコードを注入できる攻撃者は、脆弱性を見つける必要がありません。SLSAセキュリティフレームワークは段階的な道筋を提供します。低いレベルでは、どのコミットがどの成果物を生成したかを確立し、高いレベルではビルド自体を検証可能にします。
セキュアバイデザインの実践を採用してください。CISAの誓約事項（デフォルトでの多要素認証(MFA)、デフォルトパスワードなし、透明性のある脆弱性報告）は、合理的な最低基準です。
新しいコードにはメモリ安全な言語を優先してください。深刻な脆弱性の大部分は、Rust、Go、またはマネージドランタイムでは発生しないメモリ安全性バグです。CISA、NSA、NCSCは有用なロードマップを公開しています。既存のC/C++コードを書き直す必要はありませんが、新しいC/C++コードには正当な理由が必要です。AI支援による書き直しも、ますます実現可能になっています。
実践的なヒント: OWASP Top 10と言語固有のルールセットを備えたCIアクションとして実行される静的アプリケーションセキュリティテスト(SAST)ツーリングは、オープンソースおよびコードホスティングプラットフォームに組み込まれた形で広く利用可能です（GitHub上のCodeQLが最も一般的な出発点です）。ビルドの出自を評価するために、OpenSSFはGitHub ActionsからSLSAレベル3の証明書を生成する再利用可能なワークフローを公開しています。これを採用することは、SLSA仕様が示唆するよりも大幅に少ない作業です。
以前と同様に、AIでこの作業を加速する明確な機会がいくつかあります:
AI脆弱性スキャン: ここでの論理は単純です。攻撃者が使用するのと同じ種類のモデルで、彼らが行う前に、自社のコードとシステムをスキャンすべきです。このアプローチには、分離されたエージェント、ノイズをフィルタリングする検証ステップ、および既存のトリアージプロセスへの経路が必要です。これは今日、LLMで実行できます。このセクションから1つだけ実装するなら、これを実装してください。
パッチ生成。SAST（静的アプリケーションセキュリティテスト）やスキャナーが検出結果を生成した際、フロンティアモデルは通常、それに対するパッチを提案できます。これによってレビューの必要性がなくなるわけではありませんが、開発者の仕事が「バグを理解して修正を書く」から「提案された修正が正しいことを検証する」に変わります。後者の方が速いです。同じアプローチはメモリ安全な言語への移行にも適用できます：LLM（大規模言語モデル）は、テスト付きの自己完結型CモジュールをRustに移植できます。レビュアーは、ゼロからすべてを書くのではなく、同等性を検証すればよいのです。
- 既にコード内にある脆弱性を見つける
パッチ適用は、依存しているソフトウェア内の既知の脆弱性に対処します。しかし、自社のコードベースには未知の脆弱性が含まれています。長期間稼働している本番コードのほとんどは人間によって何度もレビューされていますが、フロンティアモデルによる検査は一度も受けておらず、その種の分析は新しく、これまで見過ごされていた問題を表面化させる傾向があります。積極的なスキャンによって、攻撃者自身が発見する前に、最新のLLMが到達可能な脆弱性を特定できます。
露出度で優先順位をつける。信頼できない入力を解析するコード、認証や認可の決定を実施するコード、インターネットから到達可能なコードから始めてください。これらは、検出結果が最も重要になり得る経路です。
レガシーコードを含める。現在のレビュー手法が確立される前に書かれたコード、またはオリジナルの開発者が既にいなくなったコードは、多くの場合、最も最近の精査を受けていません。そこから新たな検査で得られるものが最も多いのです。
修正のための予算を確保する。構造化されたモデルによる古いコードのスキャンは、通常、SASTの導入よりも検出結果が少なくなりますが、その中で実際の脆弱性である割合は高くなります。バグを修正するためのエンジニアリング時間を計画してください。
実践的なヒント：現在の所有者が少ないインターネットに接するサービスを1つ選び、その入力処理と認証ロジックをスキャンしてください。エージェントを隔離環境で実行し、確認済みの検出結果に対してのみ行動するよう、検証ステップを追加します。1つのサービスを適切に行うことは、より広範なプログラムのコストを見積もるための合理的な基礎となります。
- 侵害を前提に設計する
攻撃者はどこかに足場を得ようと試みます。あなたは、彼らがそこから到達できるものを制限する必要があります。
摩擦（攻撃を面倒にすること）によって価値をもたらす緩和策（追加の踏み台ホップ、レート制限、非標準ポート、SMSベースのMFA（多要素認証））は、その面倒なステップを地道に進むことができる敵対者に対しては、はるかに効果が低くなります。以下の私たちの推奨事項は、攻撃者が無限の忍耐力を持っている場合でも有効なコントロールを重視します：ハードウェアに紐づく認証情報、有効期限付きトークン、単に不便なだけでなく存在しないネットワーク経路です。
ゼロトラストアーキテクチャを採用する。サービス間のすべてのリクエストを、あたかもインターネットから来たかのように認証・認可します。CISA（米国サイバーセキュリティ・インフラストラクチャセキュリティ庁）のゼロトラスト成熟度モデルとNCSC（英国国家サイバーセキュリティセンター）のゼロトラスト原則は、いずれも段階的な導入パスを提供しています。
認証情報ではなく、検証済みハードウェアにアクセスを紐づける。本番システムと機密性の高い内部ツールは、証明されたハードウェアイデンティティを持つ管理された従業員デバイスから、フィッシング耐性のある2FA（FIDO2またはパスキー）と組み合わせてのみ到達可能であるべきです。盗まれた認証情報だけでは決してアクセスを得られないようにすべきです。本番サービス間の呼び出しでさえ、ハードウェアイデンティティに基づくべきです。
アイデンティティによってサービスを分離する。侵害されたビルドサーバーが本番データベースをクエリできないようにすべきです。侵害されたラップトップがビルドインフラに到達できないようにすべきです。これは受信側で強制します：すべてのワークロードは独自の暗号化アイデンティティを運び、各サービスはそのポリシー名で指定された特定の呼び出し元からの接続のみを受け入れるべきです。ネットワークセグメンテーションは依然として被害範囲とノイズを減らすことができますが、それは最後の防衛線です。
長期間有効なシークレットを短時間有効なトークンに置き換える。静的APIキー、埋め込み認証情報、共有サービスアカウントのパスワードは、モデル支援コード分析を行う攻撃者が最初に見つけるものの一つです。アイデンティティプロバイダーによって発行される、短時間有効で狭いスコープのトークンを使用してください。
実践的なヒント：完全なゼロトラストは複数年にわたるプログラムですが、アイデンティティを認識するアクセスプロキシは、内部サービスのアーキテクチャを根本的に変更することなく、その前にデバイス検証済み、MFAゲート付きのアクセスを配置します。各主要クラウドプロバイダーはネイティブオプションを提供しており、オンプレミスまたはマルチクラウド環境向けにいくつかのオープンソースおよび商用の代替手段が存在します。シークレットについては、すべての主要クラウドにはマネージドシークレットストアがあります。最も広く共有されている単一の認証情報をその中に移動させ、それをローテーションすることは、残りの部分に対する有用な強制力となります。
- 公開しているものを削減し、目録を作成する
このセクションは、2つの重要な原則に基づいています。第一に、知らないシステムは防御できません。第二に、露出した表面が小さければ小さいほど、攻撃対象は少なくなります。
システム内のすべてのインターネットに接するホスト、サービス、APIエンドポイントの最新の目録を維持してください。攻撃者は自動化された偵察を実行できます。あなたの目録は少なくともそれと同じくらい正確であるべきです。これらのシステムをペネトレーションテストやレッドチーミングに含めてください。
使用されていないシステムを廃止する。明確な所有者がいないレガシーサービスは、通常、パッチも適用されていません。
各サービスが公開するものを最小限にする。ネットワークイングレスはデフォルト拒否とし、APIの表面積を実際に必要なものに制限してください。
実践的なヒント：インターネット全体のスキャンインデックスは公開検索可能です。自社のIP範囲とドメインに対してそれをクエリすることで、攻撃者の偵察が何を見ているかがわかります。クラウド資産については、ネイティブの目録ツール（AWS Config、Azure Resource Graph、GCP Asset Inventory）が既に存在します。作業はそれらをクエリすることです。
AIはここでも直接的に役立ちます：
古くなったコードとシステムの剪定。使用されていないコードの特定は面倒ですが、上記のように、AIモデルは面倒なタスクが得意です。コードベースとトラフィックログへの読み取りアクセス権を持つモデルは、呼び出し元がなく、トラフィックを受け取っていないエンドポイントをリストアップできます。そこから、各エンドポイントを削除すると何に影響するかを説明できます。
自律的な外部レッドチーミング。AI攻撃エージェントを、認証情報もソースコードへのアクセスもなしに、外部から自社の境界に対して向けます。そして、攻撃者がするであろうことをさせます：到達可能なものを把握し、フィンガープリントを採取し、見つけたものを連鎖させて足場を得ようと試みます。この種の自動化されたレッドチーミングは、ソースコードスキャンでは見えないもの（忘れられたホスト、公開された管理インターフェース、デフォルト認証情報、設定ミスされたストレージ）を捕捉できます。目録の更新と同じ頻度で実行してください。
- インシデント対応時間を短縮する
エクスプロイトはパッチ公開から数時間以内に出現することがあります。数日かかる対応プロセスは遅すぎます。以下は、インシデント対応時間を短縮する方法についてのいくつかのアイデアです：
アラートキューの先頭にモデルを配置する。すべての受信アラートは、人間が目にする前に自動化された一次調査を受けるべきです。SIEM（セキュリティ情報イベント管理）プラットフォームへの読み取り専用アクセスと、適切にスコープされた一連のクエリツールを持つこの種の「トリアージエージェント」は、人間の判断を最も必要とするアラートに注意を向けさせることができます。
インストルメントの滞在時間とカバレッジを何よりも優先する。これらは、AI自動化が最も大きく動かす能力を持つ2つの指標です。どちらも、エクスプロイトの窓が短くなるほど重要になります。
インシデント周辺の事務作業を自動化する。アクティブなインシデント中、モデルはメモを取ったり、証拠を収集したり、並行調査トラックを追求したり、事後分析や根本原因分析の草案を作成したりすべきです。一方、人間は封じ込めの判断、開示の判断、顧客対応の判断を行うべきです。インシデント中の人間の意思決定速度は、証拠収集や文書作成など、AIに任せた方が良い側面で制限されるべきではありません。
モデルに検知のフライホイールを駆動させる。脅威インテリジェンスの取り込み、候補検知ルールの生成、一致の探索、発火するものの調整は、すべて現在フロンティアモデルの到達範囲内にあり、エンドツーエンドでプロセスを実行できます。
5つの同時インシデントでテーブルトップ演習を実行する。標準的な演習は、動作するエクスプロイトを伴う1つの重大なCVE（共通脆弱性識別子）が月曜日に発生することを想定しています。私たちが目にしているAI能力の向上を考えると、これは賢明ではないかもしれません。対応を真にストレステストするには、同じ週に5つのインシデントが発生するバージョンを実行すべきです。
検知カバレッジをMITRE ATT&CKに対してマッピングする。ATT&CKは、ほとんどの検知ツールが既に使用している攻撃者技術の標準語彙を提供します。どの技術を検知できるか（そしてできないか）を知ることは、「検知を改善する」という一般的な目標よりも有用です。横移動と認証情報アクセスに対するカバレッジを優先すべきです。
緊急変更手順を事前に確立する。本番パッチに対する2週間の変更承認サイクル自体がセキュリティリスクです。緊急封じ込めアクション（サービスをオフラインにする、認証情報をローテーションする、ネットワーク経路をブロックするなど）にも同じことが当てはまります。誰がこれらを承認でき、どのくらいの速さで行えるかを事前に決定すべきです。
実践的なヒント：既知の高い誤検知率を持つノイジーなルールを1つ選んでください。フロンティアモデルをそのアラートストリームに、基盤データへの読み取り専用アクセス権で配線し、発火ごとに構造化された処置を生成させます。2週間、人間のレビュアーとの一致率を測定します。一致率が許容できるものであれば、次のルールに拡大します。キューの全体を一度に自動化しようとする価値はありません。別途、Atomic Red TeamはATT&CK技術にマッピングされた小さく安全なテストのオープンソースライブラリです。それをいくつか実行し、既存のロギングが実際にどれを検知したかを確認することは、具体的なカバレッジマップを生成する半日の演習です。
以下は、AIが対応時間の短縮に役立ついくつかの方法です：
100%カバレッジでの一次トリアージ。適切にスコープされたトリアージエージェントは、すべてのアラート（人間は特定の重大度閾値以上のものしか見ないかもしれない）を調査し、人間が承認、却下、エスカレートできる構造化された処置を生成できます。これを機能させるメカニズムは、モデルに最小限のツールセット（クエリ、思考、報告）を与え、独自の調査戦略を選択させ、出力を運用指標に対して測定することです。
インシデント記録係および並行調査担当者。アクティブなインシデント発生中、モデルは同時進行でメモを取り、収集された証拠にタイムスタンプを付け、対応者がまだ着手していない独立した調査経路を追求し、インシデント終了後にトランスクリプトから事後分析レポートを起草することができます。これはフロンティアモデルをセキュリティ作業に適用する最も地味な用途ですが、おそらく最も影響力の高いものです。
自社環境に対する積極的なハンティング。ソースコード内の脆弱性を見つけられるのと同じ種類のエージェントが、テレメトリデータ全体で設定ミスや侵害の痕跡を探すことができます。外部攻撃対象領域スキャンと同じ頻度で実行できます。
他者への脆弱性レポート提出に関するアドバイス
コード（自社の依存関係、オープンソースプロジェクト、ベンダー製品）をスキャンし、発見事項を上流に報告する場合、それらのレポートの質は誰かが対応するかどうかを決定します。オープンソースのメンテナーはすでに大量の低品質な自動レポートを受信しており、多くの人はAI生成に見えるものは無視し始めています。信号を増やさずに量だけ増やすことは、あなたを含むすべての人にとって問題を悪化させます。
レポートは、人間が検証し、自分の名前を掲げる意思がある場合にのみ送信されるべきです。具体的には：
バグとその影響を平易な言葉で説明する。メンテナーは最初の段落から、何が悪いのか、なぜ重要なのかを、何も実行せずに理解できるべきです。
コードパスを順を追って説明する。入力がどこから入り、どこで誤って処理され、どこで結果が発生するかを示します。これは、パターンマッチングではなく実際の発見を区別する部分です。
動作する再現手順を提供する。メンテナーが実行できる概念実証、または失敗するテストケースは、どんな説明よりも信頼性があります。
もし自分がメンテナーなら受け入れるであろう修正パッチを含める。パッチは、報告者がプロジェクトの慣習に合った方法で問題を修正できるほどコードベースを理解していることを示します。
AIの関与を最初に開示する。モデルがバグを発見したりレポートを起草したりした場合は、最初の行でその旨を述べてください。メンテナーはどうせ気づきます。隠すことは開示するよりも信頼性を大きく損ないます。
メンテナーの判断を尊重する。彼らがレポートを却下した場合、それを受け入れるべきです。協力しやすいことから生まれる善意は、一つのバグに関する議論に勝つことよりも価値があります。
実用的なヒント：脆弱性レポートを送信する前に有用なセルフチェックは、エディタを閉じて記憶からバグを説明することです。モデルの出力を参照せずに何が悪いのか説明できない場合、それを報告するほど十分に理解していません。
セキュリティチームがない場合
上記のアドバイスのほとんどは、組織に専任のセキュリティ機能があることを前提としています。小規模組織、単独の開発者、またはオープンソースメンテナーの場合、同じリスクが適用されますが、対応はよりシンプルです：
オペレーティングシステム、ブラウザ、および提供するすべてのアプリケーションの自動更新を有効にする。これは利用可能な最も効果的な単一のアクションであり、継続的な努力を必要としません。
セルフホスティングよりもマネージドサービスを優先する。セキュリティチームを持つプロバイダーにデータベース、認証、メールを実行させることで、パッチ適用の負担を彼らに移せます。このようなマネージドサービスのコストは、1件のインシデントのコストよりもほぼ常に低くなります。
対応するすべてのアカウントでパスキーまたはハードウェアセキュリティキーを使用する。SMSコードは傍受される可能性があり、パスワードは使い回されます。ハードウェアキーはフィッシングの対象になりません。
コードホストの無料セキュリティツールを有効にする。GitHubのDependabot、シークレットスキャン、CodeQLはパブリックリポジトリで無料であり、エンタープライズツールが検出するもののかなりの部分を捕捉します。有効化には数分しかかかりません。
オープンソースプロジェクトをメンテナンスしている場合は、SECURITY.mdを公開してください。
パッチ優先順位付け
CISA KEVカタログ、FIRST EPSS、CISA BOD 22-01
ベースラインコントロール
ACSC Essential Eight、CISA CPGs、CIS Controls v8、NCSC 10 Steps
セキュア開発
NIST SSDF（SP 800-218）、OWASP ASVS、OWASP SAMM、CISA Secure by Design
CISA/NSAメモリ安全ロードマップ
サプライチェーンおよびビルド完全性
SLSA、OpenSSF Scorecards、CISA SBOMリソース、NIST SP 800-161
CISAゼロトラスト成熟度モデル、NIST SP 800-207、NCSCゼロトラスト原則
検知および対応
MITRE ATT&CK、MITRE D3FEND
プログラムフレームワーク
NISTサイバーセキュリティフレームワーク2.0、NCSCサイバー評価フレームワーク
謝辞
この記事は、Anthropicのセキュリティエンジニアリングおよびリサーチチームのメンバー（Donny Greenberg、Jason Clinton、Michael Moore、Abel Ribbink、Jackie Bowを含む）によって執筆され、Jannet Park、Gabby Curtis、Stuart Ritchieの貢献を受けました。
PrevPrev0/5NextNexteBook
Claudeで構築するチーム向けの製品ニュースとベストプラクティスをもっと探す。
マルチエージェント調整パターン：5つのアプローチと使用タイミング
エージェントマルチエージェント調整パターン：5つのアプローチと使用タイミングマルチエージェント調整パターン：5つのアプローチと使用タイミングマルチエージェント調整パターン：5つのアプローチと使用タイミングマルチエージェント調整パターン：5つのアプローチと使用タイミング  catalog immediately. This catalog contains vulnerabilities that are confirmed to be under active exploitation. Anything on this list which is reachable from a network should be treated as an emergency.
Use EPSS to prioritize the rest. Exploit Prediction Scoring System (EPSS) provides a daily-updated probability that a given Common Vulnerability and Exposure (CVE) will be exploited in the next 30 days. Patching the KEV list first and then everything above a chosen EPSS threshold will help you turn thousands of open CVEs into a manageable queue.
Reduce time-to-patch on internet-exposed systems. We recommend patching internet-facing applications within 24 hours of an exploit becoming available, and within days for other vulnerabilities.
Automate patch deployment and reboots where the risk of an automated update causing an outage is acceptable. Manual approval steps add delay, and delay is now the primary risk.
Practical tip: Most cloud and OS vendors already ship patch automation; enabling it is often a simple configuration change. For container images and dependency manifests, several open-source scanners run as a single continuous integration step and annotate CVEs with data from the KEV catalogue and EPSS, so prioritization is built in.
- Prepare to handle a much higher volume of vulnerability reports
Over approximately the next two years, the processes you use to receive, prioritize, and fix vulnerabilities (both in your own code and in the software you buy from vendors) will be under far more pressure than they are today. Your Vulnerability Management process should plan for many more patches, from vendors and upstream.
Plan for an order-of-magnitude increase in finding volume. Aspects like intake, triage, and remediation tracking need to keep pace with the increasing numbers of vulnerabilities being exposed. If your security meetings are still built around a spreadsheet and a weekly meeting, it’s unlikely that you’ll keep up. It’s worth considering some amount of automation—with, of course, humans in the loop, to assist with the sheer volume here.
Check the security of your open-source dependencies. Most software supply chains are mostly open source. Most open-source projects have no service-level agreement or commitment to maintain a high level of security. OpenSSF Scorecard automatically scores every dependency on signals like branch protection, fuzzing coverage, signed releases, and maintainer activity. It runs in CI and helps to identify unmaintained packages.
Apply the same expectations to your vendors. Your third-party risk management process should ask suppliers how they are themselves preparing for accelerated exploit timelines and whether they are scanning their own code.
Practical tip: Look into open source software and third-party services that evaluate the reachability of vulnerable code. Build automated processes that continuously deliver new software updates to your IT and production infrastructure, by doing regression testing on updates to gain confidence that you can deploy them quickly.
Above we mentioned automation of these processes. There are a number of important ways that AI can assist:
Speeding up triage Triage is a bottleneck, because it requires expert review and classification. A frontier model can deduplicate findings against an existing backlog, use its knowledge of your assets to estimate exposure, and draft remediation tickets where the affected code paths are pre-identified.
Check your dependencies for redundancy. Most large codebases accumulate multiple libraries doing the same job (several HTTP clients; several JSON parsers). This gives attackers more opportunity, all for no functional gain on your part. Pointing an LLM at a lockfile and asking which dependencies overlap (and what migration and consolidation would look like) is a one-hour exercise that often pays off.
AI upgrade automation. Frontier models are increasingly capable of generating patches to include alongside vulnerability reports. When the report is clear and thorough, maybe even with a proof-of-concept, the model can directly test the patch to confirm that the exploit path is closed. It can also directly automate the process of accepting the upstream patch, validating that the upgrade doesn’t break tests or internal systems.
AI vendoring. Some small dependencies will score poorly on the OpenSSF Scorecard—perhaps because they’re not actively maintained. You shouldn’t continue to rely on these; instead, you should consider having an LLM write its own code to reimplement the functionality you actually use.
- Find bugs before you ship them
Prevention is always better than cure. You should assume that bugs that reach production will eventually be found, so your security testing needs to happen well before.
Add static analysis and AI-assisted code review to your continuous integration pipeline, and block merges on high-confidence findings. If false positives make this impractical, you should keep the check, but address the tooling. The OWASP Application Security Verification Standard defines what “passing” a test looks like at three different levels of rigor.
Add automated penetration testing to your continuous delivery pipeline. You can run the same scanning for staging that attackers will run against your production systems.
Secure the build pipeline. An attacker who can inject code between commit and deployment does not need to find a vulnerability. The SLSA security framework provides a graded path: lower levels establish which commit produced which artifact, and higher levels make the build itself verifiable.
Adopt Secure by Design practices. CISA’s pledge commitments (multi-factor authentication by default; no default passwords; transparent vulnerability reporting) are a reasonable minimum bar.
Prefer memory-safe languages for new code. A large share of severe vulnerabilities are memory-safety bugs that do not occur in Rust, Go, or managed runtimes. CISA, the NSA, and the NCSC have published useful roadmaps. Existing C/C++ code does not need to be rewritten, but new C/C++ code should require a justification. AI assisted rewrites are increasingly viable, as well.
Practical tip: Static application security testing (SAST) tooling that runs as a CI action with OWASP Top 10 and language-specific rule sets is widely available, both open-source and built into code hosting platforms (CodeQL on GitHub being the most common starting point). To assess build provenance, OpenSSF publishes a reusable workflow that produces SLSA Level 3 attestations from GitHub Actions; adopting it is significantly less work than the SLSA spec suggests.
As before, there are some clear opportunities for accelerating this work with AI:
AI vulnerability scanning. The logic here is straightforward: you should scan your own code and systems with the same kind of model an attacker would use, before they do. This approach just requires an isolated agent, a verification step to filter noise, and a path into your existing triage process. You can do this with an LLM today. If you implement one thing from this section, implement this.
Patch generation. When SAST or a scanner produces a finding, a frontier model can usually propose a patch for it. This does not remove the need for review, but it changes the developer’s job from “understand the bug and write a fix” to “verify a proposed fix is correct.” The latter is faster. The same approach applies to memory-safe migration: LLMs can port a self-contained C module to Rust with tests; a reviewer can validate the equivalence rather than writing the whole thing from scratch.
- Find the vulnerabilities already in your code
Patching addresses known vulnerabilities in software you depend on. But your own codebase contains unknown ones. Most long-running production code has been reviewed by humans many times, but has never been examined by a frontier model, and that kind of analysis tends to surface new, previously-overlooked issues. Proactively scanning can identify vulnerabilities that are within the reach of modern LLMs before attackers discover them themselves.
Prioritize by exposure. Start with code that parses untrusted input, enforces an authentication or authorization decision, or is reachable from the internet. These are the paths where a finding is most likely to matter.
Include legacy code. Code that predates current review practices, or whose original authors have moved on, often has the least recent scrutiny. That’s where you have the most to gain from a fresh pass.
Budget for remediation. A well-structured model scan of older code typically produces fewer findings than a SAST rollout, but a higher share of them are real. Plan engineering time to fix the bugs.
Practical tip: Pick one internet-facing service with few current owners and scan its input handling and auth logic. Run the agent in isolation and add a verification step so you’re acting on confirmed findings. One service done properly is a reasonable basis for estimating what a broader program will cost.
- Design for breach
Attackers will try to get a foothold somewhere. You need to limit what they can reach from there.
Mitigations whose value comes from friction—making an attack tedious—rather than a hard barrier (extra pivot hops, rate limits, non-standard ports, SMS-based MFA) are much less effective against an adversary that can grind through those tedious steps. Our recommendations below favor controls that hold even when the attacker has unlimited patience: hardware-bound credentials, expiring tokens, and network paths that do not exist rather than paths that are merely inconvenient.
Adopt zero trust architecture. Authenticate and authorize every request between services as if it came from the internet. CISA's Zero Trust Maturity Model and the NCSC's zero trust principles both provide staged adoption paths.
Tie access to verified hardware rather than credentials. Production systems and sensitive internal tools should only be reachable from managed employee devices with attested hardware identity, paired with phishing-resistant 2FA (FIDO2 or passkeys). Stolen credentials alone should never be sufficient to gain access. Even calls between production services should be rooted in hardware identity.
Isolate services by identity. A compromised build server should not be able to query production databases. A compromised laptop should not be able to reach build infrastructure. Enforce this at the receiving end: every workload should carry its own cryptographic identity, and each service should accept connections only from the specific callers of its policy names. Network segmentation can still reduce blast radius and noise, but it is a backstop.
Replace long-lived secrets with short-lived tokens. Static API keys, embedded credentials, and shared service-account passwords are among the first things an attacker with model-assisted code analysis will find. Use short-lived, narrowly-scoped tokens issued by an identity provider.
Practical tip: Full zero-trust is a multi-year program, but an identity-aware access proxy puts device-verified, MFA-gated access in front of internal services without having to fundamentally change their architecture. Each major cloud provider offers a native option, and several open-source and commercial alternatives exist for on-premises or multi-cloud environments. For secrets, every major cloud has a managed secrets store; moving the single most widely-shared credential into one and rotating it is a useful forcing function for the rest.
- Reduce and inventory what you expose
This section is based on two important principles. First, you cannot defend systems you don’t know about. Second, the smaller the exposed surface, the less there is to attack.
Maintain a current inventory of every internet-facing host, service, and API endpoint in your systems. Attackers can run automated reconnaissance; your inventory should be at least as accurate. Include these systems in your pentests and red-teaming.
Decommission unused systems. Legacy services with no clear owner are typically also unpatched.
Minimize what each service exposes. Default-deny network ingress and limit API surface area to what is actually required.
Practical tip: Internet-wide scan indexes are publicly searchable; querying one for your own IP ranges and domains shows you what an attacker’s reconnaissance sees. For cloud assets, native inventory tools (AWS Config, Azure Resource Graph, GCP Asset Inventory) already exist; the work is in querying them.
AI can help directly here, too:
Pruning stale code and systems. Identifying unused code is tedious—but as noted above, AI models are good at tedious tasks. A model with read access to a codebase and traffic logs can list endpoints that have no callers and have not received traffic; from there, it can explain what removing each one would affect.
Autonomous external red-teaming. Point an AI offensive agent at your own perimeter from the outside, with no credentials and no source access. Then, let it do what an attacker would: work out what is reachable, fingerprint it, and attempt to chain what it finds into a foothold. This kind of automated red-teaming can catch things source scanning doesn’t see: forgotten hosts, exposed management interfaces, default credentials, and misconfigured storage. Run it on the same cadence as your inventory refresh.
- Shorten your incident response time
Exploits can appear within hours of a patch. Response processes that take days are too slow. Here are some ideas for how to reduce your incident response time:
Put a model at the front of your alert queue. Every inbound alert should get an automated first-pass investigation before a human sees it. This kind of “triage agent” with read-only access to your Security Information and Event Management (SIEM) platform and a well-scoped set of query tools can direct your attention to the alerts that need human judgement most.
Put instrument dwell time and coverage before anything else. These are the two metrics that AI automation has the greatest ability to move; both matter most when exploit windows shorten.
Automate the bookkeeping around incidents. During an active incident, models should be taking notes, capturing artifacts, pursuing parallel investigation tracks, and drafting the postmortem and root-cause analysis. On the other hand, humans should be making the containment calls, disclosure calls, and customer-comms calls. Human decision speed during an incident should never be rate-limited on aspects that would be better handed to an AI, like evidence collection or write-ups.
Let models drive the detection flywheel. Ingesting threat intelligence, generating candidate detections, hunting for matches, and tuning what fires are all now within reach of frontier models, who can run the process end-to-end.
Run a tabletop for five simultaneous incidents. The standard exercise assumes one critical CVE with a working exploit hits on a Monday. Given the improved AI capabilities we’re seeing, this might be unwise. To truly stress-test your responses, you should run the version where five incidents hit in the same week.
Map detection coverage against MITRE ATT&CK. ATT&CK provides a standard vocabulary of attacker techniques that most detection tools already use. Knowing which techniques you can detect (and which you can’t), is more useful than a general goal to “improve detection.” You should prioritize coverage for lateral movement and credential access.
Establish emergency change procedures in advance. A two-week change-approval cycle for production patches is itself a security risk. The same applies to emergency containment actions (like taking a service offline, rotating a credential, or blocking a network path). You should decide in advance who can authorize these and how fast.
Practical tip: Pick one noisy rule with a known-high false positive rate. Wire a frontier model into its alert stream with read-only access to the underlying data, and have it produce a structured disposition for every firing. Measure agreement against a human reviewer for two weeks. If the agreement rate is tolerable, expand to the next rule. It’s not worth trying to automate the whole queue at once. Separately, Atomic Red Team is an open-source library of small, safe tests mapped to ATT&CK techniques; running a handful and checking which ones your existing logging actually detected is a one-afternoon exercise that produces a concrete coverage map.
Here are some ways AI can assist with response times:
First-pass triage at 100% coverage.A well-scoped triage agent can investigate every alert (where humans might look only at those above a given severity threshold), and produce a structured disposition a human can accept, reject, or escalate. The mechanism that makes this work is giving your model a minimal tool set (query, think, report), letting it choose its own investigation strategy, and measuring the output against operational metrics.
Incident scribe and parallel investigator. During an active incident, a model can take contemporaneous notes, timestamp artifacts as they are collected, pursue independent investigation tracks the responder has not gotten to yet, and draft the postmortem from the transcript once the incident closes. This is the least glamorous application of frontier models to security work—but it’s probably the highest-impact one.
Proactive hunting against your own environment. The same kind of agent that can find vulnerabilities in source code can hunt for misconfigurations and indicators of compromise across your telemetry. You can run it on the same cadence as your external attack-surface scan.
Advice for submitting vulnerability reports to others
If you are scanning code—your own dependencies, open-source projects, or vendor products—and reporting findings upstream, the quality of those reports determines whether anyone acts on them. Open-source maintainers are already receiving large volumes of low-quality automated reports, and many have started ignoring anything that looks AI-generated. Adding to that volume without adding signal makes the problem worse for everyone, including you.
A report should be sent only when a human has verified it and is willing to put their name on it. Concretely:
State the bug and its impact in plain language. A maintainer should be able to understand what is wrong and why it matters from the first paragraph, without running anything.
Walk through the code path. Show where the input enters, where it is mishandled, and where the consequence occurs. This is the part that distinguishes a real finding from a pattern match.
Provide a working reproduction. A proof-of-concept the maintainer can run, or a test case that fails, is more credible than any amount of explanation.
Include a proposed patch you would accept if you were the maintainer. A patch demonstrates that the reporter understands the codebase well enough to fix the problem in a way that fits the project’s conventions.
Disclose AI involvement upfront. If a model found the bug or drafted the report, say so in the first line. Maintainers will find out anyway; concealing it costs more credibility than disclosing it.
Defer to the maintainer's judgment. If they decline the report, you should make peace with that. The goodwill from being easy to work with is worth more than winning an argument over one bug.
Practical tip: A useful self-check before sending a vulnerability report is to close the editor and explain the bug from memory. If you cannot describe what goes wrong without referring back to the model output, you do not understand it well enough to report it.
If you don’t have a security team
Most of the above advice assumes that your organization has a dedicated security function. If you are a small organization, a solo developer, or an open-source maintainer, the same risks apply but the actions are simpler:
Turn on automatic updates for your operating system, browser, and every application that offers it. This is the single most effective action available and requires no ongoing effort.
Prefer managed services over self-hosting. Letting a provider with a security team run the database, authentication, and email shifts the patching burden to them. The cost of a managed service like this is almost always lower than the cost of one incident.
Use passkeys or hardware security keys on every account that supports them. SMS codes can be intercepted and passwords get reused; a hardware key cannot be phished.
Enable the free security tooling on your code host. GitHub's Dependabot, secret scanning, and CodeQL are free for public repositories and catch a meaningful share of what enterprise tools catch. Enabling them takes minutes.
If you maintain an open-source project, publish a SECURITY.md
Patch prioritization
CISA KEV Catalog, FIRST EPSS, CISA BOD 22-01
Baseline controls
ACSC Essential Eight, CISA CPGs, CIS Controls v8, NCSC 10 Steps
Secure development
NIST SSDF (SP 800-218), OWASP ASVS, OWASP SAMM, CISA Secure by Design
CISA/NSA Memory Safe Roadmaps
Supply chain & build integrity
SLSA, OpenSSF Scorecards, CISA SBOM resources, NIST SP 800-161
CISA Zero Trust Maturity Model, NIST SP 800-207, NCSC Zero Trust Principles
Detection & response
MITRE ATT&CK, MITRE D3FEND
Program framework
NIST Cybersecurity Framework 2.0, NCSC Cyber Assessment Framework
Acknowledgements
This article was written by members of Anthropic’s Security Engineering and Research teams, including Donny Greenberg, Jason Clinton, Michael Moore, Abel Ribbink, and Jackie Bow, with contributions from Jannet Park, Gabby Curtis, and Stuart Ritchie.
PrevPrev0/5NextNexteBook
Explore more product news and best practices for teams building with Claude.
Multi-agent coordination patterns: Five approaches and when to use them
AgentsMulti-agent coordination patterns: Five approaches and when to use themMulti-agent coordination patterns: Five approaches and when to use themMulti-agent coordination patterns: Five approaches and when to use themMulti-agent coordination patterns: Five approaches and when to use them ![](https://cdn.prod.website-files.com/68a44d4040f98a4adf2207b6/6903d230e0a787df988a8558_97cf99624aa60f59b75f9e08cdf0f00d33c348
関連記事
2026年3月6日 Frontier Red TeamによるClaudeのCVE-2026-2796エクスプロイトのリバースエンジニアリング
Frontier Red Teamが、Claudeの脆弱性CVE-2026-2796を悪用するエクスプロイトをリバースエンジニアリングした。
フロンティア・レッドチーム、Firefoxのセキュリティ向上のためにMozillaと提携
フロンティア・レッドチームは、Firefoxのセキュリティを向上させるため、Mozillaと提携した。
59％のユーザーがより安価なモデルを選択：Sonnet 4.6の詳細解説
Anthropic社がClaude Sonnet 4.6をリリースし、Claude Codeテストで70％のユーザーが前世代モデルより好み、59％がフラッグシップモデルOpus 4.5よりも選択した。コーディング、コンピュータ利用、100万トークンコンテキストなど6次元で全面アップグレードされ、価格は据え置き。