AWS Security Agent Hands-on - 帰国後アウトプット
はじめに
AWS Security AgentはAWS re:Invent 2025で発表されたフロンティアエージェントの1つです。SDLC（Software Development Life Cycle）における設計～デプロイをカバーする3つの機能が提供されています。現在はプレビューでバージニア北部（us-east-1）でのみ利用可能です。もちろん料金無料です。今回はこれらの機能を一通り実践し、使用感を確認していきます。
- 設計レビュー
- コードレビュー
- ペネトレーションテスト
SDLCとは、ソフトウェア開発の計画から保守まで一連の全フェーズを指し、以下の段階で構成されます。
- 企画：ビジネスニーズの分析、市場調査、プロジェクトの目標と予算、スケジュール計画
- 要件定義：ビジネス要件と機能要件を明確化
- 設計：システムアーキテクチャ、データベース設計、セキュリティ設計などの具体的な仕様作成
- 開発 ：コーディング
- テスト ：単体テスト、結合テスト、システムテスト、受入テストなど
- デプロイ ：本番環境へリリース
- 運用・保守 ：本番環境での運用、トラブル対応、継続的な改善
準備
まず、AWS Security Agentの評価対象となるドキュメントやWebアプリケーションを用意する必要があるので、簡易的なTODOアプリをKiroと一緒に作成しました。
- Kiroを使ってTODOアプリを作成
- Amplifyでアプリをホスト
- Route53でドメインを取得
- Amplifyでカスタムドメインを設定
AWS Security Agent Hands-on
AWS Security Agentは3つのコンポーネントから成ります。AWS DevOps AgentにもエージェントスペースやWebアプリケーションがありますね。
- エージェントスペース
- マネジメントコンソールにて、評価対象のアプリケーション/プロジェクト単位にエージェントスペースを作成します。
- Webアプリケーション
- エージェントスペースを作成するとWebアプリケーション（以降、「Webアプリ」と記載）も作成されます。これは設計レビューとペネトレーションテストを実行・管理するための独自のWebページです。
- 統合
- GitHubへの接続を管理します。
AWS Security Agentのコンソールではこの他に「セキュリティ要件」を設定します。セキュリティ要件ごとに有効/無効にすることで設計レビュー/コードレビューの観点を取捨選択できます。
- マネージドセキュリティ要件
- 認証・認可、監視、暗号化、シークレット管理、機密情報保護などの観点でAWSが策定したセキュリティ要件。プレビュー時点では10個用意されている。
- カスタムセキュリティ要件
- ユーザが独自にセキュリティ要件を作成できる。
設計レビュー
エージェントスペースを作成後、まずは設計レビューを実施します。Webアプリの「Design review」からKiroが作成したspecをアップロードします。
結果は残念ながら不発でした。「そもそもspecにセキュリティ設計が書いてないから評価できない」、ということでしょうか。何か出てくると思いましたが安直でした。今回はこれでスルーします。
コードレビュー
GitHubリポジトリと接続後、プルリクエストを作成すると自動でエージェントがレビューを開始します。
指摘通りに修正してリポジトリにプッシュしましたが、エージェントが動きません。（公式ドキュメントには「エージェントは更新されたコードを分析します」と書いてあるのですが）。仕方がないので、新しいプルリクエストを作成して、エージェントに再レビューさせました。
下記は指摘の日本語訳になります。
build コマンドは--no-auditフラグを使用してnpmのセキュリティ脆弱性スキャンを無効化します。
これにより、依存関係のインストール中に既知の脆弱性や侵害されたパッケージが検出されなくなります。
これにより、既知のCVEや悪意のあるコードを含むパッケージが警告なしに本番環境にデプロイされ、重大なセキュリティリスクが生じます。
このフラグを削除すると、サプライチェーン攻撃に対する重要な防御として機能する自動セキュリティチェックが有効になります。
監査の失敗が問題となる場合は、npm audit --audit-level=high依存関係のセキュリティ体制の可視性を維持しながら、
重大な脆弱性がある場合にのみビルドを失敗させる別のコマンドの使用を検討してください。
再レビューでは指摘なしだったのでマージしました。
ペネトレーションテスト
ペネトレーションテストとは、システムやネットワークに対して、実際の攻撃者のように侵入を試みることで、セキュリティ上の脆弱性を発見するテスト手法です。攻撃シナリオに沿い、どの程度攻撃に耐えられるのか評価します。
ペネトレーションテストを開始する前にドメインの所有権を証明する必要があります。Route53にドメインを登録している場合は、AWS Security Agentのコンソールから「DNSレコードの作成」→「検証」を実行します。「DNSレコードの作成」によって、パブリックホストゾーンにTXTレコードが自動作成されます。
ここからはWebアプリでペネトレーションテストを設定していきます。基本的にはデフォルトですが、カスタマイズした項目は以下です。
※「CloudWatch log group - optional」は設定しなくとも、自動でロググループが作成されます。
- Pentest name
- ペネトレーションテストの名前
- Target URL
- 評価対象のWebアプリケーションのURL
- Service role
- 初回エージェントスペース作成時にデフォルトで作成されたIAMロール
- Automatic code remediation
- 有効（Enable automatic code remediation）
- Additional learning resources - optional
- todo-app（GitHub repository）
ペネトレーションテストの実行には1時間30分程かかりました。
重要度レベル：中が2件検出されました。内1つを見ると、かなり詳しく解説されていますが、正直どのくらい致命的な内容なのか分かりかねます（自身の実力不足）。。。自動修復を有効にすると、エージェントが検出結果に対処するためのプルリクエストをペネトレーションテスト中に作成します。「Remediate code」（コードを修正する）から手動作成することも可能です。
GitHubリポジトリを確認すると、エージェントがmainブランチから作業用ブランチ「aws-security-agent-XXXXXXXXXXXXX」を切り、修正・プルリク作成が行われていました。プルリクが作成されたので、「コードレビュー」で設定したエージェントによるレビューも実施されます。プルリクは3つなのに、なぜかブランチは4つ作成されていました。1つは何も修正が加えられず、mainブランチ（最新）と同じなので、エージェントがペネトレーションテストの際、システムを理解するための参照用に作成したのだと考えました。
人の介入が必要なのは、プルリクのレビューだけなので、エージェントの作業精度が高ければ凄まじい自動化になりそうです（すばらしい）。
さいごに
今回は、AWS Security Agentの基本的に機能を一通りさわってみました。設定自体はかなり簡単でしたが、検出結果を理解するには骨が折れそうです。また、心残りが2つあります。何かご存じの方、教えてください。
- コードレビュー後に追加プッシュした時、再レビューを自動実行するには？
- 設計レビューに使えそうなサンプルドキュメントがWeb上に転がっていないか？
re:Inventでは3つのフロンティアエージェントが発表されました。AWS DevOps Agent、AWS Security Agentはさわれましたが、Kiro autonomous agentはウェイトリストに登録し、待ちの状態です。フロンティアエージェントによって、企画・要件定義以外のフェーズはエージェントがカバー可能なため、ガンガン使って人の作業量を減らし、ラクしたいです。
Discussion