新機能AWS Security Agentを検証してみた
はじめにAWS Security Agentの概要と特徴1. Design Review（設計レビュー）2. Code Security Review（コードセキュリティレビュー）3. Penetration Testing（ペネトレーションテスト）検証：自作アプリVulnBankを使った診断AWS Security AgentのセットアップCode reviewの設定Penetration Testの設定今回のまとめ
はじめに
メディア統括本部 サービスリライアビリティグループ（SRG）の谷成です。
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
本記事は、re:Invent 2025で発表された「AWS Security Agent」を実際に検証し、AIによる設計レビューの有効性と動的テストの課題を明らかにすることで、新サービスの導入や活用を検討する際の判断材料を提供するための記事となっております。
2025年12月に開催されたre:Invent 2025において、AWSは生成AIを活用した新たなセキュリティサービス「AWS Security Agent」が発表されました。
これまでのセキュリティツールは、既知のパターンマッチングやルールベースの検出が主流でしたが、この新サービスは「AIがアプリケーションのコンテキスト（文脈）を理解する」という点で一線を画していると感じます。
開発ライフサイクル全体を通じて、設計から実装、そして運用中のテストまでを一気通貫でサポートするというのが魅力なのですが、実際の使い勝手や精度はどうなのでしょうか。
本記事では、プレビュー版として公開されたAWS Security Agentを、自作した教育用の脆弱性アプリ「VulnBank」を用いて実際に検証した結果をレポートします。
本記事は2部作に分けることを考えており、初回はAWS Security Agentの概要、AWS Security Agentのセットアップなどについて紹介し、次回は各機能がどのように動作するかを紹介してまとめる形にします。
AWS Security Agentは2025/12現在 プレビュー版で US East (N. Virginia)でのみ使用可能となっております
AWS Security Agentの概要と特徴
AWS Security Agentは、アプリケーションの設計図、ソースコード、そして稼働環境をAIが分析し、セキュリティリスクを検出・修正提案を行うサービスです。
最大の特徴は、単なるコードの不備を見つけるだけでなく、アーキテクチャ図や要件定義書といったドキュメントまで読み込み、システム全体の意図を理解した上でリスクを評価する点にあります。
従来のSAST（静的解析）やDAST（動的解析）ツールでは、誤検知（False Positive）の多さや、ビジネスロジックに起因する脆弱性の見逃しが課題でした。
AWS Security Agentは、生成AIが「このアプリはどのようなデータを扱い、どのようなフローで処理しているか」を解釈することで、より人間に近い、あるいはそれ以上の視点でセキュリティレビューを目指しています。
このサービスは主に以下の3つの機能で構成されています。
1. Design Review（設計レビュー）
実装前の設計段階で、アーキテクチャ図や仕様書（MarkdownやPDF）をアップロードし、設計上のセキュリティリスクを洗い出します。
AWS Well-ArchitectedフレームワークやOWASP Top 10などの基準に基づき、認証・認可の不備やデータの取り扱いについて指摘します。
2. Code Security Review（コードセキュリティレビュー）
GitHubなどのリポジトリと連携し、Pull Requestが作成されたタイミングでコードを分析します。
変更差分だけでなく、リポジトリ全体や関連する設計ドキュメントの情報を加味して、SQLインジェクションやハードコードされたシークレットなどを検出します。
また、単に指摘するだけでなく、修正コードそのものを提案してくれる点も大きな特徴です。
3. Penetration Testing（ペネトレーションテスト）
実際に稼働しているWebアプリケーションに対して、AIエージェントが擬似的な攻撃を行い、脆弱性を検証します。
VPC内のプライベートなリソースに対してもテストが可能で、発見された脆弱性に対しては再現手順や修正案が提示されます。
検証：自作アプリVulnBankを使った診断
今回は、意図的に脆弱性を含ませたWebアプリケーション「VulnBank」をGoを用いて自作しました。アプリケーションには以下の脆弱性を意図的に含んでおります。
- SQLインジェクション（複数箇所）- 文字列連結によるクエリ構築
- IDOR（Insecure Direct Object Reference） - 認可チェックの欠如
- Broken Access Control - 管理者機能への不正アクセス
- ハードコードされたシークレット - JWT秘密鍵、管理者パスワード等
- 弱いパスワードポリシー - パスワード検証の欠如
- デバッグエンドポイントの露出 - エンドポイント
- Mass Assignment - リクエストから任意のフィールドを設定
AWS Security Agentのセットアップ
AWS Security Agentを使用するためにセットアップを行っていきます
まず最初にエージェントスペースを作成します。作成に必要なものは名前と説明のみとなっております。
作成が完了すると以下のような状態となります。
と がまだセットアップされておらず設定が必要となっているのがわかるかと思います。
Code reviewの設定
それぞれ設定を行っていきます
を選択すると以下のような画面が出てくるので、新規作成していきます。
を押すとGitHubとの連携画面が表示されます
必要な設定を行って を押します。
に戻って を選択すると以下のような画面となります。
上記画面の設定では最初 と がfalseとなっているので、必要なものは隣りにある鉛筆マークを押してEnabledに変更する必要があります。
これらの設定が完了すると の設定は完了となります。PRなどを出してみると脆弱なコードなどが入るとreviewして修正の提案までしてくれます。こちらの詳細の様子は次回のブログにて紹介します。
Penetration Testの設定
続いて を押して設定を進めていきます。
今回はEC2にアプリケーションをデプロイしてEC2のアプリケーションに対してテストをかけたかったので、HTTPルートで検証してみました。
後述するのですが、この方法に関しては最終的にはステータスが失敗になりうまくいきませんでした。
そのまま設定してみると となってしまいます。
を叩いたときに が返る必要があるので、アプリケーションに対象のパスからの返答を実装します。
するとステータスが に変わります。
この失敗の状態で
- ポートを8080 → 80
- ポートを80 → 443 (自己証明書)
- ドメインを付与してドメイン経由でアクセスしてみる
- 証明書をACMで作成し、ALB経由のアクセスに変更する
などをして、EC2内部や手元（外部）からのリクエストで問題なくヘルスチェックや検証トークンが返ってきているにも関わらず から状態が変わることはありませんでした。
一旦 を断念して を変更して に変更していきます。
設定変更後DNSに検証用のレコードを登録することでステータスが となりました。
上記設定が完了したことで全機能が利用できるようになったことが確認できます
今回のまとめ
今回のブログではAWS Security Agentについての紹介とセットアップについて紹介させていただきました。
設定でいくつか詰まる所があり、特にペネトレーションテストの や に関しては、エラーログが画面にも表示されておらず、Amazon CloudWatchの方にも見当たらなかったので、何を修正すれば良いかわからない状況となってしまいました。プレビュー版ということで今後様々な情報が出てきたり、改善されてりすることを望んでいます。
次回はコードレビューやペネトレーションテストを実際に実施した部分をまとめてブログに記載しようと思います。
SRG では一緒に働く仲間を募集しています。
ご興味ありましたらぜひこちらからご連絡ください。