ペンリジェント・ヘッダー

AIペンテストレポートの入手方法

AIのペンテストレポートは、再試験に耐えうるものでなければ意味がない。

当たり前のことのように聞こえるが、AIが作成するセキュリティ・レポートのほとんどがここで破綻する。言語モデルは、乱雑なメモを数秒で洗練された文章に変えることができる。スキャナーの出力を要約し、改善策を下書きし、技術的な問題をエグゼクティブ向けに言い換えることができる。いずれも、発見が本物であることを証明するものではありません。信頼できるペンテスト・レポートには、スコープ、テストの境界、再現可能な証拠、エクスプロイトの条件、影響、修正、そして問題を修正する人へのきれいな引き継ぎが必要です。OWASP の現在の報告書ガイダンスでは、報告書は経営幹部と技術スタッフの両方に役立つものでなければならず、スコープ、制限、エグゼクティブサマリー、発見、再現可能な成果物、報告書自体の安全な取り扱いを明確に求めています。NIST SP 800-115 は、テストと報告を、計画、実行、所見の分析、緩和戦略の策定という同じプロセスの一部として位置づけている。PTESは、報告を後回しにするのではなく、エンゲージメントの正式なフェーズとして扱っているため、共有モデルとして依然として有用である。(owasp.org)

AIにPDFを書かせるにはどうすればいいか？問題は、"セキュリティの証拠を、別の人間が検証し、優先順位をつけ、行動できるような報告書にするにはどうすればいいか？"ということなのだ。バグ報奨金プラットフォームは、より運用的な方法で同じことを言っている。HackerOneは、質の高いレポートとは、明確なタイトル、詳細な再現手順、セキュリティチームが問題を理解し再現するのに十分な裏付け資料があるレポートであると定義しています。バグクラウド（Bugcrowd）の文書も同様に直接的で、バグが発見された場所、影響する人、再現方法、関係するパラメータを説明し、ファイルやログのような概念実証のサポートを含める必要があります。(docs.hackerone.com)

チャットの記録がペンテスト・レポートでない理由もそこにあります。PenligentのAIペンテストワークフローに関する最近の文章は、この点を攻撃側から明確に示しています。有効な成果物には、スコープの承認、生のログ、悪用に成功したキャプチャやスクリーンショット、再現可能な検証ステップが必要であり、見た目がスマートな会話だけではありません。同社が公開する製品資料やブログのコンテンツは、レポート作成を、単体の文章作成機能としてではなく、ディスカバリー、検証、証明を通じて実行される証拠チェーンの最終段階として一貫して位置づけている。(ペンリジェント・アイ)

AIペンテストレポートの実際

本物のAIペンテスト・レポートは、従来のコンサルタントが作成する成果物と最新のエビデンス・パイプラインの中間に位置する。スキャナーで書き出したものではない。ルーズなノートでもない。生のBurp履歴でもなく、1ページの「高、中、低」要約でもない。技術的な証拠から組み立てられた構造化されたアウトプットを、複数の対象者向けにアレンジしたものである。OWASP の報告書の構成は、エグゼクティブサマリーと調査結果のセクションを分離し、調査結果のセクションと付録や成果物を分離することで、その分離を明確にしている。NIST も同様に、報告書には複数の対象者が含まれる可能性があるため、複数の報告書フォーマットが必要になる可能性があると指摘しています。(owasp.org)

実際には、有用なAIペンテスト・レポートは通常、少なくとも4つのレイヤーのコンテンツを含んでいることになる。

最初の層は、誰がその作業を許可したのか、何が範囲内であり、何が範囲外であったのか、どのようなアクセスが提供されたのか、そして、どのような制限がテストを形成したのか、といった関与の真実です。OWASPは、スコープ、制限、タイムライン、バージョン管理、および、評価のポイント・イン・タイムの性質を文書化することを明確に推奨しています。なぜなら、セキュリティの発見は、文脈に非常に敏感だからです。ステージング・システムで、認証された低権限のユーザによって発見された保存された XSS は、本番環境での認証されていないコード実行と同じものではありません。(owasp.org)

第 2 の層は、リーダーシップのコミュニケーションである。何が最も重要なのか、どのようなビジネスインパクトがあるのか、修正はどの程度緊急なのか、次にどのような戦略的な修復作業を行うべきか、などである。OWASP のエグゼクティブサマリーガイダンスは、ツールのアウトプットではなく、ビジネスの必要性、ビジネスへの影響、戦略的な提言に重点を置いている。OWASP のリスク方法論は、セキュリティ問題の修正への投資を正当化するのはビジネスリスクであるとしている。(owasp.org)

第 3 のレイヤは、技術的な発見です。参照 ID、タイトル、悪用可能性、影響、リスク、詳細な説明、再現手順、証拠、改善策、裏付けとなる参考文献などです。OWASP は、エンジニアが問題を理解し、再現し、解決するのに十分で、対策を講じるのに十分な技術的詳細を含む発見セクションを推奨している。HackerOneとBugcrowdは、トリアージのレンズを通して、本質的に同じことを言っている。(owasp.org)

第 4 の層は、成果物の保存です。ログ、スクリーンショット、HTTP トレース、サニタイズされたリクエストとレスポンス、適切な場合には概念実証スクリプト、修正後の再テストノートなどです。OWASP の最新の報告ガイダンスでは、開発者が脆弱性を検証し、再テストできるように、curl コマンド、HAR ファイル、CSRF フォーム、単純な自動化スクリプトなど、再現可能なテスト成果物について明確に言及しています。(owasp.org)

報告書をそのように考えれば、AIの役割はより明確になる。AIは、変換、要約、正規化、重複排除、草稿作成に強い。しかし、グランド・トゥルースは苦手だ。スクリーンショットのトークンがすでに期限切れかどうかはわからない。脆弱なパスがプロダクションに属するものなのか、プリプロに属するものなのかもわからない。エクスプロイトに機能フラグが必要なのか、ロケール固有のコンフィギュレーションが必要なのか、管理者ロールが必要なのかは、あなたが言わない限りわからない。つまり、正しいワークフローは "AIが真実を発見する "ことではない。正しいワークフローは、"AIが検証された真実をパッケージ化する手助けをする "ことだ。

SOC 2およびISO 27001に準拠したAIペンテストレポート

AIワークフローで依然として重要なペンテストレポート基準

多くのセキュリティ・チームは、標準を事務処理として扱っている。AIレポーティング・ワークフローを構築する際には、それは間違いである。標準は、モデルが何をすることが許され、何を発明してはならないかを決めるのに役立つ。

OWASP が現在発行している「ウェブ・セキュリティ・テスト・ガイド」は、ウェブに特化したレポーティングの実際的な出発点として最良のものであることに変わりはない。OWASP のガイダンスによると、報告書は、理解しやすく、リスクを強調し、経営幹部と技術スタッフの両方にアピールするものであるべきであり、受信者だけが利用できるように、転送中または静止中に暗号化されるべきである。報告書の構成としては、範囲、制限事項、スケジュール、エグゼクティブサマリー、調査結果のサマリー、詳細な調査結果、再現可能な成果物、方法論とリスク評価の説明のための付録を推奨している。また、報告書はポイント・イン・タイムの評価であることを警告している。これは、AIが作成したアウトプットにおいて保存すべき重要な文章である。(owasp.org)

PTESは古いものであるが、エンゲージメントに首尾一貫した形を与えているため、今でも有用である。PTESは、侵入テストを7つの主要なセクションとして説明し、報告を全体的なプロセスの明確な部分として扱っている。その報告のページでは、目的、方法、結果を異なる聴衆に伝えるために、報告書を2つの主要なセクションに分けると述べている。これは、AIシステムがどのように使われるべきかを自然に表している。エグゼクティブな読者のためのアウトプットと、技術的な読者のためのアウトプット。(pentest-standard.org)

NIST SP 800-115はさらに古いものだが、報告書とテストおよび緩和策を明確に結びつけているため、連邦政府の基本的な参考資料であり続けている。その目的文によると、この文書は、組織が技術的なテストや検査を計画・実施し、発見事項を分析し、緩和策を策定するのを支援することを意図している。また、リンク先のPDFには、報告書には複数の読者が含まれるため、複数の報告書フォーマットが必要になる可能性があるとも書かれている。調査結果がすでに検証されている限り、AIによる起草はまさにそのような場合に役立つ。(NISTコンピュータセキュリティリソースセンター)

バグ報奨金ガイダンスは、もう1つの価値ある現実をチェックするものである。コンサルタントスタイルのペンテストレポートは、報奨金申請よりも広範囲に及ぶことがありますが、中核となる要件は同じです。HackerOneは、明確なタイトル、再現するための詳細なステップ、影響、サポートする成果物を求めています。Bugcrowdは、バグが発見された場所、誰に影響するか、再現方法、どのパラメータが重要か、そして概念実証のサポートを求めている。もしあなたのAIワークフローが一貫してこれらのフィールドを作成できないのであれば、それはペンテストレポートを作成する準備ができていません。(docs.hackerone.com)

ここで、オーバーラップについてコンパクトに考えてみよう：

ソース重視する点AIペンテスト・レポートが重要な理由
OWASP WSTG範囲、制限、要旨、所見、再現可能な成果物、付録、報告書の安全性レポートの骨格を提供し、モデルが欠落したコンテキストを作り出さないようにする (owasp.org)
PTESペンテストのための共通言語、異なる対象者、異なるエンゲージメントフェーズとしてのレポーティング洗練された文章は、完成された婚約とは違うことを思い出させる(pentest-standard.org)
NIST SP 800-115テスト、分析、緩和、複数の対象者同じエビデンスストアから、技術的なアウトプットと経営的なアウトプットを別々に出すことを正当化するのに役立つ(NISTコンピュータセキュリティリソースセンター)
ハッカーワン明確なタイトル、インパクト、再現性、裏付けとなる成果物AIが起草した個々の所見に対する最低基準(docs.hackerone.com)
バグ・クラウド場所、対象、パラメータ、再現性、PoCサポートAIの出力が具体的でトリアージ可能であることを強制する(バグクラウド・ドックス)

もしあなたのワークフローがこの5つの列に一致していれば、あなたはプロダクションにふさわしいものに近づいている。そうでない場合、モデルの質はあなたが思っているよりも重要ではありません。

AIペンテスト・レポートでほとんどのチームが犯す間違い

AIのセキュリティ報告で最もよくある失敗は、文法の間違いではない。誤った自信である。

モデルは、ギザギザの入力を読みやすい出力に平滑化するのが非常にうまい。そのスキルは、基礎となる証拠が不完全な場合に危険なものとなる。スキャナーは "SQLインジェクションの可能性 "を報告する。モデルはそれを「SQLインジェクションの脆弱性が確認され、データ流出が可能」と書き換える。人間がそのシナリオに目を通し、適切なバズワードを見つけ、承認する。その後、エンジニアリング・チームは問題を再現することができず、信頼は低下し、今後報告される重大性の高い報告はすべて、より懐疑的に扱われることになる。

OWASPの報告ガイダンスは、これとは逆の方向性を推し進めている。このガイダンスによれば、発見内容には、悪用可能性、影響、リスク、詳細な説明、詳細な改善策、エンジニアが行動するのに十分な技術的詳細が含まれていなければならない。生の入力が曖昧であれば、この基準を満たすのは難しい。問題は、AIが文章を書くのが下手だということではない。問題は、ワークフローが出力に不確実性を強制しない限り、AIは曖昧さを隠すのが非常にうまいということだ。(owasp.org)

そこで重要になるのが、「証拠第一」の考え方だ。Penligentが公開したAIペンテスト・コピロットに関する資料では、チャットボットの流暢さよりも、適応テスト、証拠収集、検証結果の方が重要であると主張している。これは正しいフレームです。ペンテストレポートは小論文ではありません。それは、何が観察され、何がテストされ、どのような条件が要求され、何が成功し、何が失敗し、何が不確かなままであるかの記録である。モデルがこれらのカテゴリーのどれかを省略することが許されるとき、それは確立されていない主張のゴーストライターのように振る舞い始める。(ペンリジェント・アイ)

この失敗が実際に現れる具体的な方法はいくつかある。

モデルは異なるホストの証拠を統合することがあります。これは、安定したアセット識別子を持たずに、複数のスキャナ出力やスクリーンショットを与えると起こります。脆弱なバージョンの存在」と「到達可能な攻撃経路の確認」を混同してしまうかもしれない。エクスプロイトの前提条件を取り除いてしまうかもしれない。インターネットのトレーニングデータから、「クリティカル」な発見には通常破滅的な表現がつきものだと教えられているため、ビジネスへの影響を誇張してしまうかもしれない。類似のCWEから修正パターンをコピーしても、あなたの環境における実際のコントロールの境界を見逃すかもしれません。

どれも仮定のリスクではない。もっともらしい言葉を予測することを仕事とするシステムからの自然な出力なのだ。解決策は単なるモデルの強化ではない。解決策は、より良い制約である。

SOC2およびISO 27001に準拠したAIペンテストレポート
SOC 2およびISO 27001に準拠したAIペンテストレポート

ペンテストレポートのためのAIデータハンドリング

プロンプティングを心配する前に、証拠がどこに行くかを心配しなさい。

ペンテスト・レポートには、日常的に、秘密情報、アクセストークン、顧客識別子、社内ホスト名、クラウドアカウントID、本番コンソールのスクリーンショット、そして時には、厳重に管理された環境から決して出てはならないシステムのライブデータなどが含まれる。このような資料を間違ったAIサービスにアップロードすると、最初の問題を文書化しようとしている間に、2つ目のセキュリティ問題を引き起こす可能性があります。

ベンダーの公式ドキュメントは、製品の選択が重要であることを明確に示している。OpenAIのAPIドキュメントには、APIに送信されたデータは、あなたが明示的にオプトインしない限り、OpenAIのモデルを訓練または改善するために使用されないことが記載されています。Anthropicの商用プライバシードキュメントには、デフォルトではClaude for WorkやAnthropic APIなどの商用製品からの入力や出力をモデルの学習に使用しないと書かれています。AnthropicのClaude Codeのデータ使用に関するドキュメントには、商用ユーザーは通常30日間の保持期間があり、Claude for EnterpriseのClaude Codeではゼロデータ保持が利用可能であることが追加されています。GoogleのGemini for Google Cloudのドキュメントによると、プロンプトはGoogle Cloudの規約とCloud Data Processing Addendumの下で処理される。しかし、GoogleのGemini API Additional Terms for unpaid servicesにも、品質向上のために人間のレビュアーがAPIの入出力を読み、注釈を付けることがあると書かれており、機密情報、機密情報、個人情報を無給のサービスに提出しないようユーザーに明確に警告している。(OpenAI開発者)

それが現実的なルールセットにつながる。

機密性の高いペンテストエビデンスを処理する場合、データ処理コントロールがきちんと文書化されたエンタープライズまたは商用のAPIパスをデフォルトにしてください。モデルに何かを送信する前に、秘密を取り除くかマスクする。スクリーンショットは、無害な画像ではなく、データが豊富なアーティファクトとして扱う。セッションクッキー、ベアラートークン、個人データ、ローダンプは、保存する特別な理由がない限り、削除する。無報酬のサービスやコンシューマ層のサービスを使用している場合、ベンダーがそのサービスに関して明確にそうでないと言わない限り、機密のペンテストアーティファクトを置く場所としては不適切かもしれないと考えてください。

有用な決定表は次のようなものだ：

AIパス公式に文書化されたデータ姿勢ペンテストレポートに最適使用には注意が必要
OpenAI APIAPIデータは、あなたがオプトインしない限り、トレーニングには使用されません(OpenAI開発者)調査結果のサニタイズ、エグゼクティブ・サマリーのリライト、構造化レポートの作成まだ秘密、顧客データ、トークンを隠している
人間工学的商材とAPI市販のインプットとアウトプットは、デフォルトではトレーニングに使用されない (プライバシー)管理されたエビデンスからのドラフト作成、構造化されたトリアージ、内部レポートの作成標準的なリテンションとローカル・キャッシュの詳細はまだ重要だ (クロードAPIドキュメント)
クロード・コード・エンタープライズ with ZDRエンタープライズ向けには、組織単位でゼロ・データ保持が可能 (クロードAPIドキュメント)より高感度な社内ワークフロー企業のセットアップと検証が必要
Gemini for Google CloudGoogle Cloudの規約およびDPAに準拠します。Google Cloud ドキュメント)すでにGoogle Cloudガバナンスを中心とした企業環境正確なサービス境界とログパスの確認
Gemini API未払いサービス人間のレビュアーは入力と出力を読み、注釈を付けることができる。開発者向けグーグルAI)合成データによる低感度実験ペンテスト・アーティファクトを秘匿するためのデフォルトとしては良くない。

これを正しく理解しているチームは、まず「どのモデルが最適か？どの証拠を、どの保管ルールのもとで、どの再編集を加えて、どのモデルに送ることが合法的かつ運用上可能か？

AIペンテスト・レポートを作成する実用的なワークフロー

AIペンテストレポートを入手する最もクリーンな方法は、証拠収集と言語生成を分離することである。

承認と範囲から始める。すべての発見は、誰がテストを承認したか、どの資産がスコープに含まれたか、テストがどの日付をカバーしたか、どの ID が使用されたか、そしてどのような制限が適用されたか、といった関与の安定した記録を継承しなければなりません。OWASP は、スコープ、制限、タイムライン、およびアセスメントのポイント・イン・タイムの性質を明確に文書化することを推奨します。これを省略すると、後のすべての記述が境界線なしに浮遊するため、レポートは直ちに信頼しにくくなります。(owasp.org)

そして、生の証拠を規律ある方法で収集する。"すべてのアウトプット "という観点で考えてはならない。エビデンスのクラスで考えましょう。典型的なウェブやアプリケーションのエンゲージメントでは、少なくとも以下のものが得られます：

  1. ホスト名、IP、オープン・ポート、ソフトウェア・フィンガープリント、検出されたパスなどの資産およびサービスの証拠。
  2. サニタイズされたHTTPトレース、GraphQLクエリ、RESTコール、クッキー、レスポンスボディ、タイミング動作などのリクエストおよびレスポンスの証拠。
  3. 未認証、低特権、管理者の行動の違いなど、アイデンティティと役割の証拠。
  4. スクリーンショット、キャプチャされたレスポンス、概念実証コード、コマンド出力、または影響を実証する状態変化などのエクスプロイトの証拠。
  5. バージョン文字列、コンフィギュレーションフラグ、ロケール設定、コードページ、オペレーティングシステムの詳細、機能トグル、リバースプロキシの動作などの環境証拠。
  6. パッチが適用されたバージョン、修正後の否定的なテスト結果、問題が解決されたことを証明する新しいスクリーンショットなど、緩和策や再テストの証拠。

その証拠は、どのモデルも見る前に保存しておくべきである。すべてのアーティファクトに、安定した識別子、ハッシュ、タイムスタンプ、資産の関連付けを与える。そうしないと、AIは決して結合されるべきでなかったレコードを喜んで要約してしまう。

次に、証拠を所見記録に正規化する。これが重要な移行ポイントである。モデルには、スクリーンショットとXMLから完全な所見を推測するよう求めてはならない。事実上、「ここに資産、エンドポイント、前提条件、観察された動作、サポートする成果物、可能性の高い分類、残された不確実性、およびレビュアーのステータスがあります」というレコードが与えられるべきである。その時初めて、AIはタイトル、説明、エグゼクティブフレーズ、修正文言、または再テストチェックリストの草案を作成するよう求められるべきである。

起草後、リスクと優先順位付けを追加する。OWASP は、エグゼクティブの読者のために、技術的な影響をビジネス上の影響に変換する必要があること、そして CVSS が必要な業務もあることを指摘している。2026年、CVSS v4.0は、むき出しのCVSS 3.xの基本スコアを中心に構築された古い習慣よりも、脅威と環境のコンテキストをよりきめ細かくサポートしているため、顧客や社内のリスクプロセスが正式なスコアリングを期待する場合、使用する価値がある。NVDは2024年6月に正式にCVSS v4.0のサポートを追加し、FIRSTはCVSS v4.0を基本、脅威、環境、補足の各指標グループにわたって定義しています。(owasp.org)

その後、人間によるレビューを行う。これは、攻撃的な判断力を持つ人が、悪用可能性を確認し、ビジネスコンテキストが正確かどうかをチェックし、改善策が有用なほど具体的であることを確認し、過剰な主張をする言葉を削除するポイントである。レビュアーはチェックリストを持つべきである：手順は再現可能か？成果物は添付されているか？機密事項はマスクされているか？スコープ外の経路は除外されているか。不確実性と仮定は正直に記載されているか？その問題が単なるスキャナーのノイズではないことを実際の人間が確認しているか？

最後に、同じソースから2つのアウトプットを作成する。ひとつは指導者向けの文書で、簡潔でリスク志向、行動重視のものとする。もう1つは、技術報告書または付録であるべきで、詳細で、再現可能で、成果物に裏打ちされたものである。NISTが指摘する、複数の読者に対する複数の報告書形式というのは、今でも全く正しい。(NIST出版物)

コンパクトな分業体制はこうだ：

タスクAIが助けるまだ人間のサインが必要
ノイズの多いスキャナ出力の重複排除はいそうだ。
脆弱性のタイトル案はいはい。
生の証拠をまとめるはいはい、精度と範囲のために
エグゼクティブ・サマリーを書くはいはい。
CWE、OWASPトップ10、CVSSフィールドへのマッピングはい搾取条件が微妙な場合は特にそうだ
補習テキストを書くはい汎用的な修正はエンジニアリングの時間を浪費するからだ
悪用可能性の判断いや、一人ではないはい
重大性とビジネスの優先順位を承認するいや、一人ではないはい
修正を検証済みとしてマークするいや、一人ではないはい

OWASP のトップ 10 のページには、現在 OWASP トップ 10 2025 が最新のリリースとして掲載されており、アプリケーションのレポートにおける分類のための現在の分類法の選択肢となっています。(owasp.org)

SOC2およびISO 27001に準拠したAIペンテストレポート
SOC 2およびISO 27001に準拠したAIペンテストレポート

AIペンテスト・レポートのための構造化された発見スキーマ

どんなモデルにもできる最善のことは、形のない入力を与えるのをやめることだ。

構造化されたファインディング・スキーマは、モデルに狭いレーンを与える。また、どの所見も同じように見えるため、人間によるレビューも速くなる。下書きをするのに十分な完全性を持ちながら、欠落した証拠を黙って「想像」して存在させることができないような厳密性を持つ記録が必要である。

実用的なスキーマには、通常これらのフィールドが含まれる：

フィールドなぜそれが重要なのか
Finding_idチケット、レポート改訂、再試験サイクルにまたがる安定した相互参照
タイトル信頼性を誇張してはならない、人間が読めるラベル
影響を受ける資産問題を適切なホスト、サービス、またはアプリケーションに関連付けます。
エンドポイントまたはロケーション再現性のために重要
前提条件役割、ネットワークの場所、機能の切り替え、ロケール、または構成要件
証拠品スクリーンショット、HARファイル、ログ、リクエストキャプチャ、PoCファイル
観察された行動実際に起こったこと
再現ステップもう一度見るために別のエンジニアができること
exploitability_notes（エクスプロイトビリティ・ノート搾取を容易に、あるいは困難にする要因
技術的影響機密性、完全性、可用性、認証バイパス、権限昇格など
ビジネスインパクト組織が実際に冒すリスク
分類CWE、OWASP Top 10 2025、社内分類法、または関連するコンプライアンス・マッピング(owasp.org)
リスクスコアCVSS v4または内部リスク評価。ファースト)
改善具体的なエンジニアリング・アクション
再試験計画修正後に再チェックしなければならないこと
査読者本文を承認した人
信頼確認済み、可能性が高い、可能性がある、もっと証拠が必要

Penligent社の検証結果に関する公開討論には、これと同じ考え方が見られる。彼らの最近の文章では、一般的なレポートの洗練ではなく、脆弱性のある要求シーケンス、影響を受けるオブジェクト、再現ステップ、生の証拠、および再テストの指示が強調されています。たとえその製品を使うことがなかったとしても、その運営原則は健全である。調査結果は、PDFの見栄えではなく、証拠と再現性を中心に構成されるべきである。(ペンリジェント・アイ)

以下は、レポート生成前の中間オブジェクトとしてうまく機能する最小限のJSONの例である：

{
  "finding_id"："WEB-004"、
  "タイトル"：「サポート・チケットのコメント欄にクロスサイト・スクリプティングが保存されています、
  "affected_asset"："support.example.com"、
  "location"：location": "/tickets/18492/comments"、
  「前提条件"：[
    "認証された低特権ユーザ"、
    "被害者は影響を受けるチケットをブラウザセッションで閲覧しなければならない"
  ],
  "evidence_artifacts"：[
    "artifacts/WEB-004/request.har"、
    "artifacts/WEB-004/rendered-comment.png"、
    "artifacts/WEB-004/session-redacted.txt"
  ],
  "observed_behavior"："チケットスレッドが開かれた際に、被害者のブラウザで実行されたユーザ提供の HTML ペイロード"、
  "reproduction_steps"：[
    "標準サポートユーザーとしてログイン"、
    "チケットを作成または開く"
    "コメント欄にペイロードを送信する"、
    "スレッドにアクセスできる別のユーザとしてチケットを開く"、
    "ブラウザで JavaScript の実行を観察する"
  ],
  "exploitability_notes"：「ペイロードをブロックする CSP はありませんでした。HTMLのサニタイズに一貫性がありません。攻撃には、他のユーザへのチケットの可視性が必要です、
  "technical_impact": 「技術的影響」：「セッションの侵害と被害者コンテキストでのアクションの実行」、
  "business_impact"：「内部サポートセッションの乗っ取りとチケットデータへのアクセスの可能性」、
  「分類」：{
    "cwe"：「CWE-79
    "owasp_top_10_2025"："インジェクション"
  },
  "risk_model"：{
    "cvss_version": "4.0"："4.0",
    "ベクトル"："cvss:4.0/av:n/ac:l/at:n/pr:l/ui:a/vc:l/vi:l/va:n/sc:l/si:l/sa:n""。
  },
  "remediation"：[
    "レンダリングされたコメントに文脈に適した出力エンコーディングを適用する"、
    「リッチテキスト入力に厳密なallowlistサニタイザーを使用する、
    「インラインスクリプトの実行をブロックするコンテンツセキュリティポリシーを導入する、
    「保存された XSS ペイロードの処理のリグレッション・テストを追加する。
  ],
  "retest_plan"：[
    "修正後に正確なペイロードの提出を繰り返す"、
    「保存されたコンテンツがレンダリング時にエンコードまたはストリップされることを確認する"、
    "サニタイズに失敗した場合に CSP が実行をブロックすることを確認する"
  ],
  "confidence"："確認済み"、
  "review_status"："approved_by_human_reviewer": "承認済み"
}

このようなスキーマの価値は美的なものではない。モデルは存在するものからしか起草できないということだ。もし 前提条件 が空白の場合、省略が見えるようになる。もし 証拠品 が空であれば、誰かに気づかれることなく、その問題がひっそりと確定所見になることはない。

セキュリティの証拠をペンテスト・レポートの草稿に変えるコード

検索データを構造化すれば、レポート作成はより安全になる。

一般的なパターンは、真実のソースをJSONまたはYAMLで保持し、最終レポート、クライアントポータル、またはPDF変換パイプラインのためにMarkdownをレンダリングすることである。レンダリングレイヤーは決定論的でなければならない。モデルはフィールドを埋めるのに役立ちますが、テンプレートは各フィールドがどこに行くかを決定する必要があります。

以下は、構造化オブジェクトから技術的な発見セクションをレンダリングする簡単なPythonの例です：

from textwrap import インデント

def render_list(items)：
    if not items：
        return "- None provided"
    return "♪n".join(f"- {item}" for item in items)

def render_finding(finding: dict) -> str：
    classification = finding.get("classification", {})
    risk_model = finding.get("risk_model", {})

    lines = [] (行)
    lines.append(f "### {finding['finding_id']} - {finding['title']}")
    lines.append("")
    lines.append(f "**Affected asset:** {finding.get('affected_asset', 'Unknown')}")
    lines.append(f "**Location:** {finding.get('location', 'Unknown')}")
    lines.append(f "**Confidence:** {finding.get('confidence', 'unspecified')}")
    lines.append("")

    lines.append("**前提条件**")
    lines.append(render_list(finding.get("preconditions", [])))
    lines.append("")

    lines.append("**Observed behavior**")
    lines.append(finding.get("observed_behavior", "No observation recorded."))
    lines.append("")

    lines.append("**Reproduction steps**")
    lines.append(render_list(finding.get("reproduction_steps", [])))
    lines.append("")

    lines.append("** Exploitability notes**")
    lines.append(finding.get("exploitability_notes", "No exploitability notes provided."))
    lines.append("")

    lines.append("**Technical impact**")
    lines.append(finding.get("technical_impact", "No technical impact provided."))
    lines.append("")

    lines.append("**Business impact**")
    lines.append(finding.get("business_impact", "No business impact provided."))
    lines.append("")

    lines.append("**Classification**")
    lines.append(
        f"- CWE: {classification.get('cwe', 'N/A')}n"
        f"- OWASP：f"- OWASP: {classification.get('owasp_top_10_2025', 'N/A')}"
    )
    lines.append("")

    lines.append("** リスクモデル**")
    lines.append(
        f"- CVSSバージョン：f"- CVSSバージョン：{risk_model.get('cvss_version', 'N/A')}n"
        f"- ベクトル：f"- ベクトル：{risk_model.get('vector', 'N/A')}"
    )
    lines.append("")

    lines.append("**Evidence artifacts**")
    lines.append(render_list(finding.get("evidence_artifacts", [])))
    lines.append("")

    lines.append("**Remediation**")
    lines.append(render_list(finding.get("remediation", [])))
    lines.append("")

    lines.append("**Retest plan**")
    lines.append(render_list(finding.get("retest_plan", [])))
    lines.append("")

    return "\n".join(lines)

この種のレンダラーは、現実的な問題を解決する。つまり、文体的なドリフトによって重要なフィールドが削除されるのを防ぐのである。レンダラーが常に再現ステップを期待しているため、レポートは再現ステップを「忘れる」ことができない。

2つ目の有用な部分は、証拠のマニフェスト化である。内部レビューや後の再テストに耐えられるレポートを作成したい場合は、証拠をハッシュ化し、マニフェストを保存します。これは、成果物が発券システム、共有ドライブ、またはクライアントのハンドオフを通じて移動する場合に特に重要です。

#!/usr/bin/env bash
set -euo pipefail

REPORT_ID="engagement-2026-04-webapp"
ARTIFACT_DIR="./artifacts"
MANIFEST="./${REPORT_ID}-evidence-manifest.txt"

:>"$MANIFEST"($マニフェスト)

find "$ARTIFACT_DIR" -type f | sort | while read -r file; do
  sha256sum "$file" >> "$MANIFEST"
完了

echo "マニフェストを作成しました：$MANIFEST"

このスクリプトは、それだけで証拠を信頼できるものにはしないが、後の比較や監査をはるかに容易にする。小さなコントロールに大きな価値があるのだ。

3つ目の要素は、再現性を明確にすることです。OWASP は現在、検証や再テストのために、curl コマンドや HAR ファイルのような再現可能なテスト成果物を明示的に推奨しています。開発者にクリーンで、冗長化されたリプレイパスを与えるレポートは、単に "問題が再現された" と書かれたレポートよりも重要です。(owasp.org)

例を挙げると次のようになる：

curl 'https://api.example.com/v1/profile/12345'
  -H 'Authorization：Bearer RACTED_LOW_PRIV_TOKEN' ☑ -H 'Accept: application/json
  -H 'Accept: application/json' ୧-͈ᴗ-͈.
  -H 'X-Tenant-ID: REDACTED_TENANT'  \
  --path-as-is

エンドポイントが他のユーザーのオブジェクトを返したという観察と対にして、どの識別子が変更され、どのようなステータスコードが返され、なぜそのオブジェクトにアクセスできなかったのかを説明することになる。ポイントは、curlが魔法のようだということではない。重要なのは、明確なリプレイ・アーティファクトがトリアージの摩擦を劇的に減らすということです。

リーダーシップが使えるエグゼクティブ・サマリーを書く

エグゼクティブ・サマリーは、AIが作成したセキュリティに関する文章が最も洗練されているように見えて、最も多くを語らないことが多い場所である。

OWASP の報告書ガイダンスは、エグゼクティブサマリーは、テストの目的、ビジネスコンテキストにおける重要な発見、戦略的な推奨事項を非技術的な言葉で説明すべきであると明言しています。OWASP のリスク手法も同様に、ビジネスリスクこそが修正への投資を正当化するものであるとしています。そのため、エグゼクティブサマリーでは、単に重要度のカウントを繰り返すことはできない。重要度 2、高度 4、中度 7」というリストだけでは、セキュリティリーダーにはほとんど何も伝わらない。(owasp.org)

優れたエグゼクティブ・サマリーは、5つの具体的な質問に答えている。

何がテストされたのか？
組織はなぜ検査を求めたのか？
実際に確認された最も重要な弱点は何だったのか？
このような環境で、エクスプロイトが攻撃者に何をさせるのか。
何を最初に修正すべきか、その理由は？

それは言語の問題ではない。翻訳の問題なのだ。AIはその翻訳を助けることができるが、技術的な発見がすでにビジネスに関連する詳細を捉えている場合に限られる。所見に「チケットコメントにXSSが保存されている」とあった場合、AIは影響を受けるシステムが影響の少ない内部ツールなのか、それともアカウントリセット、支払いデータ、管理者アクションにアクセスできるスタッフが使用する特権的なサポートプラットフォームなのかを知る必要がある。そのようなコンテキストがなければ、モデルは一般的なレトリックをデフォルトとしてしまいます。

悪いAIの概要はこうだ：

評価により、組織のセキュリティ態勢に重大な影響を及ぼす可能性のある複数の重大な脆弱性が特定された。早急な是正が推奨される。

この文章は文法的には問題ないが、運用上は役に立たない。

要約するとこうなる：

この評価では、リモートの攻撃者が通常の権限チェックなしに特権ワークフローに到達する可能性のある2つの問題が確認されました。最も緊急性の高い問題は、カスタマー・サポート・アプリケーションに影響するもので、一般ユーザーによって送信された悪意のあるコンテンツが、サポート・スタッフのブラウザ・コンテキストで実行されました。このような環境では、チケット・データが公開され、通常は内部オペレータのために予約されているアクションが可能になる可能性があります。別の認可の欠陥は、オブジェクトの識別子が変更されたときに、課金APIでクロステナント・オブジェクト・アクセスを可能にしていた。この2つの問題は、顧客の信頼とサポート業務に関連するワークフローに影響を与えるため、次回リリース予定までに修正する必要がある。

そのバージョンは、リーダーシップに何かを決定させる。それは、影響を受ける機能、ビジネス上の結果、修正順序を示すものである。

現実的な対比がここにある：

弱いエグゼクティブ・サマリーの表現より良いエグゼクティブ・サマリーの表現
"重大な脆弱性が発見された"「確認された2つの問題は、認証とクロステナントのデータ境界に影響した。
「攻撃者がシステムを侵害する可能性がある"リモートの攻撃者は、使用されるパスによっては、特権ユーザーのブラウザセッションで行動したり、別のテナントの記録にアクセスしたりすることができる。"
「早急な改善が必要だ「サポートポータルと請求APIは、スタッフや顧客が使用する信頼性の高いワークフローに関わる問題であるため、優先的に取り組む必要がある。
"セキュリティ態勢は改善が必要"「入力処理、承認チェック、再テスト管理は、インターネットに面したサービス間で一貫していなかった。

AIはより良いバージョンを生成することができるが、それは "リーダーシップ・サマリー "を求めるのではなく、ビジネス上の質問に明確に答えるよう強制した場合に限られる。

AIペンテストレポートにおけるCVSS v4とビジネスインパクトの利用

多くのレポートが脈絡のない数字を用いているため、セキュリティチームはいまだに採点について議論している。

OWASPの報告ガイダンスでは、CVSSを必要とする業務もあれば、正式なスコアリングが複雑さを増すだけであれば、より単純なリスクバンドを使った方がよい業務もあると指摘している。これは正しい注意である。それでも、顧客、環境、コンプライアンス・プログラムにまたがって報告するのであれば、正式なシステムは役立ちます。2026年、標準化されたスコアが必要な場合、CVSS v4.0は正しい最新の参照ポイントである。FIRSTの仕様では、CVSS v4.0を4つのメトリクス・グループとして定義しています：ベース、脅威、環境、補足である。NVDによると、CVSS v4.0は2023年11月1日にリリースされ、以前のバージョンよりも粒度が細かくなり、新しいSupplemental指標グループが追加され、深刻度の評価方法が異なっているとのことです。(owasp.org)

これは、AIペンテストレポートにとって重要なことである。FIRSTは、Threatメトリクスは概念実証コードやアクティブなエクスプロイトなどに基づいて深刻度を調整し、Environmentalメトリクスは特定の組織の配備やコントロールのためにスコアを絞り込むと明言しています。これは、実際のペンテストの優先順位付けがすでに機能している方法にはるかに近い。休眠状態の社内プロトタイプのログインバイパスは、収益が重要なプラットフォームの本番管理画面のログインバイパスと同じ優先順位ではありません。(ファースト)

CISAの既知の脆弱性カタログ（Known Exploited Vulnerabilities Catalog）は、もう一つ実用的なレイヤーを追加している。CISAは、KEVカタログについて、組織が脆弱性を管理し、脅威と歩調を合わせるのを支援する方法であると説明し、組織が脆弱性管理と優先順位付けのインプットとしてカタログを使用すべきであると明言している。つまり、AIペンテストレポートは "CVSS 9.8 "で止まってはならないということだ。もし発見された脆弱性が、すでに悪用されていることが知られている脆弱性に対応するものであれば、それは改善策の説明や順序に影響を与えるはずだ。(cisa.gov)

したがって、AIペンテストレポートの優先順位付けのセクションは、少なくとも4つのインプットを組み合わせる：

  1. 問題の本質的な深刻さ。
  2. 搾取が積極的か、容易か、公によく理解されているか。
  3. 影響を受けるシステムのビジネス上の重要性。
  4. エクスプロイトの前提条件と利用可能な代償コントロール。

これは単純な決定表として表現できる：

ファクター質問例なぜそれが重要なのか
CVSS v4 ベース一般的な意味での問題の深刻さは？ベンダーの比較やベースラインの一貫性を保つのに適している(ファースト)
脅威の背景公開されているPoCコードやアクティブなエクスプロイトがあるか？技術的な説明が変わらなくても、現実的な緊急性が高まる(ファースト)
環境的背景その資産はインターネットに接続されているのか、特権的なものなのか、顧客に影響を与えるものなのか。組織内の実際の改善順序を変更する(ファースト)
ビジネスインパクトこの問題が悪用された場合、どのような問題が発生するのか？技術的知見をリーダーシップの行動に変換する(owasp.org)
前提条件どのような役割、構成、機能が存在しなければならないか？虚偽の緊急性や広範な主張を防ぐ(owasp.org)

ここで言うAIの正しい使い方とは、「採点してくれ」ということではない。私の採点根拠が薄いところ、前提条件を文書化していないところ、ビジネスインパクトの表現が証拠と一致していないところを教えてくれ」ということだ。

優れたAI報告がどのようなものかを示す実際のCVE

AIのペンテストレポートが優れているかどうかを見分ける最も手っ取り早い方法は、自明でない条件の実際の脆弱性をどう扱うかを見ることだ。

CVE-2024-3400、PAN-OS GlobalProtect

NVDは、CVE-2024-3400について、特定のバージョンおよび明確な機能設定の下で、Palo Alto Networks PAN-OSのGlobalProtect機能における任意のファイル作成の脆弱性に起因するコマンドインジェクションの問題と説明しており、ファイアウォールのroot権限で認証されていないリモートコードが実行される可能性があるとしている。NVDはまた、Cloud NGFW、Panoramaアプライアンス、Prisma Accessは影響を受けないとしている。2024年4月12日のCISAのアラートによると、Palo Alto Networksは回避策を発表し、影響を受けるバージョンファミリ10.2、11.0、11.1を特定した。CISAはその後、CVE-2024-3400に脆弱なデバイスの偵察とプロービングを含む脅威活動について言及し、KEVカタログの検索結果には、カタログにCVE-2024-3400が表示されている。(NVD)

悪質なAIペンテスト・レポートは、この発見を "パロアルト・ファイアウォールRCE "と書くだろう。これは広すぎます。GlobalProtectの依存関係、コンフィギュレーションの前提条件、影響を受けない製品のリストが失われている。良いレポートであれば、これに近いことを言うでしょう：

  • この問題は、影響を受けるPAN-OSのバージョンと必要なGlobalProtectの条件が存在する場合にのみ該当します。
  • この欠陥は弁護団によって積極的に関連するものとして扱われ、CISAはKEV追跡に追加したため、暴露は特に緊急のものとなっている。
  • 報告書には、テスト者が到達可能性、バージョンファミリ、関連する機能／設定の状態を確認したかどうか、あるいは、その発見がフィンガープリンティングのみに基づくものであり、より深い検証が完了するまで「可能性が高い」ままであるべきかを明示すべきである。

この違いは学術的なものではない。それは、"すべてのパロアルトに直ちにパッチを当てる "か、"該当する攻撃の前提条件を持つ特定の露出したデバイスにまずパッチを当てるか、軽減する "かの違いである。

CVE-2024-4577, Windows の PHP CGI

NVD は CVE-2024-4577 について非常に正確に記述しています: PHP 8.1 以前の 8.1.29、8.2 以前の 8.2.20、8.3.8 以前の 8.3 で Apache と PHP-CGI を Windows 上で使用している場合に、特定のコードページで Windows の Best-Fit 動作により PHP-CGI が文字を PHP のオプションと誤認し、ソースの公開や PHP の任意のコードの実行が可能となる問題です。CISAのKEVカタログ検索結果にも、CVE-2024-4577がカタログに掲載されている。(NVD)

これは、AIのレポートの品質をテストするための完璧なテストである。ずさんなレポートでは、"Windows上の古いPHPがRCEを可能にする "と書かれています。強力なレポートにはこう書かれている：

  • この問題は、Windows上のApacheとPHP-CGIに関連するものであり、単に "どのPHPサーバーでも "ということではありません。
  • コードページの動作は悪用条件の一部であり、明記しなければならない。
  • 改善策は曖昧ではない。修正されたバージョンに移行するか、脆弱な配置パターンを削除することである。
  • PHP-FPMやその他の非CGIモデルを使用している環境では、適用可能性が変わるため、その旨を記述する必要があります。

報告書には、チームがどのようにして適用可能性を立証したのかも記されているはずだ。バージョン開示とサーバーの挙動か？設定への直接アクセス？ラボでの再現？本番環境ではないレプリカに対するPoCか？エンジニアリングチームは、緊急変更手順が正当化されるかどうかを判断するためにそれらを使用するからだ。

CVE-2024-6387, OpenSSH regreSSHion

NVD では、CVE-2024-6387 について、OpenSSH のサーバーにおける CVE-2006-5051 に関連したセキュリティの後退であると説明しています。 エスエスディー また、認証されていないリモートの攻撃者は、設定された時間内に認証に失敗することで、この問題を引き起こすことができるとしている。CVEの記録はこのフレーミングを反映している。(NVD)

実際の悪用可能性は環境とタイミングに大きく依存するため、これも良い例だ。脆弱なAIレポートは、見出しを読むだけで、すべてのニュアンスを "クリティカルな認証されていないSSH RCE "に集約してしまう。より優れたレポートであれば、不確実性が保たれる：

  • この問題はレースコンディションであり、1リクエストのエクスプロイトパスによる決定論的バグではない。
  • 報告書には、ターゲット・バージョンの範囲が確認されたかどうか、システムがインターネットに接続可能かどうか、補償的なコントロールによって被曝の範囲が狭められているかどうか、そして、このエンゲージメントによって悪用可能性が再現されたのか、それとも感受性が確立されただけなのかを明記すること。
  • 修復の項では、パッチの適用、サービスの硬化、一時的な露出の低減を区別すべきである。

AIは不確実性を消し去る傾向がある。優れたペンテスト・レポートはその逆を行く。重要な部分で不確実性を可視化するのだ。

CVE-2024-3094、xzバックドア

NVD は、CVE-2024-3094 はバージョン 5.6.0 以降の xz アップストリームの tarball に悪意のあるコードが含まれているとし、次のように説明している。 .m4 リポジトリに存在しないtarballsのファイルが、複雑なビルド・プロセスを通じて、ビルド中にコードを修正するために使われた。 リブルズマ.Red Hatのインシデント対応に関する投稿には、有用な環境の詳細が追加されている。 システムディー そして エスエスディーレッドハットの対応は、すべてのxzユーザーが等しく危険にさらされていると仮定するのではなく、影響を受けるかどうかを判断することに重点を置いていた。(NVD)

これは、AIレポートがしっかりとした根拠に基づいていなければ、危険なまでに誤解を招きかねない典型的なケースである。

xzライブラリのバージョンが存在する。

良い報告がある：

  • 関連するのは、影響を受けたアップストリームのtarballリリースと、実際に特定の環境でビルド、パッケージ化、デプロイされたものとの区別である。
  • リポジトリの状態とtarballの状態が同一ではなかった。
  • 露出はパッケージ名だけでなく、ビルドやランタイムの特性にも依存する。
  • 対応策には、バージョン分析とサプライチェーンの実績確認の両方が必要だった。

それこそが、AIペンテストレポートが証拠第一であるべき理由である。言語レイヤーは、サプライチェーンイベントを素朴な「バージョン・イコール違反」ストーリーに平坦化することを決して許してはならない。

この4つのケースから得られるより広範な教訓がここにある：

CVEAIがスキップしてはならないこと良い報告書とは
CVE-2024-3400機能と構成の前提条件影響を受ける PAN-OS のコンテキスト、公開パス、検証方法、緩和の優先度 (NVD)
CVE-2024-4577Windows、Apache、PHP-CGI、コードページ条件正確な展開パターン、固定バージョン、適用可能性の証明(NVD)
CVE-2024-6387レースコンディションの不確実性確認されたバージョン、曝露サーフェス、悪用可能性に関する注意事項、パッチ計画(NVD)
CVE-2024-3094ターボールとレポ、ビルドパス、ターゲット条件の狭さプロバンス、パッケージソース、デプロイメント実態、封じ込めステップ(NVD)

AIペンテストレポートは、そのような区別を平滑化するのではなく、維持することで信頼を得る。

AIハッカーツールを試す
AIハッカーツール無料お試し >>

AIを使ってペンテスト・レポートを書くときによくある間違い

失敗したAI報告プログラムのほとんどが同じ間違いを犯すのは、ツボが予測できるからだ。

最初の間違いは、ノイズの多いスキャナ出力を、確認された発見事項として宣伝することである。OWASPの報告ガイダンスでは、技術的な発見には悪用可能性、影響、詳細な説明が含まれることを期待している。それは、問題が検証の閾値を超えたことを前提としている。もし、あなたのワークフローが「SSRFの可能性」や「SQLインジェクションの可能性」をツールからそのまま最終報告書へと昇華させるのであれば、問題はモデルにはありません。問題は検証ゲートの欠如である。(owasp.org)

つ目の過ちは、スコープの境界を見失うことである。誰が作業を許可したのか、どの ID が使用されたのか、何が範囲外だったのかを省略した報告書は、 影響を誤って表現する可能性がはるかに高くなります。OWASP は、スコープと制限を含めることを明確に推奨しています。(owasp.org)

3つ目の間違いは、モデルをある環境から別の環境へと一般化させてしまうことだ。これは、マルチテナントのSaaSや多段階のデプロイメント・パイプラインで常に起こることだ。AIがデプロイの規律ではなく、可読性のために最適化するため、ステージングだけの問題が、物語の中で本番環境の問題になる。

4つ目の過ちは、一般的な修復である。時間を無駄にするので、開発者はこれを嫌う。「適切な入力検証を適用する」は修正ではない。それはスローガンだ。有用な改善策は、具体的なコントロールギャップを、影響を受けるコードパスやアーキテクチャの決定に結びつけるものである。だからこそAIは、曖昧なカテゴリーラベルからではなく、エクスプロイトパスと観察された故障モードを含む構造化された発見記録から、改善策を立案すべきである。

第五の過ちは、再テストの帳簿付けが弱いことである。OWASPの最新ガイダンスでは、修正の検証に役立つ再現可能な成果物について特に言及している。成熟したAIレポートワークフローは、オリジナルの再現ステップを保持し、何が変更されたかを記録し、再テスト状態を作成する。もしあなたのレポート・パイプラインがPDFエクスポートで終わっているなら、それは不完全です。(owasp.org)

6つ目の間違いは、技術的な表現とエグゼクティブな表現をひどく混ぜ合わせてしまうことだ。リーダーシップのセクションはメロドラマ的になり、技術的なセクションは曖昧になる。理由は簡単で、同じプロンプトが両方に使われているからである。NISTの複数の聴衆による観察は、異なるアウトプットは意図的に異なるものであるべきだということを思い出させてくれる。(NIST出版物)

第7の過ちは、レポートのセキュリティを忘れていることである。OWASPは、受信者だけが使用できるようにレポートを保護し、暗号化することを推奨している。AI時代には、成果物が最終的な納品までに多くのシステムを経由することが多いため、このガイダンスはより重要になる。(owasp.org)

これは、ワークフローの中で、チャットのみのアプローチよりもエビデンス主導のプラットフォームの方が理にかなっている部分である。Penligentの公開資料では、検証済みの調査結果、編集可能なレポート、再現可能なPoC、以前のテスト段階に結びついたワンクリックのレポートが繰り返し強調されている。チームが特定のプラットフォームを使うにせよ、社内でパイプラインを構築するにせよ、原則は正しい。レポートは、AIが生成した散文の切り離されたブロックではなく、追跡されたプロセスの目に見える先端であるべきだ。(ペンリジェント・アイ)

ペンテストレポートのための適切なAIセットアップの選択

適切なセットアップは、何を最適化しようとしているかによる。

一人の研究者や小規模な社内チームであれば、構造化されたフォルダ、ファインディングスキーマ、スクリプト可能なレンダラー、明示的なデータコントロールを備えた商用APIが、最もシンプルで使い勝手の良いセットアップであることが多い。これにより、ドラフト生成、一貫したフォーマット、タイトルのクリーンアップ、エグゼクティブサマリーのアシスト、修正フレーズなど、ほとんどの価値を得ることができる。

社内のAppSecやレッドチームの機能であれば、通常はもっと必要だろう。その時点で、レポートは単なる文書ではない。ライフサイクルの一部なのだ。アセットID、エンゲージメント記録、レビュアーのサインオフ、添付ファイルの保管、再テスト履歴などが必要です。そこで、エビデンス重視のワークフローが、その週で最もホットなモデルよりも重要になるのです。

コンプライアンスに敏感な環境を扱っている場合、正しい質問は "このシステムは後で何を証明できるのか" になります。Penligentの公開サイトでは、SOC 2とISO 27001に準拠したワンクリック・レポートを謳っており、製品概要には、資産の発見からエクスプロイトの実行、最終的なレポート作成までのパイプラインが説明されている。このようなエンド・ツー・エンドの枠組みは、コンプライアンスや顧客保証がPDFだけを気にすることはほとんどないため、有用である。なぜなら、コンプライアンスと顧客保証はPDFだけを気にすることはほとんどないからです。彼らが気にするのは、レポートが証拠の再利用と人間の承認を伴う反復可能なワークフローに対応しているかどうかです。(ペンリジェント・アイ)

だからといって、すべてのチームにオールインワンのプラットフォームが必要というわけではない。選択するアーキテクチャが、少なくともこれらの機能をサポートしていなければならないということだ：

  • 構造化された調査結果の安定した真実の源
  • ハッシュまたは同等のコントロールによるアーティファクトの保持
  • 重大性とビジネスインパクトが確定する前に、人間によるレビューが行われる。
  • テンプレート駆動型レポートレンダリング
  • 元のエビデンスとステップを再利用する再試験パス
  • 契約内容の機密性に見合ったデータの取り扱い管理

そのうちの1つが欠けていれば、AIペンテストレポートのプロセスは見た目よりも弱い。

再検査に耐えるエビデンス・パイプラインの構築

最強のAIペンテスト・レポート・ワークフローは、再試験から逆算して構築される。

6週間後、エンジニアリングが問題を修正したと発表した後のレポートを想像してみてください。2人目のテスターは、元の手順を安全に再現し、新しい動作と古い動作を比較し、自信を持って問題を解決したとマークできるでしょうか？もし答えがノーなら、元のレポートは不完全だったということになる。

OWASPの現在のガイダンスは、再現可能な成果物と、方法論とリスク評価の説明のための付録を特に推奨しているので、ここで役立つ。これによって、パイプラインを自然に構成することができる。オリジナルの報告書には、要約と所見が含まれる。付録または添付書類一式には、証拠と再試験の成果物が含まれる。再試験レポートでは、同じ発見 ID を参照し、エクスプロイト・パスがまだ機能するか、部分的に機能するか、または変更されたかを注記します。(owasp.org)

実用的な再試験対応ワークフローには、次のような段階がある：

  1. キャプチャ テスト中の生のアーチファクト。
  2. ノーマライズ それらを構造化された発見記録にまとめる。
  3. ドラフト AIによる物語セクション。
  4. レビュー 人間と。
  5. レンダー をレポート形式に変換する。
  6. トラック 修復の所有者と州。
  7. リプレイ 修正後のオリジナルの証拠
  8. 記録 同じ所見IDでの再試験結果。

運用規律は、どのモデルの機能よりも重要である。

ミニマム・エビデンス・マニフェストには、以下を含めることができる：

  • ID検索
  • アーティファクト・ファイルのパス
  • アーティファクト・ハッシュ
  • 資産ID
  • 収集日
  • ツールまたは収集方法
  • レビュアー
  • 除菌状態
  • 再試験の妥当性

それは、1つの問題には重く感じるかもしれないが、より大きな契約や繰り返される顧客環境では、すぐに元が取れる。

今週、AIペンテスト・レポートを入手するための最低限実行可能な方法

理論的なことよりも実用的なことを望むのであれば、これは合理的な最初の実装の道である。

初日には、以下のセクションからなる固定レポートのテンプレートを作成する：

  • 婚約の範囲と制限
  • 要旨
  • 調査結果の要約表
  • 詳細な調査結果
  • 方法論と成果物を含む付録

次に、先に示したJSONオブジェクトのような構造化された検索フォーマットを定義する。そのオブジェクトを、モデルが起草できる唯一のものとして使用します。生のスクリーンショットやログをレポートプロンプトに直接入力しないでください。

次に、証拠をサニタイズし、パッケージ化する。トークン、顧客識別子、秘密をリダクトする。成果物セットをハッシュ化する。マニフェストを保管する。

そして、4つの具体的な仕事だけにAIを使う：

  • 大まかなメモを一貫性のあるファインディング・タイトルに書き換える
  • 検証された分野から技術的記述を作成
  • レビュアーから提供された文脈からビジネスインパクトの段落を起草する。
  • 承認された調査結果のみからエグゼクティブ・サマリーを起草

その後、チェックリストを使って人間によるレビューを行う：

  • レポートからこれを再現できますか？
  • 搾取条件は正確か？
  • 影響を受ける資産は正しいか？
  • ビジネスインパクトは具体的で誠実か？
  • 改善策は実行可能か？
  • 遺品は添付され、消毒されているか？
  • この発見に署名するだろうか？

答えが "YES "の場合、報告書をレンダリングし、OWASPのアドバイスに従っ て暗号化された形式、あるいはアクセス制御されたチャネルを通じて、報告書を安全なも のにする。(owasp.org)

日ではなく1週間なら、さらに3つのことを追加する：

  • シンプルなチケット同期により、すべての発見IDが修復オーナーにマッピングされます。
  • 再試験状況フィールド
  • CVSS v4と環境およびビジネス修飾子を組み合わせたスコアリング・ヘルパー

AIは私が何かを書くのを助けてくれた」から「AIは私が実際に信頼できる報告ワークフローの一部である」に移行するのに十分である。

AIペンテスト・レポートの入手方法に関する本当の答え

AIのペンテストレポートを得るには、AI以外のペンテストレポートを得るのと同じように、慎重に証拠を集め、文脈を保ち、発見を正直に検証し、その結果から意思決定をしなければならない人々のために書くのだ。

AIはそのプロセスのスピードと人間工学を変える。立証責任は変わらない。

上手に使えば、AIは所見のクラスタリング、タイトルの起草、技術的なインパクトをビジネス用語に翻訳、書式の一貫性の維持、再試験ノートの作成にかかる膨大な時間を節約できる。下手に使えば、エレガントなフィクションで組織を溢れさせることになる。

だから、守るべき基準はシンプルだ。報告書のすべての重要な文章は、スコープ、証拠、または明確に述べられたレビュアーの判断にたどりつけるものでなければならない。すべての所見には、再現可能なステップがあるべきである。すべての重大性の記述は、技術的な現実と環境的な現実の両方を反映したものでなければならない。すべてのエグゼクティブステートメントは、ビジネス上の結果に対応するものでなければならない。そして、すべての報告書は、次の再テストを難しくするのではなく、容易にするものでなければならない。

そうやって、エンジニアリング、リーダーシップ、顧客、監査人に送る価値のあるAIペンテスト・レポートを手に入れるのだ。

参考文献

記事を共有する
関連記事
ペンリジェント・フッター
jaJapanese
en_USEnglish de_DEGerman fr_FRFrench es_ESSpanish pt_BRPortuguese ko_KRKorean hi_INHindi arArabic tr_TRTurkish he_ILHebrew jaJapanese