AIに脆弱性を探させる前に、探索工程を設計するのだ
はじめに
GMOサイバーセキュリティ byイエラエの資料「生成AIを活用した脆弱性調査」を読んだのだ。1
対象は、GMO IERAE HackNight #4「AI時代のセキュリティ攻防戦」で公開されたスライドなのだ。
- 資料: 生成AIを活用した脆弱性調査
- 公開元: GMOサイバーセキュリティ byイエラエ
- 発表者: 川根 健太郎 氏
- URL: https://www.docswell.com/s/ierae/KQ29DV-hacknight04-os#p1
この資料、ぱっと見だと「AIを使ったすごい脆弱性調査の話」に見えるのだ。
でも、ぼくが大事だと思ったのはそこだけじゃないのだ。
もっと大事なのは、AIに何を読ませるか、どんな道具を渡すか、どんな順番で検証させるかを、人間がちゃんと設計しているところなのだ。
資料では、Claude Code、MCP、IDA、Binary Ninja、Ghidraなどを組み合わせて、バイナリ解析や脆弱性調査を支援させる話が出てくるのだ。
ただし、これは単なるツール紹介ではないのだ。
ぼくなりに言い換えると、要点はこうなのだ。
AIに「脆弱性を探して」と丸投げする時代ではなく、AIが探索できるように、人間が探索空間、観点、道具、検証工程を設計する時代なのだ。
これはバイナリ解析だけの話ではないのだ。設計レビュー、ソースコードレビュー、ログ分析、ASM、脆弱性管理、AIレビュー基盤にもそのまま応用できる考え方なのだ。
この資料は何が面白いのだ
このスライドが扱っている領域は、かなり高度なのだ。
- バイナリ解析
- 逆アセンブル
- デコンパイル
- Claude Code
- MCP
- IDA Pro
- Binary Ninja
- Ghidra
- PoC作成
- 脆弱性候補の検証
- セキュリティ境界の判断
だから、一般的なWeb診断や2線のセキュリティレビュー部門が、明日からそのまま真似するのは難しいのだ。
でも、考え方はすごく使えるのだ。
AI時代のレビューや診断を考えるとき、特に大事なのは次の点なのだ。
- AIは丸投げすると浅く見るのだ
- 対象を絞ると深く読めるのだ
- 一般論ではなく観点を渡す必要があるのだ
- 検索ツールを渡すだけでは探索にならないのだ
- 発見と検証は分けたほうがいいのだ
- AIの出力は正解ではなく仮説なのだ
- 最終判断は人間がやるのだ
この資料は、AIを「答えを出す箱」として扱っていないのだ。
AIを「探索を手伝う相棒」として扱っているのだ。そこが実務っぽくて、ぼくは好きなのだ。
「脆弱性を探して」だけだと弱いのだ
AIをセキュリティレビューに使うとき、最初にやりがちな指示はこうなのだ。
このコードに脆弱性がないか探して。
設計レビューなら、こうなるのだ。
この設計にセキュリティ上の問題がないか確認して。
これでもAIは何か答えてくれるのだ。
でも、だいたいは一般論になりやすいのだ。
- SQLインジェクションに注意しましょう
- XSSに注意しましょう
- 認証・認可を確認しましょう
- 入力値検証を行いましょう
- ログを取得しましょう
もちろん、これらは間違いではないのだ。
でも、実務でほしいのは「気をつけましょう」ではないのだ。
ほしいのは、対象システムの具体的な処理、データフロー、権限境界、例外処理、状態遷移を読んだうえで、どこが危ないのかを見つけることなのだ。
イエラエの資料で大事なのは、プロンプトの粒度を変えると、AIの探索行動も変わるという点なのだ。
粗い依頼をすると、AIは広く浅く見るのだ。
でも、対象や観点を絞ると、具体的な箇所を深く読み始めるのだ。
例えば、悪い指示はこうなのだ。
この管理システムの設計にセキュリティ問題がないか見て。
少し良くすると、こうなのだ。
顧客情報変更機能について、認可、再認証、監査ログ、承認、検索条件の観点で確認して。
さらに良くすると、こうなのだ。
画面ID ADM-010 の顧客検索結果一覧から、顧客詳細変更 ADM-020 に遷移するフローについて、権限昇格、過剰閲覧、一括抽出、操作否認の観点で確認して。
ここまで絞ると、AIに期待している作業がだいぶはっきりするのだ。
AIの品質を上げるコツは、AIにお願いする前に、人間がレビュー対象をちゃんと切り出すことなのだ。
AIには知識より観点を渡すのだ
脆弱性レビューで、AIに長々と教科書を渡したくなることがあるのだ。
例えば、Use-After-Freeとは何か、Double Fetchとは何か、SQLインジェクションとは何かを説明したくなるのだ。
でも、多くの場合、AIはその一般知識をもう持っているのだ。
だから本当に渡したいのは、用語説明ではなく「どこをどう見るか」なのだ。
バイナリ解析なら、例えばこういう観点なのだ。
- 所有権が移動する前後で参照が残っていないか
- ロック取得前後で状態が変化していないか
- 例外パスで参照カウントが崩れていないか
- ユーザー入力が検証後に再取得されていないか
- 成功時と失敗時で解放処理に差がないか
- 境界チェック後にサイズやポインタが変化していないか
設計レビューでも同じなのだ。
「認可を確認して」だけでは、ちょっと弱いのだ。
実務では、こういう観点に分解したほうがいいのだ。
- 一覧表示で過剰な顧客情報を返していないか
- 検索条件なしで大量データを取得できないか
- 詳細画面への遷移時にサーバ側で再認可しているか
- 画面で非表示にしているだけでAPIでは更新できないか
- 代理操作、委託先操作、管理者操作の区別がログに残るか
- 更新前後の値が監査可能か
- 頻繁な業務操作に対して再認証を求めるべきか
- 承認、検知、事後レビューのどれでリスクを下げる設計か
AIに渡すべきなのは、「セキュリティとは何か」ではないのだ。
対象を見るための観点なのだ。
検索させるだけでは足りないのだ
資料を読んでいて、ぼくがかなり大事だと思ったのはここなのだ。
AIに検索ツールを渡すと、AIが検索だけで満足してしまうことがあるのだ。
例えば、バッファオーバーフローを探すときに、AIが strcpy や memcpy だけを検索して終わったら、ちょっと困るのだ。
検索は便利なのだ。
でも、検索だけでは見落とすものがあるのだ。
- 関数ポインタ経由の呼び出し
- ラッパー関数の中に隠れた不備
- サイズ計算の整数オーバーフロー
- 複数関数をまたぐ状態不整合
- 例外処理だけで起きる解放漏れ
- 条件分岐の片側だけで起きる検証漏れ
これはドキュメントレビューでも同じなのだ。
AIに大量の設計書を渡して、「認証」や「ログ」というキーワードを探させても、本当の設計不備は見つからないかもしれないのだ。
大事なのは、キーワードがあるかどうかではないのだ。
その統制が、対象の業務フローやリスクに効いているかどうかなのだ。
だからAIにやらせたいのは、単なる検索ではなく構造の読解なのだ。
- データフローの抽出
- 権限境界の抽出
- 画面/API/DBの対応関係の整理
- 要件と設計のトレース
- 例外処理の洗い出し
- 更新系処理の到達条件の確認
- ログ設計と監査要件の対応確認
- リスクシナリオごとの統制マッピング
AIに検索させるだけではなく、構造を読ませるのだ。
発見と検証は分けるのだ
AIレビューでかなり効くのが、発見と検証を分けることなのだ。
AIは、自分が出した仮説を後から正当化する方向に進みやすいのだ。
同じセッションで、脆弱性候補を出させて、そのまま「本当に脆弱性ですか」と聞くと、最初の仮説に引っ張られることがあるのだ。
だから、ぼくなら役割を分けるのだ。
Session A: 発見
ここでは、脆弱性候補や設計上の懸念を広く出させるのだ。
出してほしいものは、例えばこれなのだ。
- 指摘候補
- 根拠箇所
- 想定される悪用条件
- 影響
- 関連する処理
- 追加確認事項
この段階では、全部を正解扱いしないのだ。
あくまで候補を集める工程なのだ。
Session B: 検証
次に、Session Aの指摘が本当に成立するかを確認するのだ。
ここではAIに反証を優先させるのだ。
- 指摘が成立しない条件は何か
- すでに別の統制で防がれていないか
- 前提としている権限や状態は正しいか
- 実際に到達可能な処理か
- 仕様として許容された動作ではないか
- 影響を大きく見積もりすぎていないか
発見役と検証役を分けると、AIの自己正当化を少し抑えられるのだ。
Session C: 人間判断
最後は人間が決めるのだ。
- 指摘として採用するか
- 要確認事項として残すか
- リスク受容候補にするか
- 修正依頼にするか
- 証跡だけ残してクローズするか
AIを一人の万能レビュアーとして扱うのではなく、複数の役割に分けて使うのだ。
このほうが、レビュー品質は安定しやすいのだ。
「脆弱性」と「境界越え」は分けて考えるのだ
スライドで扱われている考え方の中で、もう一つ大事なのが、脆弱性の存在とセキュリティ境界の評価を分けることなのだ。
これは本当に大事なのだ。
ある不具合があっても、それがすぐ重大な脆弱性になるとは限らないのだ。
逆に、小さく見える不備でも、セキュリティ境界を越えられるなら重大なのだ。
例えば、管理システムで考えると分かりやすいのだ。
単にエラーメッセージが不親切なだけなら、普通は重大な脆弱性ではないのだ。
でも、そのエラーメッセージによって、存在する顧客IDと存在しない顧客IDを区別できるなら、情報漏えいの入口になる可能性があるのだ。
画面上では編集ボタンを非表示にしているだけで、APIを直接呼べば他部署の顧客情報を変更できるなら、それは明確に権限境界を越える問題なのだ。
AIレビューでも、この区別を明示する必要があるのだ。
AIに「これは脆弱性か」と聞くだけでは足りないのだ。
次のように分けて聞くのだ。
- 不具合なのか
- セキュリティ上の弱点なのか
- 悪用可能なのか
- 権限境界を越えるのか
- データ境界を越えるのか
- 業務上許可されていない操作が可能なのか
- 監査、検知、承認で十分に補完されているのか
この区別をしないと、AIの出力は「何でも脆弱性」になりやすいのだ。
境界の観点を渡すと、実務で扱える指摘に近づくのだ。
MCP連携は強いけど、権限設計も必要なのだ
資料では、IDA、Binary Ninja、GhidraなどとMCPを連携させる構成が扱われているのだ。
これはかなり強力なのだ。
AIが単にテキストを読むだけではなく、解析ツールを操作しながら、関数一覧、デコンパイル結果、呼び出し関係などを確認できるようになるのだ。
でも、強い道具をAIに渡すということは、リスクも増えるということなのだ。
業務で使うなら、少なくとも次の点は考えたいのだ。
- 解析対象のバイナリやコードが外部LLMに送信されないか
- MCPサーバがlocalhost以外に露出していないか
- AIが意図しないファイルを読めないか
- PoCや検証コードを危険な環境で実行しないか
- APIキーや認証情報がプロンプトやログに混入しないか
- 解析環境と業務環境が分離されているか
- ログや成果物に機密情報が残らないか
- 検証VMをスナップショットで戻せるか
AI活用の議論では、どうしても「何ができるか」に注目しがちなのだ。
でも実務導入では、「何をさせないか」の設計も同じくらい大事なのだ。
AIに道具を渡すなら、権限境界も一緒に設計するのだ。
2線レビューにも使える考え方なのだ
この資料は、オフェンシブセキュリティの高度な脆弱性調査を扱っているのだ。
でも、2線のセキュリティ部門にもかなり効く話なのだ。
特に、設計レビューや要件定義レビューにAIを使う場合は、次のように考えるとよいのだ。
だめなAIレビュー運用
- 設計書をまとめて投入する
- 「問題点を探して」と聞く
- 出てきた指摘をそのままレビュー結果にする
- 根拠箇所を確認しない
- 反証しない
- 人間の採否判断を省略する
これは危ないのだ。
AIはそれらしいことを言うのだ。
でも、それが対象資料に基づいているとは限らないのだ。
よいAIレビュー運用
- 対象を画面、API、業務フロー単位に分割する
- レビュー観点を明示する
- 発見、検証、反証、人間判断を分ける
- 根拠箇所を必ず出させる
- 指摘ごとに前提条件を出させる
- 業務上の許容可否を別に判断する
- 最終判断を人間が行う
AIをレビュー担当者の代わりにするのではなく、レビュー工程の一部として置くのだ。
そこを間違えないことが大事なのだ。
出力フォーマット例
AIレビューの出力は、次のように分けると扱いやすいのだ。
| 項目 | 見ること |
|---|---|
| 指摘候補 | AIが懸念した内容 |
| 対象機能 | どの画面、API、処理の話か |
| 根拠箇所 | 資料やコードのどこに基づくか |
| 想定される悪用条件 | どういう前提で成立するか |
| セキュリティ境界 | 権限、データ、業務操作のどの境界か |
| 業務影響 | 事業や利用者にどんな影響があるか |
| 既存統制 | すでに防いでいる仕組みがあるか |
| 反証観点 | 成立しない可能性は何か |
| 人間確認事項 | 人間が見るべき残課題 |
| 推奨対応 | 修正、追加確認、受容など |
| 残留リスク | 対応後に残るリスク |
この形なら、AIの出力をそのまま信じるのではなく、レビュー証跡として扱いやすいのだ。
AIレビュー基盤はチャットではなく工程なのだ
いま、多くの組織で、生成AIをセキュリティレビューに使えないかという検討が進んでいるのだ。
要件定義書、設計書、テスト仕様書、ソースコード、ログ、チケット、脆弱性診断結果などをAIに読ませ、レビューを効率化しようとする流れなのだ。
方向性としては自然なのだ。
でも、資料をまとめて読ませるだけでは品質は安定しないのだ。
イエラエの資料から学べるのは、AIレビューを「チャット」ではなく「工程」として設計する必要があるということなのだ。
例えば、次のような流れなのだ。
| 工程 | やること |
|---|---|
| 対象分割 | 画面、API、業務フロー、データ項目、権限ロールに分ける |
| 観点付与 | 認証、認可、入力検証、監査ログ、個人情報、一括操作、外部連携、例外処理などを渡す |
| 発見 | 懸念候補、根拠箇所、前提条件を出させる |
| 検証 | 指摘が成立するか、反証や既存統制を確認する |
| 採否判断 | 人間が指摘、保留、却下、リスク受容に分類する |
| 証跡化 | AI出力、人間判断、修正依頼、クローズ理由、残留リスクを残す |
AIレビューは一発回答ではないのだ。
レビュー工程の一部として扱うべきなのだ。
過大評価しすぎないのも大事なのだ
このスライドを読んだからといって、すぐにAIが高度な脆弱性を自動で見つけてくれるわけではないのだ。
むしろ、資料から見えるのは、AI活用には相応の専門性が必要だという現実なのだ。
必要なのは、少なくとも次のような力なのだ。
- 対象領域の専門知識
- ツールの理解
- AIの癖の理解
- プロンプト設計
- 検証環境
- 誤検知を潰す能力
- PoCや再現条件を確認する能力
- セキュリティ境界を判断する能力
AIによって、専門家が不要になるわけではないのだ。
むしろ、専門家の仕事が変わるのだ。
従来は、自分で全部読むことが中心だったのだ。
これからは、AIにどこを読ませるか、どの観点で読ませるか、出てきた結果をどう検証するかが重要になるのだ。
つまり、専門家は「作業者」から「探索設計者」に寄っていくのだ。
この変化を見せてくれるところに、この資料の価値があるのだ。
まとめなのだ
イエラエの「生成AIを活用した脆弱性調査」は、AIセキュリティ活用の実務的な勘所を示した資料なのだ。
特に重要なのは、AIに脆弱性調査を丸投げしない姿勢なのだ。
AIは、正しい対象、正しい観点、正しい道具、正しい検証工程を与えたときに、強力な補助者になるのだ。
一方で、曖昧な依頼、過剰なツール権限、検証なしの採用、同一セッションでの自己正当化は危ないのだ。
この資料から得られる教訓は、こう整理できるのだ。
- AIは答えを出す装置ではなく、探索を補助する装置なのだ
- AIレビューはチャットではなく、工程として設計する必要があるのだ
- 一般論ではなく、対象と観点を渡す必要があるのだ
- 発見と検証を分ける必要があるのだ
- 脆弱性の存在とセキュリティ境界越えを分けて判断する必要があるのだ
- MCPや外部ツール連携には権限制御と環境分離が必要なのだ
- 最終判断は人間が行う必要があるのだ
この考え方は、バイナリ解析だけではなく、設計レビュー、コードレビュー、ログ分析、ASM、脆弱性管理、AIレビュー基盤にも使えるのだ。
AI時代のセキュリティレビューで重要なのは、AIに任せることではないのだ。
AIが有効に働くように、人間がレビュー工程を設計することなのだ。
そこを押さえると、AIは危なっかしい自動判定機ではなく、ちゃんと使える探索の相棒になるのだ。