AWS re:Invent 2025 にて、AWS Security Agent がプレビュー公開されました。

AWS Security Agent とは

AWS Security Agent は、アプリケーションの開発ライフサイクル全体を通じて、セキュリティ態勢の向上を支援するサービスです。 設計（デザイン）、実装（コード）、検証（テスト）の各フェーズにおいて、生成 AI を活用したセキュリティレビューと修正に向けたアドバイスを行なってくれます。

以下の3つの主要な機能で構成されています。

  • Design reviews
    • アーキテクチャ図や仕様書などの設計ドキュメントをアップロードすることで、システム構成上のセキュリティリスクやコンプライアンス違反の可能性を分析します。
  • Code reviews
    • アプリケーションのソースコードを分析し、脆弱性やセキュリティのベストプラクティスからの逸脱を検出します。
  • Automated testing
    • 稼働中のアプリケーションに対して自動化されたペネトレーションテスト（侵入テスト）を実行し、外部から悪用可能な脆弱性がないかを検証します。

この中で今回は最も手軽な Design reviews を試してみます。

やってみた

まずはセキュリティエージェントをセットアップします。
エージェントスペース名、アクセス方法を選択し設定を完了します。


作成したエージェントスペースを選択すると、WebアプリケーションのURLが表示されています。

Webアプリケーションを表示すると、AWS Security Agent の画面が表示されます。
先ほどのAWS マネジメントコンソールの画面で Code reviews、Penetration testing の設定をまだ行っていないため、Design reviews のみ有効化されています。

design review を試す

AWS Security Agent の Design reviews では設計書をアップロードすると、セキュリティ観点でレビューをしてくれるというので仮でGeminiに「アーキテクチャドキュメント」と「仕様書」の2つを作成してもらいました。

少し長いですが、例としてアーキテクチャドキュメントを載せます。仕様書は同様のクオリティなので載せませんが、同じようにざっくり仕様で欠陥を持たせた内容にしています。
敢えて(露骨に)設計に欠陥を含めたドキュメントを生成してくれました。

# システムアーキテクチャ設計書

## 1. ネットワーク構成 (VPC Design)
### 1.1 基本方針
開発スピードとデバッグの容易性を最優先し、ネットワーク分離による複雑化を避けるため、フラットなネットワーク構成を採用する。

### 1.2 VPC設定
* **CIDR:** `10.0.0.0/16`
* **DNS Hostnames:** Enabled
* **DNS Support:** Enabled

### 1.3 サブネット構成
* **区分:** 単一パブリックサブネット構成（Web/App/DBすべてを同居）
* **CIDR:** `10.0.1.0/24`
* **Availability Zone:** ap-northeast-1a
* **Auto-assign Public IP:** **Enabled (True)**
    * *設計意図:* 踏み台サーバー（Bastion）の運用負荷を減らすため、全リソースに直接グローバルIPを割り当て、外部から直接アクセス可能とする。

### 1.4 ルーティング
* **Route Table:** 全トラフィック (`0.0.0.0/0`) を Internet Gateway (IGW) へルーティング。

---

## 2. コンピュートリソース (EC2)
### 2.1 インスタンス設定
* **AMI:** Amazon Linux 2 (Kernel 5.10)
* **Instance Type:** t2.micro
* **IAM Role:** `EC2-FullAdmin-Role`
    * **Attached Policy:** `AdministratorAccess`
    * *設計意図:* 開発中に権限不足エラーで止まるのを防ぐため、管理者権限を付与しておく。
* **Metadata (IMDS):** v1 (IMDSv2 Optional)

### 2.2 セキュリティグループ (`sg-allow-all`)
デバッグ効率化のため、すべての通信を許可する。

| Type | Protocol | Port Range | Source | Description |
| :--- | :--- | :--- | :--- | :--- |
| All traffic | All | 0-65535 | **0.0.0.0/0** | Allow all for debugging |

---

## 3. ストレージ & データベース
### 3.1 オブジェクトストレージ (S3)
* **Bucket Name:** `legacy-app-public-share`
* **Public Access:** **All Enabled (Block Public Access: Off)**
* **ACL:** `public-read-write`
    * *設計意図:* 外部ベンダーとのファイル受け渡しをスムーズにするため、誰でもアップロード/ダウンロード可能にする。
* **Encryption:** None
* **Versioning:** Disabled

### 3.2 データベース (RDS for MySQL)
* **Instance Class:** db.t3.micro
* **Engine Version:** MySQL 5.7 (EOLに近いバージョンを選択)
* **Publicly Accessible:** **Yes**
    * *設計意図:* 開発者のローカルPCからGUIツールで直接DB接続してデータ確認を行うため。
* **Storage Encryption:** Disabled
* **Master Username:** `admin`
* **Master Password:** `Password123!` (暫定)

---

## 4. 認証・認可 (IAM)
* **Root User:** MFA未設定（開発初期のため）
* **Developers:** 共通のIAMユーザー `dev-team-shared` を作成し、アクセスキーをチーム内で共有する（`.env`ファイル等で管理）。

Create design review から設計レビューを開始します。
名前と対象のファイルをアップロードするだけでレビューが開始できます。
DOC, DOCX, JPEG, MD, PDF, PNG, TXT のファイル形式がサポートされています。

レビューを開始すると、数分で結果が表示されます。

9個の非準拠項目が検出されました。
内容と関係ないんですが、一度レビューするとこのレビュー結果を消すところはありませんでした。。プレビューだからですかね。。
スペースごと削除すれば、消えてくれます。

中身を見ると、要約されていますが、セキュリティ観点のレビューがいくつか指摘されています。

Geminiで翻訳してもらいました。

コメント
システムが適切なガードレール（保護措置）なしに過剰な特権アクセスを許可しているため、結果は NON_COMPLIANT（非準拠） です。具体的には、EC2インスタンスに AdministratorAccess IAMポリシーが付与されていること、ルートアカウントにMFA（多要素認証）がないこと、開発者が単一のIAMユーザーを共有し認証情報をリポジトリに保存していること、そしてRDSが脆弱なパスワードでパブリックアクセス可能な状態であることが挙げられます。

修復ガイダンス
コンプライアンス（準拠）を達成するためには、以下の対策を実施してください：
EC2に対し、最小権限のIAMロールを実装する。
ルートアカウントでMFAを有効にする。
共有の認証情報ではなく、個別のIAMユーザーを提供する。
RDSへのパブリックアクセスを削除する。
Secrets Manager等を使用し、強力なパスワード管理を行う。

各項目で推奨事項がこのように数分で出力されました。

AWS Security Agent のAWSコンソールへ行くと、このセキュリティ要件の無効化やカスタマイズができます。

まとめ

設計書があれば、セキュリティレビューが手軽に行えるのでその点は便利そうです。
他にもGitHubアカウントと接続した Code reviews や Penetration testing があるため、少し設計書レビューと比較してハードルは高いですが、機会があれば試してみたいと思います。