リリースが数ヶ月ごとにしか行われていなかった時代には、ペネトレーションテストは理にかなっていました。ある時点での評価であれば、数週間、場合によっては数ヶ月間、リスクの正確な状況を把握することができました。しかし現在、エンジニアリングチームは継続的にリリースを行っています。CISO 200名とエンジニアリングリーダー200名を対象に実施した「ペネトレーションテストにおけるAIの現状」に関する調査によると、76％が少なくとも週に1回は大幅な変更をデプロイしており、40％近くが毎日デプロイしていることが明らかになりました。それにもかかわらず、リリースごとにセキュリティ検証を行っているのはわずか21％にとどまっています。
その隔たりには、結果として影響が及ぶ。
- 79％が、ペネトレーションテストの合間に脆弱性が見落とされることを懸念している。
- 半数は、報告書が届く頃には、その調査結果はすでに時代遅れになっていると指摘している。
- 64％が、セキュリティテストのスケジュールがリリース決定に影響を与え、導入の遅延を招いたり、チームに追加のリスクを受け入れることを余儀なくさせたりしていると回答している。
多くの組織にとって、AIを活用したペネトレーションテストは、そのギャップを埋める現実的な手段になりつつあります。しかし、これはまだ比較的新しい分野であるため、購入担当者は従来のペネトレーションテスト向けに設計された基準を用いてプラットフォームを評価することがよくあります。そうした基準では、開発ワークフローに組み込まれた際に、どのプラットフォームが最も優れたパフォーマンスを発揮するかを判断することはもはやできません。
AIペネトレーションテストを提供するすべてのベンダーが答えられるべき質問
どのベンダーも、脆弱性 を実演することができます。
このプラットフォームがエンジニアリングのワークフローに組み込まれると、より難しい課題が浮上してきます。ソースコードを活用できるのでしょうか？ AIエージェントがスコープ外に出るのをどのように防ぐのでしょうか？ ソフトウェアが変更されても、このプラットフォームは引き続き価値を提供し続けるのでしょうか？
このプラットフォームではソースコードを使用できますか？
1,000件以上のAIによるペネトレーションテストにおいて、ホワイトボックステストは、グレーボックステストのみの場合よりも少ない試行回数で、7倍多くの脆弱性を発見した。
すべてのAIペネトレーションテストプラットフォームがホワイトボックステストに対応しているわけではなく、対応しているプラットフォームであっても、ソースコードの活用方法は必ずしも同じとは限りません。ベンダーがコードをどのように活用しているか、また結果の根拠となる証拠を理解することは、あらゆる評価において欠かせない要素であるべきです。
ベンダーに問い合わせる：
- このプラットフォームはホワイトボックステストに対応していますか？
- コードへのアクセスは任意ですか？
- テストの際、ソースコードはどのように活用されるのでしょうか？
- 顧客のソースコードはどのように保護されていますか？
- コードへのアクセスが成果の向上につながることを示す証拠にはどのようなものがあるか？
ベンダーを公平に比較していますか？
ベンダー評価が有用となるのは、すべてのプラットフォームが同等の条件下でテストされた場合に限られる。
あるベンダーがソースコードを受け取り、別のベンダーが受け取らない場合。あるプラットフォームの実行時間が著しく長かったり、クレジットの消費量が大幅に多かったりすると、最終レポートの比較が困難になります。
このガイドに記載されている推奨事項の一つは、次のとおりです：
このチェックリストでは、認証、ソースコード、適用範囲、検証、報告といった項目について具体的な質問を盛り込むことで、すべてのベンダーが同じ条件で評価されるようにしています。
テストはどのようにして範囲内に収められているのでしょうか？
AIエージェントは、アプリケーションを探索するように設計されています。購入者は、その境界がどのように適用されるかを正確に理解しておく必要があります。
スコープがどのように適用されるかを確認してください。デフォルトで本番環境を除外することは可能ですか？ドメインは許可リストに登録されていますか？エージェントが合意された環境外へのリダイレクトに従った場合、どうなりますか？テストの実行中に、その状況を監視したり、テストを停止したりすることは可能ですか？
最も堅牢なプラットフォームは、プロンプトや書面による指示に頼るのではなく、技術的な手段を用いてこれらの制御を実施しています。
このプラットフォームは、ソフトウェアの変更にどのように対応しているのでしょうか？
現代のエンジニアリングチームは、ペネトレーションテストが完了しても、リリース活動を止めることはありません。新しいコード、新しい機能、そして新しい依存関係 攻撃対象領域に変化をもたらします。
ベンダーに、そのプラットフォームが自社のリリースプロセスにどのように適合するかを尋ねてください。ソフトウェアの変更に伴い、テストは自動的に実行されますか？新しいアプリケーションはどのくらいの速さで導入できますか？修正後の再テストは、別途契約を結ぶことなく行えますか？最初の有意義な結果が出るまで、どのくらいの時間がかかりますか？
週に複数回デプロイを行う組織や、CI/CDセキュリティ機能を直接組み込んでいる組織にとって、こうした課題はますます重要になってきています。
評価の過程でよく見られる危険信号
また、このガイドでは、注意深く見極めるべき警告サインについても取り上げられています。
- ベンダー側は、調査結果がどのように検証されているのか説明できない。
- 比較証拠がない限り、コードへのアクセスは却下される。
- セキュリティの防護柵は、技術的な制御ではなく、ユーザーへの促しに依存している。
- どのデモも、よく知られたOWASPの脆弱性に焦点を当てており、ビジネスロジックのテストが行われている形跡はほとんど見られない。
これらの要素のいずれも、プラットフォームを自動的に除外するものではありませんが、決定を下す前にそれぞれを詳しく検討する価値があります。
「AIペネトレーションテスト購入ガイド」をダウンロードする
上記の例は、評価フレームワークのほんの一部に過ぎません。
この完全ガイドには、以下の内容も含まれています：
- 実用的なベンダー評価チェックリスト
- AIによるペネトレーションテストと手動によるペネトレーションテストの比較
- 1,000件以上のAIペネトレーションテストに関する調査
- ホワイトボックステストとグレーボックステストの比較分析
- 「ペネトレーションテストにおけるAIの現状」レポートの主な調査結果
- 120時間の手動ペンテスト では問題が1件もペンテスト のに対し、AIによるペネトレーションテストで13件の問題が発見された、匿名化された顧客事例
評価の対象が何であれ Aikido であれ、他のプラットフォームであれ、このガイドは、すべてのベンダーを同じ基準で比較できるよう設計されています。
ガイドの全文はこちらからダウンロードしてください：
