継続的なオフェンシブセキュリティとAIペネトレーションテスト：よくある20の質問

アプリケーションは、予定されたセキュリティ評価の合間にも何度も変更されることがあります。新機能、API、インテグレーションによって、次回の年次ペネトレーションテストが始まる前にリスクが生じる可能性があります。

こうした隔たりを埋めるため、オフェンシブテストは単一のツールや一度きりの評価にとどまらない形へと進化しています。チームは、アプリケーションリスクのさまざまな層を評価するため、動的アプリケーションセキュリティテスト（DAST）、AIペネトレーションテスト、AIレッドチーミングを組み合わせるようになっています。これらの手法を組み合わせることで、脆弱性を繰り返し検出し、エクスプロイトをより深く検証し、AIエージェントやエージェント型アプリケーション特有のリスクをテストできます。各アプローチが対処するよう設計されたリスクとテストの目的に合わせて、手法を選ぶ必要があります。

継続的なオフェンシブセキュリティの基本

継続的なオフェンシブセキュリティでは、検出、検証、修正、再テストにわたって、相互に補完するテスト手法を連携させます。アプリケーションの種類、直近の変更、確認対象のリスクに応じて、適切な手法を選択できます。

1. 継続的なオフェンシブセキュリティとは何ですか？

継続的なオフェンシブセキュリティ（COS）は、定期的およびイベント発生時のテストを通じて、アプリケーションリスクを特定・検証するプログラムレベルのアプローチです。広範なカバレッジを実現する自動化手法と、より深い調査を行う適応型テストを組み合わせられます。アプリケーションの変化に応じて、より強固なカバレッジを維持し、より迅速なフィードバックを提供することが目的です。この包括的なプログラムの中で、各テスト手法を異なるスケジュールで実施できます。

2. 継続的なオフェンシブセキュリティが必要なのはなぜですか？

アプリケーションやAPIは頻繁に変化するため、一度きりの評価だけでは十分なカバレッジを確保できません。予定されたペネトレーションテストでは、その評価時点のアプリケーションを調査できますが、その後の新しいリリースで脆弱性が生じることがあります。継続的なオフェンシブセキュリティは、予定されたペネトレーションテストがもたらす深い保証を維持しながら、こうした変化をより早く特定するのに役立ちます。

3. 継続的なオフェンシブセキュリティは、従来のオフェンシブセキュリティとどう違いますか？

従来のオフェンシブセキュリティは、範囲、期間、対象を定めた個別の評価に依存することがよくあります。継続的なオフェンシブセキュリティでは、このモデルをテスト、修正、再テストの反復サイクルへと拡張します。範囲を定めたペネトレーションテストやレッドチーム演習も含めながら、他のテスト手法と連携させることで、アプリケーションの変化に応じて、より頻繁にフィードバックを得られます。

4. 継続的なオフェンシブセキュリティには、どのようなテストを含められますか？

COSプログラムでは、稼働中のWebアプリケーションやAPIをテストするDAST、エクスプロイト可能性を調査するAIペネトレーションテスト、AIエージェントやエージェント型アプリケーションを評価するAIレッドチーミングを活用できます。エージェントレッドチーミングはAIレッドチーミングの一種で、テキストを生成するだけでなく、AIシステムがアクションを実行したりツールを呼び出したりできる場合に生じる追加のリスクに焦点を当てます。適切な組み合わせは、アプリケーションの種類、ビジネス上の重要度、テストの目的によって異なります。

5. 継続的なオフェンシブセキュリティでは、すべてのテストを常時実行するのですか？

テストは、スケジュールに沿って、リリースや大きな変更の後に、または新たなリスクが発生したときに実施できます。継続的なオフェンシブセキュリティにおける「継続的」とは、すべてのテストを絶え間なく実行することではなく、プログラム全体で継続的にカバレッジを確保し、フィードバックサイクルを短縮することを指します。

AIペネトレーションテストの基本

AIペネトレーションテストは、従来ペネトレーションテストで行われてきた作業の多くを自動化します。アプリケーションを調査し、応答に応じてテスト方法を適応させ、疑われる脆弱性が悪用可能かどうかの検証を支援できます。

6. AIペネトレーションテストとは何ですか？

AIペネトレーションテストでは、AIを使ってアプリケーションを調査し、その応答に応じてテストを調整して、疑われる脆弱性を悪用できるかどうかを評価します。固定された一連のチェックだけに従うのではなく、テストの進行に応じて次のステップを適応させられます。ただし、調査の深さ、自律性、検証能力は製品や実装によって異なります。

7. AIペネトレーションテストはどのように機能しますか？

AIペネトレーションテストでは通常、許可されたテスト対象をマッピングし、アクセス可能な機能、エンドポイント、ワークフローを特定することから始めます。次にアプリケーションとやり取りし、その応答をもとに次のテストを選択します。この反復プロセスにより、承認された範囲内で疑われる脆弱性を調査し、検出結果を検証できます。また、何が起きたのかをチームが把握して結果を再現できるよう、プロセスの証拠も記録します。具体的な手法は、製品、設定、許可された範囲によって異なります。

8. AIペネトレーションテストは従来のペネトレーションテストとどう違いますか？

AIを活用したペネトレーションテストと従来のペネトレーションテストは、エクスプロイト可能性の検証、攻撃経路の調査、影響の実証という基本的な目的を共有しています。主な違いは、その実施方法にあります。従来のペネトレーションテストでは、テスターがアプリケーションを調査し、アプローチを調整する作業に大きく依存します。AIペネトレーションテストではそのプロセスの多くを自動化するため、より多くのアプリケーションに対して、より深いテストを高い頻度で繰り返しやすくなります。範囲の設定、監督、複雑なビジネスコンテキストの解釈には、引き続き人の関与が重要な場合があります。

9. AIペネトレーションテストはDASTとどう違いますか？

DASTは、幅広く再現可能なチェックを用いて、稼働中のアプリケーションやAPIにおける既知の脆弱性パターンを特定します。AIペネトレーションテストはさらに踏み込み、アプリケーションの挙動に応じて調査方法を適応させ、脆弱性を悪用できるか検証し、複数の検出結果が攻撃経路としてどうつながるかを調べることもできます。ペネトレーションテストツールには、スキャナーにAI機能を追加するだけでは不十分です。固定的なチェックを超えて、コンテキストを踏まえた深い検証を行う必要があります。

10. AIペネトレーションテストは完全に自動化されていますか？

AIペネトレーションテストでは、テストプロセスの多くを自動化できます。自動化の程度は、製品や運用モデルによって異なります。範囲の設定、テストの承認、検出結果のレビュー、リスク判断には、引き続き人の関与が必要な場合があります。どこまで自動化され、どの段階で人による監督が必要なのかをチームで評価しましょう。

11. AIペネトレーションテストで、脆弱性が悪用可能かどうかを検証できますか？

AIペネトレーションテストは、疑われる脆弱性を承認された範囲内で再現または悪用できるか確認できるよう設計できます。検証には、問題の挙動の再現、不正アクセスや制御の確認、レビュー用の証拠記録などが含まれます。信頼性の高い攻撃ステップを実証すれば、攻撃を最後まで実行しなくても、リスクを明らかにし、修正につなげるための十分なコンテキストを得られることがよくあります。

12. AIペネトレーションテストで、ビジネスロジックの欠陥や攻撃の連鎖を発見できますか？

AIペネトレーションテストシステムの中には、複数のステップ、ワークフロー、ユーザーロールにわたってアプリケーションの挙動に適応し、ビジネスロジックの欠陥や攻撃の連鎖を調査するよう設計されたものがあります。こうした脆弱性は、単一の技術的な欠陥ではなくコンテキストに依存することが多いため、検出が困難です。カバレッジは製品、範囲、利用可能なアクセスによって異なります。完全なカバレッジを前提とせず、システムがどのような証拠を提示できるかを評価しましょう。

13. AIペネトレーションテストは、人間のペネトレーションテスターに取って代わりますか？

AIペネトレーションテストは、繰り返し可能な調査や検証を自動化することで、テスト能力を拡大できます。一方で、範囲の設定、テストの承認、特殊なビジネスコンテキストの解釈、機微なシナリオの評価、最終的なリスク判断には、引き続き人の専門知識が重要です。多くのプログラムでは、AIを活用したテストと人が主導するテストを組み合わせ、それぞれが最大の価値を発揮する場面で活用します。

AIペネトレーションテストを実際に活用する

適切なアプリケーションを対象に明確な境界を定め、検出結果を既存の修正ワークフローにつなげることで、AIペネトレーションテストの価値を最大限に引き出せます。

14. 組織はいつAIペネトレーションテストを実施すべきですか？

大規模なリリースや重要なアプリケーション変更の前後、脆弱性が疑われる場合、インターネットに公開された高リスクシステムを対象とする場合などに、AIペネトレーションテストを活用できます。また、人が主導する評価の合間に生じるカバレッジの空白を減らすのにも役立ちます。適切な実施頻度は、アプリケーションのリスク、リリース頻度、悪用された場合の潜在的な影響によって異なります。

15. チームはどのアプリケーションを優先すべきですか？

悪用された場合にビジネスへの影響が最も大きいアプリケーションから着手しましょう。優先対象には、インターネットに公開されたアプリケーション、機密データを扱うシステム、ビジネスクリティカルなサービス、複雑な認証や認可を伴うアプリケーションなどが含まれます。最近の大きな変更や既知のセキュリティ上の懸念も、優先度を高める要因です。リスクベースのアプローチにより、より深いテストが最も効果的な保証につながる対象に注力できます。

16. AIペネトレーションテストはどのくらいの頻度で実施すべきですか？

テストの頻度は、アプリケーションのリスクと変更のペースに応じて決めましょう。主な実施のきっかけには、大規模なリリース、アーキテクチャの更新、新たなAPIの公開、認証の変更、インフラや依存関係の重要な変更などがあります。高リスクのアプリケーションにはより頻繁なテストが適する一方、リスクの低いシステムでは軽めの頻度で対応できる場合があります。毎月、四半期ごと、または継続的といった一律のスケジュールが、すべてのアプリケーションに適合することはほとんどありません。

17. チームは検出結果をどのように検証し、修正すべきですか？

有用な検出結果には、問題を再現し、リスクを把握して対応するための十分なコンテキストが含まれている必要があります。対象のアセット、再現手順、裏付けとなる証拠、エクスプロイト可能性、潜在的な影響、修正方法などが含まれます。その後、チームは証拠を確認し、担当者を割り当てます。リスクに基づいて優先順位を決め、修正と再テストを行って、問題が解決したことを確認します。

18. AIペネトレーションテストは、コンプライアンスや保証要件への対応に役立ちますか？

AIペネトレーションテストでは、テスト記録、再現可能な証拠、検証済みの検出結果、再テストの結果を取得でき、コンプライアンスや保証活動を支援できます。ただし、受け入れられるかどうかは、具体的な要件、顧客、監査人、評価者によって異なります。規格によっては、資格を持つ人によるテストや、定められた評価手法が引き続き求められる場合があります。AIペネトレーションテストだけに依存する前に、どのような証拠が受け入れられるかを確認しましょう。

19. どのような安全性、範囲、ガバナンスの管理が重要ですか？

AIペネトレーションテストを承認された範囲内で管理し、安全に実施するには、明確な境界が必要です。チームはテスト範囲を管理し、リスクの高い操作や破壊的な操作を制限する必要があります。監査ログ、データ保護、停止手段は、特に本番環境やその他の機微な環境で、さらなる安全対策となります。

Evoが各アプローチをどう統合するか

Evoは、従来型のアプリケーション、API、エージェント型システム全体でこれらのテスト手法を適用し、幅広いカバレッジと、より深い検証、AI特有の挙動に対するテストを結び付けます。

20. Evo by Snykでは、DAST、AIペンテスティング、エージェントレッドチーミングはどのように連携しますか？

それぞれの機能は、Snykの包括的なオフェンシブセキュリティの取り組みにおいて、異なるテストニーズに対応します。また、どの機能もゼロから始めるわけではありません。テストを開始する前に、Evo COSはSnyk Code、Snyk Open Source、過去のSnyk API & Webスキャンで得られた既存の検出結果を活用します。そのため、AI Pentestingは、これらのツールがすでに検出した問題を何度も見つけ直すのではなく、未検出の脆弱性に推論を集中できます。DASTは、あらゆるエンドポイントを対象に、一般的な脆弱性パターンを網羅的かつ決定論的に検出します。AI Pentestingは、こうした一般的な脆弱性の検出にDASTを活用し、アプリケーションの設計意図を理解しなければ発見できない、アーキテクチャやビジネスロジック上の脆弱性に推論を集中させます。COSのAgent Red Teamingは、AIエージェントがテキストを生成するだけでなく、アクションを実行しツールを呼び出せることに起因するリスク、つまりプロンプトインジェクション、ツールやエージェントの悪用、データの持ち出しを対象にします。偵察によってスタック内のLLMを検出すると、自動的にテストを開始します。

検出結果がレポートに記載される前に、独立した悪用可能性の検証が行われます。検出に使ったシステム自体に確認を任せるのではなく、別のモデルが脆弱性の実在を確認します。これらの機能を組み合わせることで、従来型アプリケーション、API、AI駆動型システムにわたるテストを実現します。各機能はプラットフォームがすでに把握している情報を活用するため、互いに連携して精度を高め合い、ばらばらのツールとして機能することはありません。

リスクに応じたテストを実施

アプリケーションのリスクは、単一のテスト手法だけでは捉えきれません。Evo Continuous Offensive Securityは、アプリケーションごとに適切なテスト手法を組み合わせ、自動で切り替えます。これにより、オフェンシブテストを修正対応やリスク低減に、より直接的につなげます。ご質問がありますか？Evoの担当者に今すぐご相談ください。