AWS Security Agent (Preview)について学んでみた

はじめに

この記事はJapan AWS Top Engineers Advent Calendar 2025 の 7 日目の記事です。

こんにちはnagisa_53です。

12/1～5にラスベガスで開催されていたre:Invent 2025に参加してきました。

AWS CEO Matto Garman氏のKeynoteの中で発表された新サービス、AWS Security Agentについて、現地でWorkshopを受けてきたため、概要や設定方法について本記事でご紹介していきます。

Workshopとしては "[SEC353][NEW LAUNCH] AWS Security Agent: Get started with AI-powered proactive AppSec" を受講しました。本記事ではWorkshop自体の内容というよりは、Workshopを通じて学んだ概要や設定方法を中心にお伝えしていきます。

AWS Security Agentとは？

Keynote内で、長時間自律的に稼働するスケーラブルなAI Agent "Frontier agents" として、

• Kiro Autonomous Agent
• AWS Security Agent
• AWS DevOps Agent

が発表されました。

AWS Security Agentはその1つで、開発ライフサイクル全体を通じて、アプリケーションのセキュリティをプロアクティブに確保するAgentです。

機能としては大きく以下3つに対応しています。

• Design security reviews
• Code Security reviews
• Penetration testing

現在はパブリックPreview中のため、無料で利用できます。
※最終的な料金は現時点では不明。

実際にやってみる

Security Agentのセットアップ

まずはAWS Management Console上からAWS Security Agentのページを開き、"AWSセキュリティエージェントをセットアップ"ボタンを押下し、セットアップを開始します。

セットアップの中で、最初のエージェントスペース名とユーザーアクセス設定を行います。

ユーザーアクセス設定ですが、AWS Security Agentではスキャンの実施や結果確認のためにウェブアプリが個別に準備されるため、ウェブアプリの認証方法をどうするかの設定になります。
選択肢としては

• IAM Identity Center
• IAMユーザー

の2つがあります。
一度選択すると修正不可のため、注意が必要です。

必要項目を入力したら"AWSセキュリティエージェントをセットアップ"ボタンを押下し、セットアップ完了です。

ここから、個別機能の設定に進みます。

Design security reviews

設定編

前工程の作業を終えると、左ペインの"エージェントスペース"選択時に、作成したエージェントスペース名が出てきます。

作成したエージェントスペース名を選択すると、各エージェントベースの画面に遷移するため、"設計レビュー"タブを押下します。
デフォルトだと、以下のように10個のAWSマネージドのセキュリティ要件が有効になっています。

上記のセキュリティ要件ですが、"セキュリティ要件を管理"ボタンを押下することで、無効化や、カスタムセキュリティ要件の追加を行えます。

カスタムセキュリティ要件を作るには以下を入力する必要があります。

• セキュリティ要件名
• 説明
• 適用性
  • このセキュリティ要件を評価する必要があるシナリオ、システムタイプ、または条件を記入
• コンプライアンス条件
  • このセキュリティ要件におけるコンプライアンス遵守とコンプライアンス違反の条件を記入
• 是正ガイダンス（オプション）
  • 内部文書や標準へのリンクなど、違反の修正方法に関するガイダンスを記入

AWSマネージドのセキュリティ要件をテンプレートにカスタムセキュリティ要件を作成することができるので、記入方法などはマネージドのものを参考にするのが良さそうです。
例えばAWSマネージドの"Audit Logging Best Practices"の場合、以下のように各設定が行われています。

スキャン編

設定が終わったらエージェントベースの画面に戻り、"ウェブアプリ"タブを選択します。

上記の通りエージェントウェブアプリのURLが提供されているので、押下すると、Sign inページに遷移します。開発者など、AWS Securituy Agentの設定権限は持たず、スキャンや結果の確認のみ行う人向けには上記の"ユーザー追加"を押下し、事前にユーザーとして追加しておく必要があります（IAM Identity Center or IAMユーザーのどちらかが必要（どちらかは最初の選択による））。

AWS Securituy Agentの設定権限を持つ管理者については上述の"管理者アクセス"ボタンを押下することで、以下のウェブアプリにログインできます。

左ペインの"Design reviews"を押下すると"Creat design rview"ボタンがあるので、選択します。

Design review nameに入力し、レビュー対象としたいファイルをアップロード → "Start design review"を押下することでレビューが開始します。
ファイルの種別としては
"DOC, DOCX, JPEG, MD, PDF, PNG, TXT"
が扱えるようです。
また、同時に5ファイルまでのアップロードが可能でした。

以下はWorkshop受講時のものですが、以下のようにスキャン結果が出力されます。

Code Security reviews

続いてCode Security reviewsです。

設定編

エージェントスペースの設定画面で、コードレビュータブを選択します。

すると、GitHubの登録を求める画面が出てきますので、"GitHubアカウントを登録"ボタンを押下します。

現時点では"GitHubアカウントを登録"ボタンしか現れないため、GitリポジトリとしてはGitHubのみ利用可能なようです（Documentからもその模様）。
復活したCodeCommitやGitLabなども今後追加されることを期待します。

遷移した画面で、"インストールと認証"ボタンを押下するとGitHubアカウントのログインを求められ、許可するとAWS Security AgentのInstall許可画面に遷移します。

"Install & Authorize"を押下するとインストールが完了します。

ここまで進むと、Agentへ接続できる状態になるため、"接続"を押下することで、接続設定に進みます。

接続設定画面でリポジトリを選択し、"コードレビューが有効"が"無効"になっているのを"有効"に、また、Code Review Settingsでレビューの種類を選択します。

レビューの種類としては、以下が選択可能です。

• Security requirement validation（デフォルト）
  • コード変更が有効にしたカスタムセキュリティ要件に準拠しているかどうかを検証します
• Secuiry vulnerablity findings
  • コード変更における一般的なセキュリティ脆弱性を特定します
• 上記両方

上記入力後に"接続"を押下することで、設定が完了します。

スキャン編

設定完了後に、対象としたGitHubリポジトリ上で、Pull Requestを行います。
すると、Pull Requestにフックし、AWS Security Agentがスキャンを開始します。

スキャンが終了すると、レビュー結果をPull Request上のコメントとしてお知らせしてくれます。

なお、Code Security reviewsについてはウェブアプリ上での結果確認の機能などはなく、GitHub上で確認する使い方となるようです。

Penetration testing

最後にPenetration testingです。

設定編

エージェントスペースの設定画面で、ペネトレーションテストタブを選択し、"ペネトレーションテストをセットアップ"ボタンを押下します。

すると以下のような画面が出てくるので、ターゲットとなるドメイン等の情報を入力します。

ドメインについては検査対象のアカウントでRoute53のドメイン登録があるとそこから選択可能で、他のDNSで管理している場合は、DNS_TXT検証か、HTTP_ROUTE検証のいずれかが必要になります（ペネトレーションテストを仕掛けて良い先かどうかを確認するためかと思います）。

また、対象のアプリケーションがパブリックインターネット上で利用できない場合は、この設定項目でVPC（VPC, Security Group, Subnet）の情報を入力することでアプリケーションへのアクセスが可能です。

ただ、現状Document上に以下の注意事項が書かれており、10.0.0.0/16の範囲と重複する場合は現状サポートされていないようなため、現時点では外部未公開のアプリケーションでは検査できないケースも多そうです。

For VPC penetration tests, VPC CIDR ranges that overlap with the 10.0.0.0/16 range are currently not supported. Additionally, if you have a VPC IP endpoint that falls within this CIDR range, it will also fail to resolve.

参考：https://docs.aws.amazon.com/securityagent/latest/userguide/connect-agent-vpc.html

ターゲットの必要情報を入力したら画面下部の"保存"ボタンを押下し、マネコン上での設定完了です。

この後の設定は上述したSecurity Agentのウェブアプリ側から行います。

画面の左ペインから"Penetration tests"を押下し、Pnenetration Testの設定を行っていきます。

必須で指定が必要な入力項目はnameとTarget URL、実行時のService roleの情報になります。

また"Next"を押下するとVPCの情報を聞かれるので、対象のアプリケーションがパブリックインターネット上で利用できない場合は、この設定項目も入力します。

更にその後にOption項目が聞かれますが、必要に応じて入力し、設定を完了させます。
※アプリケーションログインに認証が必要なケースの設定や、テストに役立つ追加ドキュメントの提出などがオプション項目から行えるようです。
https://docs.aws.amazon.com/securityagent/latest/userguide/quickstart.html

設定が完了すると以下のような画面に遷移します。

設定としてはこれで完了です。

スキャン編

上述の画面で"Start run"を押下することでスキャンが始まります。
あとはひたすら待つだけですが、Workshopの2時間以内だと終わらなかったので、結果が出るまでに数時間はかかるもののようです。

途中の時点の結果にはなりますが、結果として以下のような内容が出力されます。

今回は記載を割愛しますが、Penetration Testingの結果画面で確認できる内容は以下のページに記載されていますのでご参照ください。

Review findings from a penetration test
https://docs.aws.amazon.com/securityagent/latest/userguide/review-penetration-findings.html

おわりに

本記事では、AWS Security Agentの概要や設定/スキャン方法についてまとめてみました。
DesignやCodeのレビューについては、これまでAmazon Q DeveloperなどのAI Agentツールの利用でできる範囲はあったものの、AWS Security Agentの利用により、より実施しやすくなったのではと思います。
また、Penetration Testについてはこれまで外部のサービスを利用する方法が主流だったため、AWSマネージドサービスで実施できるのはかなり嬉しいアップデートかと思います。

現状Preview版のため料金等は不明ですが、G/Aされたら是非使っていきたいサービスになりそうです。