脆弱性診断・脅威モデリングを行うセキュリティエージェントを実装しました

こんにちは！システムセキュリティ推進グループの小笠原 (@gassara5) です。

最近では連日のサプライチェーン攻撃の増加やClaude Mythosを始めとしたAIのサイバー攻撃能力を考えると、守り側もAIを使わずにはいられない時代になりました。

今回は、私たちが実装したセキュリティエージェント「BUGMAP」の事例をご紹介したいと思います。BUGMAPはセキュリティチームだけでなく、社内のエンジニアが使えるツールとして提供しています。

＊ BUGMAP：「BUG（脆弱性）がどこにあるか明らかにし、解決のための道のり=MAP（地図）を提供する」、という意味合いで名付けました

なぜBUGMAPを作ったのか

私たちセキュリティチームはプロダクトセキュリティの課題解決がミッションとなります。その中でも、リリース前などに実施する脆弱性診断や、設計レビュー、脅威検知・モニタリングをメインに行ってきました。

今までのスピード感では対応できない

しかし、従来の脆弱性診断は完了までのリードタイムが数カ月かかることもあります。また、設計レビューや脅威モデリングについても規模によっては数日かかりきりでした。
一方で、プロダクトのリリーススピードにセキュリティレビューが追いつかないという課題もあります。

普段から対象プロダクトを開発しているわけではないため、レビューに時間がかかるのは仕方ないのですが、現場エンジニア目線でも診断準備に相当な負担があるというのが課題でした。

AIの登場によって攻撃者側の能力やスピードも数段上がっているため、私たち守る側もスピード向上は急務の課題です。

品質とスピードの両方を向上する

スピードだけではなく、品質も落とすわけにはいきません。むしろ攻撃能力も日に日に上がっているため、今まで以上に脆弱性の解析能力が求められます。

そこで私たちは、「次世代セキュリティレビュープロジェクト」を2025年11月から始動し、BUGMAPというサービスを開発しました。今回はこのBUGMAPの取り組みで実践した内容と結果を共有したいと思います。

このプロジェクトでは、セキュリティチームだけで完結させるのではなく、診断チーム（診断士）、実際にプロダクトを開発するエンジニアと一緒に進めてきました。診断担当者が持っている暗黙知を分解し、AIエージェントが実行できるタスクやレビュー観点に落とし込みながら、現場のエンジニアでもセルフサービスとして使える形にすることを目指しました。

BUGMAPで何ができるのか

BUGMAPが提供しているメインの２つの機能をご紹介します。

1. WEBシステムの脆弱性診断

まず最初にセキュリティ診断チームと一緒に脆弱性診断エージェントの実装に取り掛かりました。BUGMAPの診断は従来のブラックボックス診断だけでなく、ソースコードベースのホワイトボックス診断の双方を行うことがポイントです。

また、診断の依頼者はこの準備のために特別な作業は必要なく、BUGMAPが、URLのエンドポイント一覧やデータのインプット・アウトプット解析図などを自動生成します。

最初に、GitHub Appをインストールし診断対象のリポジトリを選択（複数可能）、あとは診断観点やブラックボックス診断等のオプション設定を入力し、診断を開始できます。

およそ、1h〜2h程度で診断が完了し、サマリーレポートと指摘Issueを見ることができます。GitHubと連携しているため、そのままBUGMAP側がPR作成やGitHub Issue連携も行えるようにしています。これはいち早く脆弱性を修復するためのフローに繋げるようにしたかったためです。

また、IssueコメントでAIに質問や深堀り調査を依頼することもできるようにしました。セキュリティチームと現場エンジニアとも共通のインターフェースでコミュニケーションを行います。

2. 設計レビュー／脅威モデリング

続いて、設計レビュー／脅威モデリングです。
設計レビューの相談は、私たちのチームに来る相談の中でも特に多い依頼になります。例えば、新しい機能を設計・実装したり、システム全体のセキュリティを見直すケースで行われます。しかしこれらの設計レビューは非常に専門性の高いタスクになるためAI化の効果が出やすい領域だと考えています。

私たちのチームでは主に２つのレビュー手法を採用しています。

ベースラインレビュー
リスクベースレビュー

１の「ベースラインレビュー」ではOWASPのASVSや各種ベンダーのベストプラクティスを元にどれだけ準拠できてるかをチェックするものです。また、社内で過去に行ったレビュー履歴から実装ベースのナレッジも参照して評価し具体的な指摘に落とし込みます。

２の「リスクベースレビュー」では脅威モデリングを行うケースが多いです。データフロー図（DFD）を作成しシステム全体を可視化し、重要な資産がどこにあるのか、信頼境界はどこかを特定し、脅威分析→リスク評価を行います。また、社内で広く導入されている RISKEN や Wiz といったセキュリティサービスと連携して、実際に観測されているFinding／Issue（エビデンス）を含めた脅威分析を行えるようにています。

現場で放置されがちなCRITICALやHIGH以外の問題も含めてトータルで評価し対応の有無や優先度の意思決定を支援します。

導入して何が変わったのか

2026年の2月頃から徐々に、実際の診断業務やレビュー依頼にBUGMAPを導入していきました。また、セルフ診断ツールとしても4月に社内で公開しました。
導入してみるといくつかの発見がありました。

診断能力が高く、誤検知が少なかった

ソースコードベースの診断を行うので、ある程度は予想はしていたものの、それをはるかに上回る性能が確認できました。実際の診断業務では、従来のレビュー手法と並行してBUGMAPによる診断を行い、人手のレビュー結果と比較しながら品質を確認してきました。特に良かった点は非常に「誤検知」が少ない点です。

従来のセキュリティスキャンツールでは誤検知に悩まされるケースが多かったのですが、実際にエクスプロイト可能かを丁寧にAIが検証してくれます。その場でPoCコードを生成して検証したり、実際にAPIリクエストを送って攻撃が成立するかを確認します。

継続的に繰り返し実行が可能になった

現場のエンジニアに好評だった機能の一つが、「スケジュール診断」機能です。日々変化するシステムに対して定期的に診断を行い、新しい脆弱性を発見したら通知します。

今までの診断では半年〜1年に1回行うのが限界でしたが、1回の診断が1h〜2hで終わるのと人が介在しないため、自動化できるようになりました。

また、脅威モデリングも同様です。今まで1回のレビューに非常に工数がかかっていたのですが、継続的に生きたコードベースで診断ができるようになったのは非常に大きい変化です。

現場のエンジニアが使いやすい体験になった

BUGMAPを導入して特に嬉しかったのは、実際に利用した現場のエンジニアから非常にポジティブな声をもらえたことです。単に診断性能を高めるだけでなく、GitHub連携、PR自動作成、Issue連携、AIエージェントとのチャットや追加調査など、現場担当者が脆弱性を理解し、修正まで進めるために必要な機能をフィードバックをもらいながら揃えていきました。

これまでレビュー依頼のために必要だった情報整理や資料作成も、BUGMAPがソースコードや設計書から自動生成することで、依頼者側の準備負担をかなり減らせるようになりました。セキュリティチームだけが使うツールではなく、プロダクト開発の現場で自然に使える仕組みにできたことは大きな成果だと感じています。

BUGMAPを支えるアーキテクチャ

先日、CloudflareのMythos Preview利用レポートの記事を見ました。
https://blog.cloudflare.com/cyber-frontier-models/

ここで紹介されている「４つの教訓」や「Vulnerability Discovery Harness」の仕組みは非常に参考になるポイントが多く含まれていました。

単にAIに「脆弱性を見つけて。」と指示するだけでは不十分で、本来AIが持つサイバーセキュリティ能力をうまく発揮できません。実はこれは私たちのチームでも以前から強く実感しており、非常に似たアプローチを取っていました。

全体ワークフローの構築

まず、セキュリティレビューのフローをいくつかの専用タスクに分割する仕組みを構築しています。各タスクで生成したアウトプットを次のタスクにコンテキストとしてうまく渡すよう設計しています。

ワークフローの実行制御としてAWSのStepFunctionsを採用しました。また、タスク実行環境としてはECS Fargate上でサンドボックス化しAIエージェントのセキュリティを考慮しています。

AIの基盤モデルはAmazon BedrockやOpenAI、ローカルLLM、Devinなどタスクによって様々使い分けができる設計にしています。また、タスクごとに推論能力がどれだけ必要かによってもモデル選択やReasoningEffortを調整できるようにしています。

これらのAWSサービスを軸にした技術選定は、AIエージェントのハーネス構築としては、今でも非常に良い選択だったと思っています。パフォーマンス、安定性、セキュリティのバランスが非常に良くメンテナンス性が高いです。

144個の専用レビューエージェント

各タスクでは複数の専用レビューエージェントを起動させ親プロンプトでそれらのエージェントをオーケストレーションさせる仕組みにしています。気付いたら144個のエージェントに膨れ上がっていましたが、今後もっと増えることが予想されます。多ければ良い、というわけではありませんが、各エージェントの範囲を絞り、タスクを並列化することでより良い結果が得られてることはCloudFlareの「4つの教訓」でも言及されています。

タスクごとに与えられた役割に応じたレビュー計画をたて、複数のSubagentを並列で起動（Spawn）させます。最後に結果をまとめるフローです。

ガイドラインやベストプラクティスの観点ごとに専用のSubagentを分ける設計にしています。こうすることでAIエージェントがサボることもなくなりますし、並列実行してくれるため全体的に早くなります。

複数のタスクｘSubagentのアウトプットは最後にレビュー・検証し、結果をまとめる専用のフローも用意しています。

AIエージェントを安全に使うための工夫

BUGMAPではPoCコードの生成や実際のAPIリクエストによる検証も行いますが、これらの検証を安全に行うための仕組みも重要です。

例えば、AIエージェントの実行環境はECS Fargate上でサンドボックス化し、タスクごとに実行範囲を制御しています。また、外部サイトへの意図しないリクエストが発生しないように専用プロキシなどの安全対策を組み込んでいます。

AllowList（URLやドメインの許可）で基本的に自社サイトのみに制限し、DenyList（決済機能や、メール送信、3rd-Party通信のエンドポイント等を除外）の組み合わせも設定できるようにしています。技術的にはEgressプロキシ側で動的にルール制御することでこの仕組みを実現しています。
外部通信は、AWSのSecurity Groupによって必ずプロキシを経由するようにネットワークレベルで制御しています。

AIエージェントの能力を高めるほど、同時に実行環境や権限、通信経路の制御も重要になります。BUGMAPでは、単に強いモデルを使うだけでなく、安全に検証できる環境をセットで作ることを重視しました。

チームとして得た学び

BUGMAPを作る中で一番大きかった学びは、AI エージェントの性能だけでなく、セキュリティ担当者の知見をどのように分解し再利用できる形にするか、が重要だということです。

診断担当者が普段の業務において、

どの順番で情報を見ているのか
どの観点で危険度を判断しているのか
どの状態なら修正に進めるのか

これらを言語化していくことで、AI エージェントに任せられる部分と人が判断すべき部分が整理されていきました。

また、現場のエンジニアからのフィードバックを受けながら機能を揃えたことで、セキュリティチームのためだけのツールではなく、プロダクト開発の流れの中で使える仕組みに近づけることができました。セキュリティレビューを一部の専門家だけの作業に閉じず、組織全体で扱える形にしていくことが、今後ますます重要になると感じています。