AI が加速させる攻撃に備えてセキュリティプログラムを整える

今週初め、私たちは Project Glasswing を発表しました。これは、最新のフロンティアモデル Claude Mythos Preview が持つ強力なサイバーセキュリティ能力を防御目的に活用しようとする緊急の取り組みです。発表記事および技術ブログ記事では、AIモデルがソフトウェアの脆弱性を発見し悪用するために必要なリソース、時間、スキルを急速に削減していることを説明しました。

AIの急速な進歩を見据えると、同様の能力レベルを持つモデルが広く利用可能になるまでそう長くはかかりません。今後24か月以内に、おそらく何年もコードの中で見過ごされてきた膨大な数のバグがAIモデルによって発見され、動作するエクスプロイトに連鎖されるでしょう。実際、公開されている Mythos 未満レベルのモデルでも、従来のレビューが長期間見逃してきた深刻な脆弱性を発見できる状況がすでに生まれています。

幸いなことに、これは両方向に作用します。攻撃者がAIを使ってより速く動けるように、AIツールを採用してセキュリティを確保する防御者もまたより速く動けるのです。この記事では、私たちのセキュリティチームと研究者が、フロンティアAIモデルを使って実際のコードベースやシステムを保護する中で観察し学んだことに基づいて、セキュリティに関する推奨事項と実践的なヒントを提供します。AIドリブンのサイバーセキュリティの時代に入るにあたり、セキュリティチームやその他の方々にとって、このアドバイスが役立つことを願っています。

以下のアドバイスの多くは、すでに既存のセキュリティのコンセンサスに含まれているものです。私たちは、どのコントロールが持ちこたえ、どのコントロールが劣化したかの観察に基づいて優先順位付けを行いました。もし組織が SOC 2 や ISO 27001 に準拠して報告しているのであれば、これらはすでに追跡しているコントロールに直接マッピングされます。

私たちと Project Glasswing のパートナーがサイバーセキュリティの取り組みを継続するにつれて、このガイダンスを更新していきます。

今すぐやるべきこと

1. パッチギャップを解消する

AIモデルは、パッチ未適用のシステムにおいて、既知のパッチ済み脆弱性のシグネチャを認識することに非常に長けています。パッチをリバースして動作するエクスプロイトにすることは、まさにこれらのモデルが得意とする機械的な分析です。つまり、パッチが公開されてからエクスプロイトが利用可能になるまでの時間的猶予が縮小しているということです。

• CISA Known Exploited Vulnerabilities (KEV) catalog に掲載されているものはすべて直ちにパッチを適用してください。 このカタログには、現在活発に悪用されていることが確認された脆弱性が掲載されています。このリストに載っていてネットワークから到達可能なものは、すべて緊急事態として扱うべきです。
• 残りの優先順位付けには EPSS を使用してください。 Exploit Prediction Scoring System (EPSS) は、特定の Common Vulnerability and Exposure (CVE) が今後30日以内に悪用される確率を日次で更新・提供しています。KEVリストを最初にパッチし、次に選択した EPSS 閾値を超えるものをすべてパッチすることで、何千もの未対応 CVE を管理可能なキューに変えることができます。
• インターネットに公開されたシステムのパッチ適用時間を短縮してください。 エクスプロイトが利用可能になってから24時間以内にインターネットに面したアプリケーションにパッチを適用し、その他の脆弱性については数日以内に適用することを推奨します。
• 自動アップデートによる障害リスクが許容できる場合は、パッチのデプロイと再起動を自動化してください。 手動の承認ステップは遅延を生みますが、今や遅延こそが主要なリスクです。

実践的なヒント: ほとんどのクラウドおよびOSベンダーはすでにパッチ自動化を提供しており、有効にするのは多くの場合、簡単な設定変更です。コンテナイメージや依存関係マニフェストについては、CIの単一ステップとして実行され、KEVカタログやEPSSのデータでCVEにアノテーションを付けるオープンソースのスキャナーが複数あるため、優先順位付けが組み込まれています。

2. はるかに大量の脆弱性レポートへの対応を準備する

今後およそ2年間で、脆弱性の受付、優先順位付け、修正に使用しているプロセス（自社コードと購入したソフトウェアの両方）は、現在よりもはるかに大きなプレッシャーにさらされます。脆弱性管理プロセスは、ベンダーやアップストリームからのパッチの大幅な増加に備える必要があります。

• 発見件数の桁違いの増加に備えてください。 インテーク、トリアージ、改善の追跡は、増加する脆弱性の数に対応する必要があります。セキュリティミーティングがいまだにスプレッドシートと週次ミーティングを中心に構築されている場合、対応しきれなくなる可能性が高いです。もちろん人間をループに含めた上で、この膨大な量を処理するためにある程度の自動化を検討する価値があります。
• オープンソース依存関係のセキュリティを確認してください。 ほとんどのソフトウェアサプライチェーンは、大部分がオープンソースです。ほとんどのオープンソースプロジェクトには、高いセキュリティレベルを維持するためのサービスレベルアグリーメントやコミットメントがありません。OpenSSF Scorecard は、ブランチ保護、ファジングカバレッジ、署名済みリリース、メンテナーの活動状況などのシグナルですべての依存関係を自動的にスコアリングします。CIで実行され、メンテナンスされていないパッケージの特定に役立ちます。
• ベンダーにも同じ期待を適用してください。 サードパーティリスク管理プロセスでは、サプライヤーが加速するエクスプロイトのタイムラインにどのように備えているか、自社のコードをスキャンしているかを確認すべきです。

実践的なヒント: 脆弱なコードの到達可能性を評価するオープンソースソフトウェアやサードパーティサービスを調べてみてください。アップデートに対するリグレッションテストを行い、迅速にデプロイできるという確信を得ることで、ITや本番インフラに新しいソフトウェアアップデートを継続的にデリバリーする自動化プロセスを構築しましょう。

上記ではこれらのプロセスの自動化について言及しました。AIが支援できる重要な方法がいくつかあります。

• トリアージの高速化。 トリアージは、専門家のレビューと分類が必要なため、ボトルネックです。フロンティアモデルは、既存のバックログに対して発見事項を重複排除し、資産に関する知識を使って露出度を推定し、影響を受けるコードパスが事前に特定された改善チケットを起案できます。
• 依存関係の冗長性をチェック。 ほとんどの大規模コードベースでは、同じ役割を持つ複数のライブラリが蓄積されます（複数のHTTPクライアント、複数のJSONパーサーなど）。これは攻撃者により多くの機会を与えますが、機能的な利点はありません。LLMにロックファイルを読ませ、どの依存関係が重複しているか（そして移行・統合がどのようなものになるか）を質問するのは1時間の作業ですが、大きな見返りがあることが多いです。
• AIによるアップグレード自動化。 フロンティアモデルは、脆弱性レポートとともにパッチを生成する能力がますます向上しています。レポートが明確で詳細であれば、場合によっては概念実証付きであれば、モデルはパッチを直接テストしてエクスプロイトパスが閉じられたことを確認できます。また、上流パッチの受け入れを自動化し、アップグレードがテストや内部システムを壊さないことを検証するプロセスを直接自動化することもできます。
• AIによるベンダリング。 小規模な依存関係の中には OpenSSF Scorecard で低スコアになるものがあります。おそらく積極的にメンテナンスされていないためです。これらに依存し続けるべきではなく、代わりにLLMに実際に使用している機能を再実装するコードを書かせることを検討すべきです。

3. 出荷前にバグを見つける

予防は治療に勝ります。本番に到達したバグはいずれ発見されると想定すべきであり、セキュリティテストはそれよりもはるかに前に実施する必要があります。

• 静的解析とAI支援コードレビューをCIパイプラインに追加し、高確信度の発見事項でマージをブロックしてください。誤検知がこれを非現実的にする場合、チェックは維持しつつツールの改善に取り組んでください。OWASP Application Security Verification Standard は、3つの異なる厳密性レベルでテストに「合格」するとはどういう意味かを定義しています。
• 自動ペネトレーションテストをCDパイプラインに追加してください。 攻撃者が本番システムに対して実行するのと同じスキャンを、ステージングに対して実行できます。
• ビルドパイプラインを保護してください。 コミットからデプロイメントの間にコードを注入できる攻撃者は、脆弱性を見つける必要がありません。SLSA セキュリティフレームワークは段階的なパスを提供します。低レベルではどのコミットがどのアーティファクトを生成したかを確立し、高レベルではビルド自体を検証可能にします。
• Secure by Design プラクティスを採用してください。 CISAの誓約コミットメント（デフォルトでの多要素認証、デフォルトパスワードの廃止、透明な脆弱性報告）は、合理的な最低基準です。
• 新規コードにはメモリ安全な言語を優先してください。 深刻な脆弱性の大部分は、Rust、Go、またはマネージドランタイムでは発生しないメモリ安全性のバグです。CISA、NSA、および NCSC は有用なロードマップを公開しています。既存のC/C++コードを書き直す必要はありませんが、新規のC/C++コードには正当性の説明を求めるべきです。AIを活用した書き換えもますます実用的になっています。

実践的なヒント: OWASP Top 10 および言語固有のルールセットを使用してCIアクションとして実行する静的アプリケーションセキュリティテスト (SAST) ツールは、オープンソースとコードホスティングプラットフォーム組み込みの両方で広く利用可能です（GitHub の CodeQL が最も一般的な出発点です）。ビルドの来歴を評価するために、OpenSSF は GitHub Actions から SLSA Level 3 の証明書を生成する再利用可能なワークフローを公開しています。これを採用する作業量は SLSA 仕様が示唆するよりもかなり少ないです。

前述のとおり、この作業をAIで加速するための明確な機会がいくつかあります。

• AIによる脆弱性スキャン。 ロジックは単純です。攻撃者が使うのと同じ種類のモデルを使って、攻撃者よりも先に自社のコードとシステムをスキャンすべきです。このアプローチに必要なのは、隔離されたエージェント、ノイズをフィルタリングするための検証ステップ、そして既存のトリアージプロセスへのパスだけです。これは今日のLLMで実行可能です。このセクションから一つだけ実施するなら、これを実施してください。
• パッチ生成。 SASTやスキャナーが発見事項を出した場合、フロンティアモデルは通常、それに対するパッチを提案できます。これはレビューの必要性をなくすものではありませんが、開発者の仕事を「バグを理解して修正を書く」から「提案された修正が正しいか検証する」に変えます。後者のほうが速いです。メモリ安全な移行にも同じアプローチが適用されます。LLMは自己完結したCモジュールをテスト付きでRustにポートでき、レビュアーはゼロから全体を書くのではなく等価性を検証できます。

4. コードに既に存在する脆弱性を見つける

パッチ適用は、依存するソフトウェアの既知の脆弱性に対処するものです。しかし、自社のコードベースには未知の脆弱性が含まれています。長期間運用されている本番コードのほとんどは、人間によって何度もレビューされてきましたが、フロンティアモデルによって調査されたことはなく、そのような分析は新しい、これまで見過ごされていた問題を発見する傾向があります。プロアクティブなスキャンにより、最新のLLMの能力範囲内にある脆弱性を、攻撃者が自ら発見する前に特定できます。

• 露出度で優先順位を付けてください。 信頼できない入力をパースするコード、認証または認可の決定を実行するコード、またはインターネットから到達可能なコードから始めてください。これらは、発見事項が最も重要になる可能性が高いパスです。
• レガシーコードを含めてください。 現在のレビュー慣行より前のコード、またはオリジナルの作者が離れたコードは、通常、最も最近の精査が少ないです。そこがフレッシュなパスで最も大きなリターンを得られる場所です。
• 改善の予算を計上してください。 適切に構造化されたモデルスキャンは、古いコードに対して通常 SAST の展開よりも少ない発見事項を生成しますが、そのうち本物の割合はより高くなります。バグを修正するためのエンジニアリング時間を計画してください。

実践的なヒント: 現在のオーナーが少ないインターネット向けサービスを1つ選び、その入力処理と認証ロジックをスキャンしてください。エージェントを隔離して実行し、確認された発見事項のみに基づいて行動するよう検証ステップを追加してください。1つのサービスを適切に実施すれば、より広範なプログラムにかかるコストを推定するための合理的な基礎となります。

5. 侵害を前提に設計する

攻撃者はどこかに足がかりを得ようとします。そこから到達できる範囲を制限する必要があります。

摩擦から価値を得るミティゲーション、つまり攻撃を面倒にするもの（追加のピボットホップ、レート制限、非標準ポート、SMSベースのMFAなど）は、ハードバリアではなく、それらの面倒なステップをすり抜けることができる敵対者に対しては効果がはるかに低くなります。以下の推奨事項は、攻撃者が無限の忍耐力を持っていても保持されるコントロールを優先しています。ハードウェアに紐づいた認証情報、有効期限付きトークン、そして単に不便であるだけでなく存在しないネットワークパスです。

• ゼロトラストアーキテクチャを採用してください。 サービス間のすべてのリクエストを、インターネットからのものであるかのように認証・認可してください。CISAの Zero Trust Maturity Model と NCSCの zero trust principles がどちらも段階的な採用パスを提供しています。
• 認証情報ではなく、検証済みハードウェアにアクセスを紐づけてください。 本番システムと機密性の高い社内ツールは、フィッシング耐性のある2FA（FIDO2またはpasskeys）と組み合わせた、ハードウェアIDが証明された管理対象の従業員デバイスからのみ到達可能にすべきです。盗まれた認証情報だけでアクセスを得ることは決してできないようにすべきです。本番サービス間の呼び出しでさえ、ハードウェアIDに根ざすべきです。
• IDによってサービスを分離してください。 侵害されたビルドサーバーが本番データベースにクエリできるべきではありません。侵害されたラップトップがビルドインフラストラクチャに到達できるべきではありません。これを受信側で強制してください。すべてのワークロードが独自の暗号IDを持ち、各サービスはポリシー名で指定された特定の呼び出し元からの接続のみを受け入れるべきです。ネットワークセグメンテーションは爆発範囲とノイズを減らすことができますが、それはバックストップです。
• 長寿命のシークレットを短寿命のトークンに置き換えてください。 静的なAPIキー、埋め込まれた認証情報、共有のサービスアカウントパスワードは、モデル支援のコード分析を持つ攻撃者が最初に見つけるものの1つです。IDプロバイダーが発行する短寿命でスコープの狭いトークンを使用してください。

実践的なヒント: 完全なゼロトラストは複数年にわたるプログラムですが、ID認識型のアクセスプロキシは、内部サービスのアーキテクチャを根本的に変更することなく、デバイス検証済み・MFAゲート付きのアクセスをその前に配置します。各主要クラウドプロバイダーがネイティブオプションを提供しており、オンプレミスやマルチクラウド環境向けのオープンソースおよび商用の代替手段もいくつか存在します。シークレットについては、すべての主要クラウドがマネージドシークレットストアを持っています。最も広く共有されている認証情報を1つそこに移動してローテーションすることは、残りを進めるための有用な強制力となります。

6. 公開するものを削減し棚卸する

このセクションは2つの重要な原則に基づいています。第一に、知らないシステムを守ることはできません。第二に、公開されている表面が小さいほど、攻撃対象は少なくなります。

• すべてのインターネット向けホスト、サービス、APIエンドポイントの最新のインベントリを維持してください。 攻撃者は自動化された偵察を実行できます。あなたのインベントリは少なくとも同程度に正確であるべきです。これらのシステムをペンテストやレッドチーミングに含めてください。
• 使用していないシステムを廃止してください。 明確なオーナーがいないレガシーサービスは、通常パッチも未適用です。
• 各サービスが公開するものを最小化してください。 デフォルト拒否のネットワークイングレスにし、API の公開範囲を実際に必要なものに限定してください。

実践的なヒント: インターネット全体のスキャンインデックスは公開検索可能です。自社のIPレンジとドメインで検索すれば、攻撃者の偵察が何を見ているかが分かります。クラウド資産については、ネイティブのインベントリツール（AWS Config、Azure Resource Graph、GCP Asset Inventory）がすでに存在しており、作業はそれらにクエリを行うことです。

ここでもAIは直接役立ちます。

• 古いコードやシステムの整理。 使われていないコードの特定は面倒な作業ですが、前述の通りAIモデルは面倒な作業が得意です。コードベースとトラフィックログへの読み取りアクセスを持つモデルは、呼び出し元がなくトラフィックを受信していないエンドポイントをリストアップできます。そこから、それぞれを削除した場合の影響を説明できます。
• 自律的な外部レッドチーミング。 AI攻撃エージェントを、認証情報もソースアクセスもなしで、外部から自社のペリメーターに向けてください。そして、攻撃者がやるであろうことをさせてください。到達可能なものを把握し、フィンガープリンティングし、発見したものを連鎖させて足がかりを得ようとすること。この種の自動レッドチーミングは、ソーススキャンでは見えないものをキャッチできます。忘れられたホスト、公開された管理インターフェース、デフォルト認証情報、設定ミスのストレージなどです。インベントリの更新と同じケイデンスで実行してください。

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

エクスプロイトはパッチから数時間以内に出現する可能性があります。数日かかる対応プロセスでは遅すぎます。インシデント対応時間を短縮するためのアイデアをいくつか紹介します。

• アラートキューの先頭にモデルを配置してください。 すべての受信アラートは、人間が見る前に自動化されたファーストパス調査を受けるべきです。Security Information and Event Management (SIEM) プラットフォームへの読み取り専用アクセスと、適切にスコープされたクエリツールセットを持つこの種の「トリアージエージェント」は、人間の判断を最も必要とするアラートに注意を向けさせることができます。
• 他の何よりも滞留時間とカバレッジを優先してください。 これらは、AI自動化が最も大きく動かせる2つの指標です。エクスプロイトの時間的猶予が短縮されるときに最も重要になります。
• インシデント周りの事務作業を自動化してください。 アクティブなインシデント中、モデルはメモを取り、アーティファクトをキャプチャし、並行する調査トラックを追い、インシデントが終了したらポストモーテムと根本原因分析の草稿を作成すべきです。一方、人間がすべきなのは、封じ込めの判断、開示の判断、顧客コミュニケーションの判断です。インシデント中の人間の判断速度は、証拠収集やレポート作成のようなAIに任せた方がよいタスクによって律速されるべきではありません。
• モデルに検知のフライホイールを回させてください。 脅威インテリジェンスの取り込み、候補となる検知の生成、マッチのハンティング、発火するものの調整は、すべてフロンティアモデルの能力範囲内にあり、エンドツーエンドでプロセスを実行できます。
• 5つの同時インシデントのテーブルトップ演習を実施してください。 標準的な演習は、月曜日に動作するエクスプロイト付きの重大なCVEが1つ発生することを想定しています。私たちが目にしているAI能力の向上を考えると、これは賢明ではないかもしれません。レスポンスを真にストレステストするには、同じ週に5つのインシデントが発生するバージョンを実施すべきです。
• MITRE ATT&CK に対して検知カバレッジをマッピングしてください。 ATT&CKは、ほとんどの検知ツールがすでに使用している攻撃者テクニックの標準語彙を提供します。どのテクニックを検知できるか（そしてどれができないか）を知ることは、「検知を改善する」という一般的な目標よりも有用です。ラテラルムーブメントと認証情報アクセスのカバレッジを優先すべきです。
• 緊急変更手続きを事前に確立してください。 本番パッチに対する2週間の変更承認サイクルは、それ自体がセキュリティリスクです。緊急の封じ込めアクション（サービスのオフライン化、認証情報のローテーション、ネットワークパスのブロックなど）にも同じことが言えます。誰がこれらを承認でき、どの程度速く対応できるかを事前に決めておくべきです。

実践的なヒント: 偽陽性率が高いことで知られるノイジーなルールを1つ選んでください。フロンティアモデルを基盤データへの読み取り専用アクセスとともにそのアラートストリームに接続し、すべての発火に対して構造化された判定を生成させてください。2週間、人間のレビュアーとの一致率を測定してください。一致率が許容範囲であれば、次のルールに展開してください。キュー全体を一度に自動化しようとする価値はありません。別途、Atomic Red Team は ATT&CK テクニックにマッピングされた小規模で安全なテストのオープンソースライブラリです。いくつかを実行して既存のログが実際にどれを検知したかを確認することは、具体的なカバレッジマップを生成する半日の作業です。

以下は、AIが対応時間の短縮に役立つ方法です。

• 100%カバレッジのファーストパストリアージ。 適切にスコープされたトリアージエージェントは、すべてのアラートを調査し（人間は特定の重大度閾値以上のものしか見ないかもしれませんが）、人間が承認、却下、またはエスカレートできる構造化された判定を生成できます。これを機能させるメカニズムは、モデルに最小限のツールセット（クエリ、思考、報告）を与え、独自の調査戦略を選択させ、運用指標に対して出力を測定することです。
• インシデントスクライブと並行調査者。 アクティブなインシデント中、モデルは同時メモを取り、収集されたアーティファクトにタイムスタンプを付け、レスポンダーがまだ着手していない独立した調査トラックを追い、インシデントが終了したらトランスクリプトからポストモーテムを起案できます。これはフロンティアモデルのセキュリティ業務への応用として最も地味なものですが、おそらく最もインパクトの大きいものです。
• 自社環境に対するプロアクティブなハンティング。 ソースコードの脆弱性を発見できるのと同じ種類のエージェントが、テレメトリ全体にわたってミスコンフィギュレーションや侵害の指標をハンティングできます。外部アタックサーフェススキャンと同じケイデンスで実行できます。

他者への脆弱性レポート提出に関するアドバイス

コードをスキャンしている場合——自社の依存関係、オープンソースプロジェクト、またはベンダー製品——そして発見事項をアップストリームに報告する場合、それらのレポートの品質が誰かが行動を起こすかどうかを左右します。オープンソースのメンテナーは、すでに大量の低品質な自動化レポートを受け取っており、AI生成に見えるものを無視し始めているメンテナーも多くいます。シグナルを追加せずにその量に加えることは、あなた自身を含む全員にとって問題を悪化させます。

レポートは、人間が検証し、自分の名前を付ける覚悟がある場合にのみ送信すべきです。具体的には以下の通りです。

• バグとその影響を平易な言葉で述べてください。 メンテナーは最初の段落で、何を実行することなく、何が問題でなぜそれが重要かを理解できるべきです。
• コードパスを辿ってください。 入力がどこで入り、どこで誤処理され、どこで結果が発生するかを示してください。これが、本物の発見事項をパターンマッチと区別する部分です。
• 動作する再現手順を提供してください。 メンテナーが実行できる概念実証、または失敗するテストケースは、いかなる量の説明よりも信頼性があります。
• 自分がメンテナーなら受け入れるであろうパッチを添付してください。 パッチは、報告者がプロジェクトの規約に合った方法で問題を修正できるほどコードベースを理解していることを示します。
• AIの関与を最初に開示してください。 モデルがバグを発見した、またはレポートを起案した場合、最初の行でそう述べてください。メンテナーはいずれにせよ気づきます。隠すことは開示するよりも多くの信頼を失います。
• メンテナーの判断に従ってください。 レポートが却下された場合、それを受け入れてください。協力的であることで得られる信頼は、1つのバグをめぐる議論に勝つよりも価値があります。

実践的なヒント: 脆弱性レポートを送信する前の有用なセルフチェックは、エディタを閉じてバグをメモリから説明することです。モデルの出力を参照せずに何が問題かを説明できない場合、報告するのに十分な理解がありません。

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

上記のアドバイスの大部分は、組織に専任のセキュリティ機能があることを前提としています。小規模な組織、個人開発者、またはオープンソースのメンテナーの場合、同じリスクが適用されますが、アクションはよりシンプルです。

• 自動アップデートを有効にしてください。 オペレーティングシステム、ブラウザ、およびそれを提供するすべてのアプリケーションに対して。これは利用可能な最も効果的な単一のアクションであり、継続的な努力を必要としません。
• セルフホスティングよりもマネージドサービスを優先してください。 セキュリティチームを持つプロバイダーにデータベース、認証、メールの運用を任せることで、パッチ適用の負担を彼らに移転できます。このようなマネージドサービスのコストは、ほぼ常に1回のインシデントのコストよりも低いです。
• passkeys またはハードウェアセキュリティキーを使用してください。 サポートするすべてのアカウントで。SMSコードは傍受でき、パスワードは再利用されます。ハードウェアキーはフィッシングされません。
• コードホストの無料セキュリティツールを有効にしてください。 GitHub の Dependabot、secret scanning、CodeQL はパブリックリポジトリでは無料で、エンタープライズツールが検出するものの相当部分を検出します。有効にするのに数分しかかかりません。

オープンソースプロジェクトをメンテナンスしている場合は、SECURITY.md を公開してください。誰に連絡すべきか、連絡した際に何を期待すべきかを記載します。AIを活用したスキャンにより、以前よりも多くの脆弱性レポートを受け取ることになります。価値のあるものもあれば、自動化されたノイズもあるでしょう。明確なインテークプロセスは両者を区別するのに役立ち、善意の報告者に対して彼らの努力が無駄にならないことを示します。

謝辞

この記事は、Donny Greenberg、Jason Clinton、Michael Moore、Abel Ribbink、Jackie Bow を含む Anthropic のセキュリティエンジニアリングおよびリサーチチームのメンバーが執筆し、Jannet Park、Gabby Curtis、Stuart Ritchie が寄稿しました。