AI に脆弱性調査やリバースをさせるときは「指摘は手がかり、証拠は外に残す」
強いモデルでも、対象の情報・再現できるツール・許可範囲・記録・検証手段が欠けると質が落ちる。調査用の「ハーネス」でそれを補い、LLM の指摘は確定した発見ではなく仮説として、成立条件と証拠で確かめる。
いつ使うか
- 自社コードや許可を得た OSS を AI エージェントで脆弱性調査する
- IDA などで LLM に名前や型を付けさせながらマルウェアを解析する
ハーネスに入れるもの（[un]prompted II の演習教材より）
- 許可範囲: テストはローカル・隔離環境・明示的に許可された対象に限る。公開インフラへのテストや、未修正と思われる脆弱性の公表はしない。
- 再現できるツール: 同じ入力に同じ結果を返す決定論的なツールを用意する。例として、Go のファイルから
exec.Commandの直接呼び出しを一覧化し、条件・範囲・呼び出し式が変わらなければ再レビューを省いて行番号だけ更新する（間接呼び出しは対象外で、安全の保証ではない）。 - オラクル: モデルが持たない専門データを返す仕組み。例として、Helm チャートの RBAC 宣言を検索できる DB にまとめ、Web 検索を再現可能なクエリーに置き換えた。
- 記録と比較: 汎用エージェントへの依頼と回答を基準として保存し、専用ハーネスの結果と比べる。
- 報告: エージェントは下書きまで、送るかは人が決める。
LLM の注釈を検証可能にする（SentinelLABS の VerifiedIDA）
- LLM は不正確な名前を付けたり、分かったことを IDB に残さなかったり、予定の作業を忘れたり、関連コードの調査を途中でやめたりする。未使用と判明したフィールドに
unresolved_28と付け、未調査と見分けられなくした例もある。 - 対策は 4 つ: 注釈ごとの根拠の追跡、変更と保存の検証、作業状態をモデルのコンテキスト外に保存、調査範囲の強制と独立レビュー。
- VerifiedIDA は LLM の編集を隔離した候補 IDB に当て、別の IDA プロセスで開き直して保存を確かめてから採用する。独立レビューと注釈が食い違うと完了にしない。確かめているのは記録と保存の成否で、解釈の正しさではない。間違いを後から追えることが目的。