ThreatBookによるCyberStrikeAI買収、オープンソースツールをエンタープライズセキュリティへの賭けに変える
ThreatBookは、AIペネトレーションテストプラットフォームの公開から1年未満でCyberStrikeAIを買収し、オープンソースセキュリティのガバナンスを即座に試す局面を生み出した。ThreatBookによるCyberStrikeAI買収により、同社は100を超えるツールテンプレートを備えた実用的な攻撃的セキュリティプラットフォームを手にする。同時に、実際のネットワーク全体で重大な操作を実行し得る技術への責任も負うことになる。
この取引は、従来型の製品買収にとどまらない。ThreatBookはCyberStrikeAIのオープンソース版を維持しつつ、顧客ネットワーク内で展開するエンタープライズ版を構築する計画だ。このアプローチでは、オープン性、商用上の統制、悪用防止を同じ製品戦略の中で両立させる必要がある。
競争の基準は、発見事項のキューを増やすだけの脆弱性スキャナーではなくなっている。Horizon3.ai、Pentera、XBOWといったベンダーはすでに、弱点が実際の攻撃経路につながるかどうかを検証する自動化またはAI支援システムを販売している。ThreatBookは今後、買収したオープンソースプロジェクトを同等に信頼されるエンタープライズシステムへ転換できることを示さなければならない。
ThreatBookによるCyberStrikeAI買収が攻撃的レイヤーを追加
ThreatBookが買収するのは、単なる脅威インテリジェンスの情報源ではなく、実行プラットフォームだ。
ThreatBookは2026年9月30日、シンガポールおよび香港から買収を発表した。同社は買収発表で、買収価格やその他の財務条件を開示していない。
CyberStrikeAIはGoで記述されたAIネイティブのペネトレーションテストプラットフォームだ。言語モデルが、偵察、スキャン、エクスプロイト、分析、レポート作成を行うセキュリティツールを連携させられる。ペネトレーションテストとは、脆弱性が実際に悪用可能かを判定するため、認可を得たうえで攻撃を実施することを指す。
このプラットフォームの重要性はオーケストレーションにある。従来のセキュリティツールは通常、個別の作業を処理し、テスト担当者がコマンドを選択して結果を結び付ける必要がある。CyberStrikeAIは、より長い一連の手順を計画・実行できるエージェントの背後にこうしたツールを配置する。
公開ドキュメントでは、ネットワーク、アプリケーション、クラウド、コンテナ、フォレンジック、侵害後活動にわたり、100を超えるツールテンプレートをサポートすると説明している。このプロジェクトは、特定のテスト中に利用可能なプロンプト、ツール、挙動を制限するロールベースの構成も提供する。
ThreatBookによると、CyberStrikeAIは2025年後半の公開後、GitHubで7,000を超えるスターを集めたという。同社はさらに、公開インターネットスキャンのデータで、世界中に3,000以上の導入済みインスタンスがあることが示されていると述べる。これらの数値は可視性と展開状況を示すものだが、エンタープライズでの採用やテスト品質を裏付けるものではない。
この区別は重要だ。スターは関心を表すにすぎず、検証済みの性能を意味しない。公開状態のインスタンスも、運用上の成功ではなく、実験や不十分な導入慣行を示している可能性がある。ThreatBookは、この展開数について独立した監査結果を公表していない。
基盤となるCyberStrikeAIリポジトリは、このプロジェクトが注目を集めた理由を示している。自然言語での操作、複数のモデルプロバイダー、ナレッジ検索、攻撃チェーンの可視化、ツール監視、永続的な実行記録を組み合わせている。
ThreatBookは、これらの機能をレッドチームのポートフォリオに統合する計画だ。レッドチームは、組織の防御が現実的な攻撃者の行動を検知し、耐えられるかを検証するため、統制された攻撃を実施する。
同社はオープンソース版を引き続き利用可能にするとしている。また、悪用を抑えるための追加的な安全策も計画しているが、発表ではその設計や適用モデルは定義されていない。
別途用意されるEnterprise Editionには、オンプレミス展開、ローカルデータ保管、権限制御、完全なエージェント操作の監査証跡が追加される。中国本土では直ちにトライアル提供が始まり、世界展開は2026年第4四半期に見込まれている。
この製品分割が中心的な緊張関係を生む。コミュニティ版は到達範囲、フィードバック、拡張性をもたらす。エンタープライズ版は、こうした特性をセキュリティリーダーが安全に承認できる統制された実行へ変換しなければならない。
ThreatBookが今AIペネトレーションテストを求める理由
この買収によりThreatBookは、脅威を説明する立場から、統制された環境内でソフトウェアエージェントに攻撃行動を再現させる立場へと進む。
ThreatBookはこれまで、脅威インテリジェンス、検知、調査、対応を中心に取り組んできた。これらの製品は、顧客が悪意あるインフラを理解し、不審な活動を特定し、インシデントを調査するのに役立つ。
同社は最近、この位置付けをエージェント型セキュリティへと広げている。エージェント型システムは単にテキストを生成するのではなく、ツールを選択し、操作を実行し、結果を検査し、計画を修正する。ThreatBookはすでに、エージェントベースのセキュリティ運用や、AIエージェントのリスクを評価するツールを販売している。
CyberStrikeAIは、欠けていた攻撃的な役割を埋める。インテリジェンスが説明した、あるいは防御システムが検知した弱点が、実用可能な攻撃経路につながるかをテストできる。これにより、脅威知識、攻撃の検証、検知、修復の間に潜在的なループが生まれる。
このタイミングは、従来のペネトレーションテストにおける実用上の制約を反映している。人間主導の取り組みは判断力と創造性をもたらすが、通常は限られた期間に定義済みの範囲を対象とする。最終レポートが届いた直後にも、インフラは変化し得る。
自動化テストは、評価間隔の短縮を約束する。チームがアプリケーション、アイデンティティポリシー、クラウド構成、ネットワーク境界を変更した後に、既知の攻撃経路を繰り返し検証できる。
重要な約束は、人間のテスト担当者を排除することではなく、継続的な検証だ。有用なシステムは、到達可能な資産を特定し、統制をテストし、証拠を保存し、修復を確認すべきである。人間のオペレーターは引き続き範囲を設定し、危険な手順を承認し、事業への影響を解釈する必要がある。
CyberStrikeAIのアーキテクチャは、言語モデルを既存ツールへ接続することでこの方向性を支える。Model Context Protocol、すなわちMCPは、モデルが外部ツールを呼び出し、その結果を利用するための標準化された方法を提供する。CyberStrikeAIでは、構成ファイルを通じて追加のコマンドを定義することもできる。
このプラットフォームのマルチモデル設計により、オペレーターは推論に使用する言語モデルを選択できる。この柔軟性は、組織が展開やデータ要件を満たす助けになる。一方で、異なるモデルは同じ証拠から異なる計画を立てる可能性があるため、ばらつきも生じる。
ThreatBookのエンタープライズ計画は、購入者が抱く複数の懸念に直接対応する。ローカル展開により、機密性の高いトポロジー、認証情報、脆弱性の証拠、モデルとのやり取りを顧客環境内に保持できる。
権限制御により、どのユーザーまたはエージェントが高リスクのツールを呼び出せるかを制限できる。監査証跡は、どの指示が操作を生み、ツールが何を返し、システムがどのように進行したかを示せる。
ただし、これらの統制は実行経路全体をカバーして初めて価値を持つ。サブプロセス、プラグイン、リモートツールが同一のポリシー境界の外で動作できるなら、エージェントの会話を記録するだけでは不十分だ。
だからこそ、ThreatBookによるCyberStrikeAI買収は重要な時期に実現した。企業はますます操作を実行するAIシステムを求めているが、セキュリティチームは、そうしたシステムに意味のある権限を与える前に、より強力な証拠を必要としている。
CyberStrikeAIの仕組みそのものが最大のリスクでもある
防御側の時間を節約する同じオーケストレーション層が、無許可の攻撃を実行するために必要な労力を減らす可能性がある。
CyberStrikeAIは、セキュリティ運用に影響を与えるために新たなエクスプロイトを発明する必要はない。その実用的な価値は、既存ツールを連携させ、コンテキストを維持し、各結果の後に次の操作を選択することにある。
認可を得た内部評価を考えてみよう。エージェントはホストを列挙し、公開されたサービスを特定し、既知の弱点をテストし、アクセス可能な認証情報を調べ、保護されたシステムへの経路をマッピングする可能性がある。その後、証拠を構造化されたレポートにまとめられる。
人間のテスト担当者も同じ手順を実行できる。エージェントは、より多くの標的に対して確立済みの手順を繰り返し、コマンドごとの継続的な監督なしに動作することで、その経済性を変える。
この仕組みは危険性も説明する。攻撃的セキュリティツールは常にデュアルユースであり、防御側と攻撃側の双方が同じ能力を利用できる。利用しやすいオーケストレーション層は、経験の浅いオペレーターでも複雑なワークフローを実行しやすくする可能性がある。
CyberStrikeAIのドキュメントは、これが高権限システムであると警告している。コマンドの実行、MCPツールの呼び出し、Webシェル接続の管理、さらに任意でコマンド・アンド・コントロールのワークフローをサポートできる。
こうした能力には、通常のAIアシスタントより厳格な安全策が必要だ。誤った文書要約は混乱を招く。誤ったペネトレーションテスト操作は、サービスを中断し、データを露出させ、システムを変更し、認可境界を越える可能性がある。
近年の研究では、自律型ペネトレーションテストエージェントを独自のセキュリティ問題として扱っている。エージェントセキュリティ分析の一つは、永続メモリー、現実世界での操作、長期的な推論が、会話型AIを超えるリスクをもたらすと論じている。
懸念には、プロンプトインジェクション、安全でないツール選択、過剰な権限、汚染されたメモリー、人間による監督の失敗が含まれる。エージェントは曖昧なスコープ定義を誤解し、オペレーターが含める意図のなかった資産をテストする可能性もある。
モデルの挙動も別の変数となる。CyberStrikeAIは異なるモデルプロバイダーに接続できるが、モデルごとに拒否の挙動、計画品質、コンテキスト処理、操作されたコンテンツへの感度は異なる。
偵察中に遭遇したWebページには、AIエージェントに影響を与えるために設計された指示が含まれている可能性がある。システムが信頼できない標的コンテンツを権威ある指針として扱えば、秘密情報を開示したり、不適切なツールを呼び出したりするおそれがある。
ツールの説明も攻撃対象になり得る。悪意あるプラグインは機能を偽って説明し、認証情報を取得し、エージェントの計画を誤った方向へ導く偽造結果を返す可能性がある。
したがって、ThreatBookが約束する監査機能と権限機能は必要だが、決定的なものではない。効果的なガバナンスには、強制される標的境界、隔離された実行、認証情報の統制、承認チェックポイント、信頼できるログ、緊急停止が必要となる。
完全な監査証跡は、エージェントが述べた推論以上のものを記録すべきだ。ツールパラメーター、出力、アイデンティティ、タイムスタンプ、承認判断、モデル構成、ポリシーバージョン、環境への変更を記録する必要がある。
セキュリティチームには再現性も必要だ。エージェントが脆弱性を悪用したと報告する場合、レビュー担当者は直接的な証拠とモデルによる解釈を区別できるべきである。
この中核的な仕組みは、判断と操作をつなぐからこそ価値がある。そのつながりは同時に、購入者がCyberStrikeAIを、使い慣れたツールのための単なるAIインターフェースではなく、特権を持つインフラとして評価しなければならないことも意味する。
オープンソースとエンタープライズ統制は共存しなければならない
ThreatBookにとって最も難しい製品上の課題は、有用なオープン性を維持しつつ、企業が検証できる統制を導入することだ。
オープンソース配布は、CyberStrikeAIの急速な普及を後押しした。研究者はコードを精査し、ツールを追加し、プロンプトを調整し、モデルプロバイダーをテストし、商用リリースのサイクルを待たずに修正へ貢献できる。
こうしたオープン性により、ThreatBookはすぐに活用できるコミュニティと広範なテスト領域を得られる。公開の場での検証は、企業環境に到達する前に欠陥、安全でないデフォルト設定、互換性の問題を発見し得る。
しかし、ソースコードが利用可能であることは、システムの安全性を自動的に保証するものではない。大半のユーザーは導入前に、すべての依存関係、プラグイン、設定ファイル、生成されたコマンドを監査するわけではない。
高い権限を持つプロジェクトは、メンテナーが制限を追加した後でもフォークされ得る。ThreatBookは公式配布版を改善できるが、既存のコピーを回収することも、下流の派生版が同じ安全策を維持することを保証することもできない。
同社は、悪用防止策を追加しつつ、オープンソース版を提供し続けると約束している。重要なのは、それらの対策が自発的な警告、技術的制限、モデルプロバイダーのポリシー、あるいはその組み合わせに依存するのかという点だ。
統制が弱すぎれば、悪用の問題は未解決のまま残る。厳しすぎる統制は正当な研究者をいら立たせ、古いバージョンにとどまったり、統治の緩いフォークを維持したりする動機を与えかねない。
エンタープライズ版は、第二のバランス問題を生む。ThreatBookは、買収の魅力を支えたコミュニティ版を空洞化させずに、商用価値を提供しなければならない。
オンプレミス導入は明確な差別化要因の一つだ。多くのペネトレーションテストでは、認証情報、内部アドレス、専有コード、システム設定、悪用可能な発見事項を扱う。そうした情報を外部サービスへ送ることは、ポリシーや顧客への義務に違反する可能性がある。
ただし、オンプレミス運用であっても、すべてのコンポーネントがローカルにとどまる保証はない。購入者は、モデルエンドポイント、テレメトリー、更新サービス、プラグイン、組み込み分析機能、サポートのワークフローを検証すべきだ。
権限制御にも十分な細かさが求められる。セキュリティ責任者は、特定のツール、対象、認証情報、テスト時間帯、ネットワークセグメント、破壊的な操作を制限できる必要がある。
大まかな管理者とユーザーの区別だけでは不十分だ。テストごとに必要な権限レベルは異なり、ラボ環境で安全な操作が、本番インフラでは危険になり得る。
人間による承認も、設計上の選択肢の一つである。すべてのコマンドに承認を求めれば、自動化の利点の多くが失われる。無制限の実行を許せば、機微な環境で許容できないリスクが生じる。
より信頼できるモデルは、段階的な自律性を採用する。低リスクの偵察は自動で進められる一方、悪用、認証情報の使用、永続化、データアクセス、サービスに影響する操作には明示的な認可を要求する。
インシデント後もログは信頼できる状態で残らなければならない。テストエージェントや呼び出されたツールが自身の記録を改変できるなら、監査証跡はコンプライアンスやフォレンジック調査を支えられない。
こうした詳細が、この買収が持続可能なプラットフォーム戦略となるかを左右する。GitHubでの人気はユーザーを引き付けられるが、企業のセキュリティチームが購入するのは、予測可能な境界、サポート、証拠、説明責任である。
ThreatBook、競争が激しい自律テスト市場に参入
ThreatBookが競合するのは、手作業のペネトレーションテストだけでなく、既存の攻撃検証プラットフォームでもある。
Horizon3.ai、Pentera、XBOW、Hadrian、Aikido Securityなどのベンダーは、すでに継続的または自律的なテストを訴求している。それぞれの提供内容は、内部ネットワーク、クラウドシステム、アイデンティティ環境、Webアプリケーション、外部攻撃対象領域にわたって異なる。
このカテゴリーには重要な製品上の違いもある。一部のプラットフォームは脆弱性の発見を重視する。悪用可能性の検証、攻撃チェーンの構築、敵対者のシミュレーション、自動テストと人間によるレビューの組み合わせに重点を置くものもある。
スキャナーは通常、シグネチャや設定チェックに基づいて疑わしい弱点を報告する。自律型ペネトレーションテストは、制御された悪用を試み、それらの弱点を攻撃者が利用できるかどうかを証明しようとする。
その証拠は優先順位付けを改善し得る。重大なソフトウェアの欠陥でも、代替的な統制によって到達可能な経路がすべて遮断されていれば、当面のリスクは限定的かもしれない。一方、評価の低い弱点でも、機微なシステムにつながる認証情報を露出させる場合は、緊急の対応に値する可能性がある。
Horizon3.aiは、自律テストを悪用可能性の検証と修正の継続的な再テストを行う手段として説明している。同社の購入者向けガイダンスは、購入者が攻撃経路の検証をスキャンやシミュレーションと区別すべきだと主張している。
ThreatBookは、この競争において三つの潜在的な優位性を持つ。既存のオープンソースプロジェクトを取得し、脅威インテリジェンスをテスト計画に統合でき、機微な顧客向けにローカル導入型の実行環境を提供できる。
オープンソース配布は、評価時の摩擦も減らし得る。技術チームは、商用調達を開始する前にソフトウェアを調査し、テストできる。
不利な点も同様に明確だ。ThreatBookは、最近取得したプロジェクトを中心に、エンタープライズサポート、安全性、ベンチマーク品質、国際的な提供体制を確立しなければならない。
競合他社は長年をかけて、独自の攻撃知識、導入ツール、レポーティングシステム、顧客からの信頼を構築してきた。チケット管理、脆弱性管理、アイデンティティ、セキュリティ運用プラットフォームとの統合を提供する企業もある。
CyberStrikeAIの統合ツール一覧だけでは、その差を埋められない。ツールの数が多いことは、エージェントがそれらを適切に選択すること、障害を安全に処理すること、誤った結論を減らすことの証明にはならない。
独立したベンチマークの実施は依然として難しい。ラボでの課題では、エージェントが既知の脆弱性を見つけられるかを測定できるが、本番環境の評価には、不完全な情報、脆弱なシステム、ポリシー上の制約、変化する防御策が伴う。
システムはその発見事項を人間にも説明しなければならない。セキュリティチームには、正確な証拠、修正の文脈、再現可能な検証が必要だ。運用担当者が手順を再現できなければ、見栄えのする攻撃チェーンに価値はほとんどない。
ThreatBookの脅威インテリジェンス分野での背景は、ここで重要になり得る。最新のインテリジェンスは、一般的なチェックリストを繰り返すのではなく、進行中のキャンペーンに関連する手法をエージェントが優先する助けになるかもしれない。
その統合は、インテリジェンスとテストを別々のワークフローとして扱うベンダーに圧力をかける可能性がある。同時に、出所、鮮度、信頼度に関する新たな要件も生む。
未検証のインテリジェンス記録が手法と製品を結び付けているというだけで、エージェントがテストを開始すべきではない。システムには、インテリジェンスを無制御な行動ではなく、範囲が限定された仮説へ変換するポリシーが必要だ。
したがって、この買収はThreatBookが対応できる課題の範囲を広げるが、リーダーシップを確立するものではない。同社は、インテリジェンスに基づく自動化が既存の自律テストプラットフォームよりも安全で有用な結果を生むことを証明しなければならない。
最大の未知数はツール数ではなく信頼だ
ThreatBookはCyberStrikeAIの機能を説明しているが、購入者には精度、安全性、運用信頼性に関する独立した証拠が依然として不足している。
買収発表には、導入数、製品機能、リリース計画が含まれている。一方で、ベンチマーク結果、誤検知率、完了率、顧客維持率、インシデント履歴、独立して検証されたセキュリティ評価は示されていない。
発表時点でその欠如は理解できる。それでも、読者がThreatBookによるCyberStrikeAI買収から導ける結論は限定される。
100を超えるツールテンプレートは対象範囲を広げ得るが、統合には保守義務が伴う。外部ツールは、時間の経過とともにコマンド、出力、依存関係、ライセンス、セキュリティ特性を変える。
開発時に機能していたテンプレートが、上流の更新後に失敗する可能性がある。より危険なのは、不完全な出力を返しながら動作を続け、エージェントがそれを誤って解釈することだ。
したがって、エージェントの信頼性には障害の認識も含まれなければならない。システムは、欠落したツール、認証エラー、部分的なスキャン、レート制限、遮断された接続、不確実な結果を識別すべきだ。
目に見えるクラッシュよりも、誤った安心感の方が大きなリスクとなる。テストが完了と表示されると、エージェントが重要な資産を密かにスキップしていたにもかかわらず、経営陣が環境は安全だと信じるおそれがある。
導入数の数字にも注意が必要だ。ThreatBookは公開インターネットスキャンのデータに基づく推計としており、これは非公開の導入や実際の利用を完全には説明できない。
高い権限を持つテストプラットフォームにとって、公開された状態そのものが望ましくない場合もある。購入者は、管理インターフェースをローカルにバインドし、強力な認証を要求し、シークレットを保護し、不必要なインターネット接続を抑制する安全なデフォルト設定を確認すべきだ。
セキュリティポリシーは、ユーザーに対し、このプラットフォームを高権限のシステムとして扱い、認可されたテストにのみ使用するよう求めている。この警告は責任の所在を定めるものだが、ユーザーがどれだけ効果的に従うかは技術的な強制力で決まる。
ThreatBookはプロジェクトガバナンスについても明確にする必要がある。コミュニティは、誰がリリースを管理し、貢献をレビューし、脆弱性を処理し、成果物に署名し、古い導入環境を維持するのかを知る必要がある。
サプライチェーン保護には特に注意を払うべきだ。攻撃者は、機微な環境へのアクセスをすでに持つセキュリティツールを頻繁に標的にする。
企業顧客は、署名付きリリース、依存関係の可視化、管理された更新チャネル、脆弱性報告手順、明確なサポート期間を期待すべきだ。また、コマンドを実行できるエージェント向けに強化された導入ガイダンスも期待すべきである。
商用モデルは別の不確実性をもたらす。ThreatBookは、価格、パッケージ、サービスレベル、どの保護策がエンタープライズ版専用となるかを明らかにしていない。
これらの決定はオープンソースプロジェクトの将来を形作る。不可欠な安全機能が商用の境界の内側にのみ置かれるなら、コミュニティによる導入は脆弱なままとなり得る。すべてのエンタープライズ向け統制が無償で提供されるなら、有償版には別の持続的な価値提案が必要になる。
ThreatBookのローカルデータ保存への取り組みは有望だが、購入者は検証すべきである。ネットワーク監視によって、モデル呼び出し、テレメトリー、クラッシュレポート、更新が環境外へ出ていないかを確認できる。
組織は、本番アクセスを付与する前に敵対的評価も行うべきだ。テストには、プロンプトインジェクション、汚染されたツール出力、スコープ操作、認証情報の漏えい、ログ記録の失敗、承認ゲートを回避する試みを含めるべきである。
AIを活用した悪用に関する研究は、なぜその評価が重要なのかを示している。Cloud Security Allianceの分析は、並列的なAI支援ワークフローが、大規模な攻撃対象領域にわたり必要な時間と人間の注意をいかに減らすかを説明している。
このレポートのより広い教訓は、防御側と攻撃側の双方に当てはまる。実行速度が上がるほど、人間が気付く前にミスや悪用が広がり得るため、境界の重要性は高まる。
三つの兆候が買収の影響を左右する
次の段階は、製品の証拠、ガバナンスの証拠、実際の顧客行動を通じて評価されるべきだ。
第一の兆候は、2026年第4四半期に予定されているグローバルなEnterprise Editionのリリースである。ThreatBookは、サポートする導入モデル、モデル接続、承認統制、監査範囲、ツール分離アーキテクチャを明示する必要がある。
詳細なセキュリティアーキテクチャは、CyberStrikeAIが企業ネットワーク内で安全に運用できるという同社の主張を強化するだろう。リリースの遅延や仕様の不足は、このプロジェクトが機微な環境に対応できるという論拠を弱める。
第二のシグナルは、オープンソースのガバナンスだ。署名付きリリース、公開された脅威モデル、より安全なデフォルト設定、独立したレビュー、明確なメンテナーの役割、報告された脆弱性への対応を文書化しているかを注視すべきである。
こうした措置は、ThreatBookがコミュニティ版を継続的に保守されるセキュリティ製品として位置付けていることを示すだろう。一方で、公開コードとエンタープライズ向け保護機能の隔たりが広がれば、断片化や管理されないフォークへの懸念を招く。
第三のシグナルは、第三者が独立して再現可能な顧客事例である。ThreatBookは将来的に、同プラットフォームが検証済みの攻撃経路をどの程度の頻度で特定するのか、不完全なテストをどのように扱うのか、顧客が修復を検証できるかどうかを示す必要がある。
ケーススタディには、見出しを飾る脆弱性件数だけでは不十分だ。有用な証拠には、対象範囲、環境規模、期間、人による監督、不成功に終わった経路、安全制御、再現可能な証明が含まれる。
競合各社の対応も、追加の文脈をもたらすだろう。既存ベンダーがオンプレミス展開、オープンな統合、または脅威インテリジェンス主導のテストを重視するなら、それはこの戦略的方向性を裏付けることになる。
購入者が引き続き、より長い運用実績を持つクローズドなプラットフォームを選好する場合、ThreatBookは、オープン性とツールの柔軟性が統合およびガバナンスのコストを上回る理由を示す必要がある。
この買収の成否は、CyberStrikeAIがより多くのツールを投入できるかどうかには左右されない。組織が、重要な影響を及ぼすすべてのアクションを予測し、制約し、検査し、信頼できるかどうかにかかっている。
プラットフォームを評価するセキュリティチームは、隔離されたラボ環境、限定的に定義された対象、使い捨ての認証情報、リスクの高い手順に対する人間の承認から始めるべきだ。報告された検出結果を独立したテストと比較し、すべての実行記録を保存すべきである。
問うべきなのは、AIペネトレーションテストがより高速になるかどうかではない。すでに自動化は容易になりつつある。重要なのは、ThreatBookによるCyberStrikeAI買収が、その自動化を実際のエンタープライズ利用に十分な説明責任を伴うものにできるかどうかだ。
