ペネトレーションテスト企業はAI時代にどう適応するか

今、あらゆるペネトレーションテスト企業が同じ圧力にさらされています。AIツールは高速かつ低コストで、能力も高まり続けており、企業がポリシーを定めているかどうかに関わらず、テスターたちはすでにそれを使い始めています。

AIがすでに自社のワークフローに入り込んでいる可能性は非常に高いと言えます。問題は、それが正式な形で導入されたものなのか、それとも従業員個人のClaudeアカウント経由で入り込んだものなのか、という点です。そしてこの業界においては、その違いが極めて重要な意味を持ちます。

誰も語りたがらないクラウドAI問題

開発者がChatGPTにコードを貼り付けた場合、最悪でもライセンス上の問題で済むかもしれません。しかしペネトレーションテスターが顧客の調査結果に対して同じことをすれば、話は別です。それは、自らコントロールできない第三者のクラウドインフラに、企業の脆弱性を詳細に記した地図をアップロードしてしまうことを意味します。

これはポリシー違反にとどまらず、顧客の機密保持契約(NDA)違反、さらに規制業界であればGDPRやHIPAAといったコンプライアンス枠組みへの違反となる可能性もあります。

ランサムウェア対策ソフトウェア

OpenAI、Anthropic、Googleといった大手AIプロバイダーは、いずれも優れた製品を提供しています。しかし、これらのクラウドホスト型モデルは、攻撃的セキュリティ業務が扱うデータの機密性を前提に設計されたものではありません。

顧客のスコープ文書、発見された脆弱性、ネットワーク図、テスト中に見つかったハードコードされた認証情報――これらは自社のインフラの外に出るべきではなく、ましてや自らが同意していない学習パイプラインに取り込まれるべきものでもありません。

実際のところ、企業が公認のAIワークフローをテスターに提供しなければ、彼らは自分たちで独自のワークフローを構築してしまいます。そしてその際、顧客との契約内容にまで気を配っている可能性は低いでしょう。

正しいアーキテクチャはすでに存在する

解決策はAIを禁止することではありません。すでにその流れは止められないところまで来ており、禁止を試みる企業では、テスターが隠れてAIを使い続ける一方、AIを正しく取り入れた競合他社がスピードと成果物の質で先行することになるでしょう。

正しい答えは、自社が管理するインフラ上にAIを内製化し、顧客データが決してネットワークの外に出ないようにすることです。

セルフホスト型のAIモデルは大きく成熟してきました。今やローカルで有能なモデルを運用することは、単なる研究プロジェクトではなく、実用的な選択肢のひとつとなっています。

そして、セキュリティ業務向けに特別に構築されたオーケストレーション層とセルフホスト型モデルを組み合わせれば、顧客の攻撃対象領域を第三者に渡すことなく、AIによる生産性向上のメリットを得ることができます。

サイバーセキュリティ企業向けに特化して設計されたAI

PentestPadは、生のメモを顧客に提出できる報告書へと変換する作業にかかる時間を短縮しつつ、プロジェクト全体の整理も行えるペネトレーションテスト報告書作成ツールです。

このツールを利用しているチームは、必ずしも同じ業態ではありません。顧客にセキュリティテストを提供する企業もあれば、自社システムを社内でテストするチームもあります。また、複数の外部プロバイダーを同時に統括し、調査結果を一箇所にまとめるためにこのプラットフォームを使用している組織もあります。

日常的な業務としては、プロジェクト管理、コラボレーション、再テスト、報告書生成が挙げられます。通常であればペネトレーションテストの周辺に散らばりがちなツール群の多くも、このプラットフォーム内に統合されています。メモ、証拠や添付ファイル、調査結果へのコメント、提案書、スコープのインポートなどです。

これにより、走り書き用のファイルや共有ドライブ、スプレッドシートに頼る必要が少なくなります。

固定されている部分はほぼありません。報告書は汎用テンプレートではなく自社独自のテンプレートから生成され、顧客ポータルは自社ドメイン上で自社ブランドをまとうことができ、調査結果の背後にあるフィールド・レイアウト・ステータスもベンダー側から引き継ぐのではなく、自チームが独自に定義できます。

AIアシスタントが従う指示についても自社で定義できるため、下書きは汎用的なハウススタイルではなく、自社の手法と言葉遣いに沿った形で返ってきます。

これはシステムの稼働環境についても同様です。PentestPadはマネージドクラウドサービスとしても、自社インフラ上への完全なセルフホスト型(エアギャップ環境を含む)としても利用可能で、ライティングアシスタントもベンダーのモデルではなく、自社ネットワーク内にセルフホストしたモデルに接続できます。

この最後の選択肢こそ、ペネトレーションテストチームが頭を悩ませてきた部分です。調査結果とは、顧客の未修正の脆弱性そのものです。それをOpenAIやAnthropicのAPIに渡すということは、顧客が同意したことのない企業にデータを送ることを意味します。

脆弱性発見サービス

ほとんどの顧客契約では、顧客データを取り扱うことのできる外部企業が一覧で定められていますが、AIモデルベンダーはそのリストに含まれていません。

そこに新たな企業を加えるということは、すべての顧客に告知し、通常は承諾のサインを求めることを意味します。しかもその間、データは自社が選んだわけでもない場所に、他者が決めた期間だけ置かれ続けることになります。モデル自体を自社で運用すれば、この問題は解決を迫られるのではなく、そもそも発生しなくなります。

このプラットフォームはMCP経由で外部に公開されているため、エージェントは推測に頼ることなく、実際の調査結果・フィールド・テンプレートに対して直接作業できます。

人間だけでなくエージェントのためにも設計

PentestPadは、キーボードの前に座る人間だけでなく、ソフトウェアによって操作されることも前提に設計されており、その操作を担うモデルを自社ネットワーク内に置くことができます。

これこそが、先述の問題に対する答えそのものです。アシスタントをセルフホスト型のLLMに接続すれば、顧客のコンテンツが自社の境界を越えることは一切ありません。

ライティングアシスタントは、テスターがすでに手元に持っている情報をもとに動作します。スキャナーの出力結果、Burpの調査結果、スクリーンショット、ログファイルなどを渡し、証拠を添付するだけで、組織が定義した指示に沿って書かれた構造化された調査結果が返ってきます。つまり、下書きは汎用形式ではなく自社の書式で届くのです。

内部構造としては、PentestPadはMCP経由で外部に公開されています。手法、過去の調査結果、テンプレート、調査結果のフィールド、そしてそれらを記述するためのルールはすべてプラットフォーム内に存在し、MCPサーバーはそれらに対して14種類の型付きツールを公開しています。プロジェクトや調査結果の検索から、テンプレートを用いた新規登録、再テスト後の修正状況の更新、コメントの追加まで対応しています。

プラットフォーム自体が唯一の正しい情報源であり続け、エージェント側は自らの状態を一切保持しません。

エンドツーエンドで運用する場合、スタックは3つの要素から構成され、そのすべてが自社管理下のハードウェア上で動作します。PentestPadがナレッジベースを担い、ローカルモデルが推論を担当し、ターミナルハーネスがその両者をつなぎます。

PentestPad自身のチームは、ハーネスとしてOpenCodeやClaude Codeを用いながら、Ollama経由でQwen3-Coderを使用しています。

これを自前で構築したくないチーム向けには、macOS、Linux、Windows向けのコマンドラインエージェントも用意されています。これには、Web、ネットワーク、偵察、API、モバイルテストにわたる6種類のカスタマイズ可能な専門エージェントに加え、手法選定やツール選択を担う汎用エージェントも含まれています。

報告書はどのように作られるのか

プロジェクトには、顧客情報、評価の種類、スコープ、担当テスター、タイムラインが紐づいています。テストの進行に応じて調査結果がそこに追加されていくため、スコープ内容・担当者・これまでの発見事項が、フォルダやチャットスレッド、スプレッドシートに分散することなく一箇所にまとまります。

各調査結果には、タイトルと説明、影響を受ける資産、深刻度、修正方法、参考資料、裏付けとなる証拠が紐づいています。

深刻度は組み込みのCVSS計算機で設定でき、チームが独自の影響度・発生確率フィールドを非表示にしている場合は、リスク評価がCVSSスコアから自動的に導出されます。

調査結果は必ずしも空の状態から作り始める必要はありません。プロジェクトと並行して、再利用可能な脆弱性テンプレートのライブラリが用意されており、名前による検索や評価領域によるフィルタリングが可能です。テンプレートをインポートすると、新しい調査結果のあらゆるフィールドが自社独自の説明文・修正方法・CVSSベクトルで自動的に埋まり、案件固有の詳細を記入するだけで済みます。エグゼクティブサマリーについても同様の仕組みです。

脆弱性発見サービス

調査結果は、チームが定義したステータス(下書きから完了まで)を経て進行していきます。コメントは文書全体ではなく個々の脆弱性に紐づけられ、改訂履歴によって下書き間の変更点を確認できます。

報告書自体は自社のファイルをもとに構築され、データが入るべき箇所にはプレースホルダーが配置されます。この変換作業はPentestPadチームが無償で対応します。ゼロから始めるチーム向けには、無料のペネトレーションテスト報告書テンプレートも用意されています。

報告書設定画面。テンプレートおよびビルド内容をここで選択します。

生成処理では、構造化されたデータがそのテンプレートに流し込まれます。目次はビルドのたびに再生成され、グラフや表は調査結果から自動的に作成され、相互参照は動的リンクシステムによって解決されるため、コンテンツが移動しても参照関係は正しく保たれます。

再利用可能なフィールドテンプレートは、報告書レベルのフィールドと調査結果レベルのフィールドの両方をカバーしており、ライブプレビューによってエクスポート前にブラウザ上で文書を確認できます。出力される内容には、エグゼクティブサマリー、スコープ、手法、調査結果、技術的詳細、修正推奨事項、および補足情報が含まれます。

1つのプロジェクトが複数の評価領域にまたがることもでき、各調査結果には出所となる領域のタグが付与されます。そのため、同じ顧客に対するWebアプリケーションテストとネットワークテストが、2つの別々の成果物としてではなく、調査結果がグループ化された1つの報告書として提出されます。

プラットフォームには、CVSSベクトルの解析やリスク評価の導出、深刻度別の調査結果件数の集計、IPアドレスのみ・URLのみへのスコープ絞り込みといった、テンプレート用関数のライブラリが標準搭載されています。

独自のJavaScript関数を定義し、テンプレートから呼び出すことも可能です。報告書はAPI経由で生成できるため、パイプラインが人手を介さずに報告書を生成することも可能です。完成したPDFには、指定したパスワードで暗号化を施すこともできます。

個別のDOCXファイルやPDFファイルは、報告書全体を再構築することなく、既存の報告書内で差し替えることができます。

ブランディング、アクセス管理、データ保持

ホワイトラベル化はロゴ、配色、ドメインをカバーしているため、進捗確認のためにログインしたユーザーは、ベンダーのブランドではなく自社ブランドの画面にたどり着きます。これは2要素認証の確認画面に至るまで徹底されており、エクスポートされる報告書にも同じブランドが反映されます。

アクセス制御は、ロール単位ではなく、より細かい粒度で設定できます。標準ではPentester、Manager、Adminのロールが用意されていますが、プロジェクト・調査結果・報告書・顧客に関する権限セットから、独自のロールを定義することも可能です。1人のユーザーに複数のロールを割り当てたり、ロールにそぐわない部分を個別の権限で上書きしたりすることもできます。

ロール管理自体も独立した権限として扱われているため、ロールの編集権限を渡すことなく、チーム管理の権限だけを付与することができます。

顧客アカウントはAPI経由で作成・招待され、顧客用のAPIキーは自社チームのものとは別に制限をかけることができます。

権限は固定的なロールではなく個別のゲートとして扱われ、ロールごとに設定した上でユーザーごとに上書きすることも可能です。

アップロードされたファイルはマルウェアスキャンにかけられ、検出されたファイルは拒否されます。ただし、権限を持つユーザーであれば、この判定を上書きして既知のサンプルをあえてアップロードすることも可能です。マネージドサービスでは常にスキャンが有効になっており、セルフホスト環境では任意設定となります。

データのライフサイクルについても同様に設定可能です。休止状態のプロジェクトは自動的にアーカイブされ、アーカイブ済みの報告書は、誰かが気づくまで蓄積され続けるのではなく、自ら設定したスケジュールに従って削除できます。

デプロイ方式、コンプライアンス、料金体系

セルフホストはすべてのプランで利用可能です。これは、顧客契約や社内ポリシーによって報告書データの保存場所が制限されている場合に重要な意味を持ちます。

セルフホスト型のインスタンスはバージョン確認用のエンドポイントにアクセスし、更新通知を発します。そのため、隔離された環境であっても、自らが最新版から遅れていることを把握できます。

プロジェクトデータ、証拠、調査結果ライブラリ、報告書テンプレート、ユーザー設定は、DOCX、PDF、XLSX、またはAPI経由でエクスポートできます。

コメント

必要に応じてご利用ください。どちらか一方、両方、あるいはどちらも使用しなくても構いません。

「顧客の調査結果がどこに置かれることを許されるかを決めるのは、それを預かるチーム自身です。そして多くの場合、それは自社のインフラの外部を一切含みません。私たちはこの要件を軸にAIを設計しました。そのため、モデルはチームが必要とする場所であればどこでも――完全に自社ネットワーク内であっても――動作させることができます。」

ルカ・シキッチ(Luka Šikić)氏、PentestPad CEO

「ほとんどのチームは、フィールド・レイアウト・ステータスを自分たちの既存の業務の進め方に合わせて作り替え、顧客に見せる部分を選び、ポータルに自社ブランドを施し、調査結果をAIにどう記入させるかについて独自の指示を書いています。まさにそうした使い方ができるように設計したのです。」

ミルナ・ノヴァク(Mirna Novak)氏、PentestPad ディレクター