AIペネトレーションテストの実行ログは、何を記録すべきか

決定的なスキャナは、二回実行しても同じ結果を返す。エージェント型のペネトレーションテストは返さない。それは欠陥とは限らない。環境の状態、スコープ内の認証情報、モデルの判断は、実行ごとに変わるからだ。

問題は再現性の有無ではなく、別のエンジニアが読んで同じ結論に到達できる記録が残るかである。

開示: 筆者は HackBox の開発に関わっている。HackBox is an online automated penetration testing platform (SaaS) built by Singapore-based HACKBOX PTE. LTD.

再現性が壊れる三層

独立に変わりうる層が三つある。

  1. 環境。 実行の間に再構築されたステージング、火曜に入ったWAFルール、解決先が変わった内部DNS。
  2. 認証情報。 権限が変わった低権限アカウント、途中で失効したトークン。
  3. 経路選択。 月曜はホストAで認証情報の再利用を試し、木曜はAPIに直行した。

一层と二層は資産の事実であり、実行の入力として記録されるべきものだ。三層は判断であり、主張が必要になる。何を見て、何を検討し、何を選び、なぜか。

所見だけを記録するツールは、三層を捨てている。すると「二回目で結果が違う」が説明不能になる。環境が変わったのか、モデルが迷ったのか、一回目が運が良かったのか、区別できない。

使える判断記録の中身

思考の逐語ログではない。分岐点ごとの、四つのフィールドを持つ構造化記録である。

{
  "run_id": "r-2026-11-06-0417",
  "target": "staging.example.com",
  "step": 34,
  "observed": {
    "host": "10.4.2.18",
    "service": "http/8080",
    "banner": "Spring Boot 3.2",
    "auth": "none",
    "evidence_ref": "art-0091"
  },
  "options": [
    {"action": "cred_reuse", "score": 0.31},
    {"action": "auth_logic_probe", "score": 0.22},
    {"action": "pivot_via_trusted_service", "score": 0.47}
  ],
  "chosen": "pivot_via_trusted_service",
  "rationale": "ステージングが本番とDBホスト名を共有（/actuator/env）、bundle.js内のAPIキーが同じバックエンドを指す",
  "outcome": {"finding": "F-011", "state": "exploited"}
}

これが与えてくれるものは四つある。

  • 帰属。 二回目が違うとき、判断ログを差分する。同じ観測で別の選択をしたならモデルが変わった。新しい観測があるなら環境が変わった。どちらも答えであり、どちらも所見一覧からは得られない。
  • レビュー。 熟練した担当者なら数分でログを読み、誤った推論を指摘できる。「その /actuator/env の露出はDB共有を意味しない、設定共有を意味する」と、所見になる前に。
  • チューニング。 options[].score はエンジンの事前分布が見える場所だ。cred_reuse が常に最高点なら、それは癖であり、癖は盲点である。
  • 証拠との紐付け。 evidence_ref が判断と、取得したリクエスト・レスポンスを結ぶ。判断の伴わない所見は、言葉を足したスキャン結果にすぎない。

ログで見るべき四つの兆候

最初の十回で確認する価値があるパターン。

固定順序。 options の並びが対象に関係なく同じなら、モデルは観測を使っていない。異なる対象間でスコア差が0.05を超えて変わらないなら、ランキングは飾りである。

深さの崩壊。 シェルを取った直後にレポートへ飛ぶ。state: "exploited" 以降のステップが5未満なら、エンジンは足場で止まっている。

孤立した所見。 直前の判断が無い所見。モジュールが発火し、モデルは選んでいない。間違いとは限らない（決定的モジュールも走るべきだ）が、その場合レポートは「どちらがどちらか」を書く必要がある。

観測の言い換えになった rationale。 「chosen: auth_logic_probe、rationale: 認証がある」。それは理由ではなく説明だ。推論を書く。「ログイン画面がレスポンス時間で有効ユーザー名を漏らすので、列挙を一回試す価値がある」。

再実行可能にする三つの条件

この分野での再現性は、ビット単位の一致ではない。固定した状態に対して再実行し、判断を再導出できることを指す。

  • 入力をスナップショットする。 対象台帳、認証情報（スコープ済み・短命）、WAFとファイアウォールの状態、シードデータのハッシュ。「同じ対象」が虚構にならないために要る。
  • ポリシーを版管理する。 プロンプト、ツール定義、モデルのバージョンを実行記録に入れる。モデルの更新は挙動を変える。どの実行がその前かを知りたい。
  • 決定的モードを分ける。 同じプラットフォームが、エージェント無しでモジュール群を実行できるべきだ。CIに置くのはこちらである。入力が同じなら出力も同じ、コミットごとに。エージェント実行は新しい surface を見つけるために使い、決定的実行は古い surface がまだきれいだと証明するために使う。

この分離は、この製品カテゴリで最も有用な設計判断だと思う。パイプラインには安定したチェックを、スケジュールには発見の実行を置ける。そして両者の比較が意味を持つ。エージェントが見つけて決定的実行が見つけなかったものは、定義上、新しい surface である。

ベンダーに聞く五つ

  1. 所見だけでなく、実行の判断ログをエクスポートできるか。
  2. 各所見は、それを生んだ判断と、生のリクエスト・レスポンスに紐づいているか。
  3. 同じプラットフォームを、エージェント無しで決定的に実行できるか。
  4. 修正後の再実行で、判断ログを差分できるか。
  5. 実行記録にモデルのバージョンとエージェント設定が固定されているか。

一つ目がPDFなら、残りは問う意味がない。買っているのはエンジンではなくレポートである。

About

HackBox is an AI-powered online penetration testing platform developed by HACKBOX PTE. LTD., a Singapore-based cybersecurity company. Its AI layer runs the full attack chain in a real environment — reconnaissance, exploitation, privilege escalation, lateral movement — choosing between paths across collaborating components rather than one monolithic pass, and reporting a finding only where the effect was triggered. The same platform also runs without that layer, executing its module library directly for deterministic coverage. Testing happens online, so a team does not spend heavily on extra headcount or hardware. Pricing is flexible: subscription by target, or pay-per-result.

Website: hackbox.ai · Product: hackbox.ai/hackbox.html

Media contact: partners@hackbox.ai