AWS Security AgentでAIによる統合セキュリティレビューを体験しよう

この章では、AWS Security Agentを使った次世代型の統合セキュリティレビューをハンズオン形式で学習します。これにより、AIによる設計レビュー・コードレビュー・ペネトレーションテストが1つのサービスで統合実行できるようになります。

1. AWS Security Agentとは

AWS Security Agent（AWSセキュリティエージェント）は、re:Invent 2025でプレビュー発表され、2026年3月31日にオンデマンドペネトレーションテスト機能が一般提供（GA）されたAIエージェント型のセキュリティサービスです。これまで別々のツールで扱っていた「設計レビュー」「コードレビュー（SAST）」「動的セキュリティテスト（DAST / ペネトレーションテスト）」を1つのサービスに統合し、AIエージェントが自動で実行してくれます。

従来のDevSecOpsでは、以下のように複数のツールを個別に導入・運用する必要がありました。

AWS Security Agentでは、これらすべてをAIエージェントが肩代わりしてくれます。特にペネトレーションテストは従来「年に1〜2回、外部ベンダに依頼して数百万円」が相場でしたが、Security Agentならオンデマンドで何度でも実行できるのが革命的なポイントです。

1.1 AWS Security Agentの3つの機能

AWS公式ドキュメントのAWS Security Agent capabilitiesでは、以下の3つの機能が提供されています。

1. 設計レビュー

設計ドキュメント（アーキテクチャ図・API仕様書・ER図など）をアップロードすると、AIエージェントがコードが書かれる前にセキュリティ上の問題を指摘してくれます。組織レベルで定義したセキュリティ要件（承認済みライブラリ・ログ基準・データアクセスポリシー）への準拠性も自動でチェックされます。

「シフトレフト」の究極系で、実装前の設計段階で問題を潰せるのが特徴です。

2. コードレビュー

GitHubリポジトリと連携し、プルリクエストが作られるとAIエージェントが自動でコードをレビューします。検出対象は以下の3パターンから選択できます（公式ドキュメント参照）。

プルリクエストに直接コメントを書き込んでくれるため、開発者は普段のGitHubワークフローの中でレビュー結果を受け取れます。なお、コードレビューはPrivateリポジトリのみが対象です。

3. ペネトレーションテスト

稼働中のWebアプリケーションやAPIに対して、AIエージェントが多段階攻撃シナリオを自動生成・実行し、実際に悪用可能な脆弱性を発見・検証します。AWS News Blogによると、13種類のリスクカテゴリ（OWASP Top 10を含む）に対するテストを実行できます。

静的解析では見つけられない「動的な脆弱性」や「複数の脆弱性を連鎖させた攻撃経路」を発見できるのが特徴です。さらに、発見した脆弱性を自動修正するプルリクエストまで作成してくれます。

2. 事前準備

2.1 前提となる講座

この章では、以下の知識を前提としています。自信がない場合は先に関連講座を実施してみましょう。

2.2 必要なツール

この章では、以下のツールを使用します。まだインストールしていない場合は、リンク先の手順に沿って準備をお願いします。

2.3 必要なアカウント

この章では、以下のアカウントを使用します。まだ用意していない場合は、リンク先の手順に沿って準備をお願いします。

2.4 サンプルファイルのダウンロード

フェーズ1〜2で使う設計ドキュメントとソースコードを zip でまとめています。以下のボタンからダウンロードし、任意の作業ディレクトリに展開しておいてください。

zip を展開すると、以下のファイル構成になります。

tasks-api-source/
├── design-doc.md           ← フェーズ1（設計レビュー）でアップロードする設計書
└── app/
    ├── __init__.py
    └── main.py             ← フェーズ2（コードレビュー）でPrivateリポジトリにpushするFastAPIコード

3. セットアップ: AWS Security Agentの初期セットアップ

AWS Security Agent は、最初に 1回だけ必要なアカウントレベルのセットアップ を行い、同時に最初の エージェントスペース（アプリケーション単位のワークスペース）を作成します。AWS公式の Set up AWS Security Agentに準拠した手順で進めます。

3.1 リージョンの確認

AWS Security Agent は提供リージョンが限られているため、まず最初に作業リージョンを正しく選んでおかないと、後でサービス画面が表示されなかったり、別リージョンに重複セットアップしてしまうトラブルにつながります。AWS Security Agent は、東京・バージニア北部・オレゴン・アイルランド・フランクフルト・シドニーの6リージョンで利用可能です。本セクションでは、他のハンズオンと統一するため 東京リージョン（ap-northeast-1） で進めます。マネジメントコンソール右上のリージョンセレクタから アジアパシフィック（東京） ap-northeast-1 を選択してください。

3.2 Security Agentコンソールを開く

エージェントスペースの作成・管理は専用のコンソールから行うため、まずSecurity Agent画面を開きます。検索バーに Security Agent と入力し、AWS Security Agent のサービス画面を開きます。AWS Security Agent のランディングページが表示されたら、右側の 「AWS Security Agent をセットアップ」 をクリックします。

3.3 セットアップ画面の設定

セットアップ画面は1つのフォームに エージェントスペース設定 / ユーザアクセス設定 / サービスアクセス・Encryption・タグ（折りたたみ） が並んだ構成になっています。本セクションで設定するのは前半の2つで、後半のオプションはすべてデフォルトのままで構いません。

まず エージェントスペース設定 を入力します。エージェントスペースはアプリケーション・プロジェクト単位のワークスペースで、連携する GitHub リポジトリ・過去の設計レビュー・ペネトレーションテスト設定・検出結果がひとまとめに管理されます。

次に ユーザアクセス設定 で、ウェブアプリケーションへのアクセス方法を選択します。

• 「IAM アイデンティティセンターによるシングルサインオン (SSO)」は IAM Identity Center 統合による SSO で、複数人のチーム運用に向いている
• 「IAM 専用アクセス」は AWS マネジメントコンソール経由でのアクセスのみで、簡易セットアップに向いている

本セクションでは 「IAM 専用アクセス」 を選択します。

残りの サービスアクセス・Encryption・タグ は折りたたまれているセクションで、本セクションでは展開せずデフォルトのままで構いません。サービスアクセスは未設定のまま進めると、AWS Security Agent が必要な権限を持つ IAM ロールを自動作成してくれます。

設定が終わったら、画面右下の 「AWS Security Agent をセットアップ」 をクリックします。

3.4 セットアップの完了

クリックすると AWS Security Agent がエージェントスペースと Web Application、必要な IAM リソースを作成し、エージェントスペース一覧画面に遷移します。

画面上部に緑色の通知 「アプリケーションが正常に有効化されました。ようこそ！」 が表示され、一覧に fastapi-sample-app が並んでいれば、初期セットアップは完了です。

4. フェーズ1: 設計レビューを体験

事前準備でダウンロード・展開した zip 内の design-doc.md を Security Agent にアップロードし、AIが設計段階の問題を指摘してくれる流れを、Create a design reviewの手順に沿って体験します。

Security Agent では、AIが設計レビューを行う際に 「セキュリティ要件」 に対する準拠性を評価します。セットアップ直後の状態では、AWS が提供するベストプラクティス由来の AWS マネージドのセキュリティ要件が10個有効化されている ため、組織独自の要件を定義しなくても、それらに対するレビューがすぐに実行できます。

4.1 Web Applicationを起動

セットアップ完了直後はエージェントスペース一覧画面が表示されているので、ここから今回の対象である fastapi-sample-app をクリックして詳細画面を開きます。詳細画面には「ペネトレーションテスト」「設計レビュー」「コードレビュー」の3つのカードが並んでおり、フェーズ1で使うのは「設計レビュー」カードです。

「設計レビュー」カードの 「ウェブアプリケーションで開始」 をクリックします。

別タブで Security Agent 専用の Web Application が開きます。ホーム画面の「デザインレビュー」カードにある 「デザインレビューを作成」 をクリックします。

4.2 デザインレビューの作成

Web Applicationが開いたら、レビュー対象の設計書をアップロードしてAIに渡します。今回の対象は事前準備でダウンロードした design-doc.md で、Tasks APIの設計に意図的な脆弱性（認証バイパス・平文パスワード保存など）を埋め込んであります。AIがこの設計書のどこを問題と判断するかを確認していきます。

「デザインレビューを作成」画面で以下を入力します。

design-doc.md がアップロード済みになっていることを確認し、画面右下の 「デザインレビューを開始する」 をクリックします。

レビューが開始されると、画面上部に「デザインレビュー Tasks API Design が開始されました」の通知が表示され、デザインレビュー一覧でステータスが 「進行中」 になります。

4.3 レビュー結果の確認

レビューを開始した時点で、AIエージェントが設計書をAWSマネージドのセキュリティ要件と照らし合わせて分析を始めます。完了を待ち、設計書のどの部分がどの要件に違反していると判定されたかを見ていきます。

数分後にレビューが完了すると、ステータスが 「完了しました」 に変わり、コントロール件数（10個）が表示されます。一覧から Tasks API Design をクリックして詳細を開きます。

詳細画面では、検出結果の概要 として以下の4ステータスでカウントが表示されます。

意図的に脆弱な設計書を渡しているため、10個すべて「非準拠」 として検出される結果になります。下部の「検出結果のレビュー」では、評価された AWS マネージドのセキュリティ要件と、それぞれの非準拠状況が一覧表示されます。

検出されたセキュリティ要件のうち、Tasks API の設計上の問題と直接対応するものは以下です。

各要件をクリックすると、詳細パネルが開き コンプライアンスステータス・コメント（非準拠と判定した根拠）・修正ガイダンス が表示されます。

レビュー結果一覧に複数の Findings（検出事項） がリストアップされ、各 Finding の詳細パネルで非準拠の根拠と修正ガイダンスが確認できれば、設計レビューの体験は完了です。

5. フェーズ2: コードレビューを体験

フェーズ1では、設計段階でセキュリティ要件への違反を見つける設計レビューを体験しました。ただし、設計書だけでは「どんなコードを書くか」までは見えません。たとえばSQL文字列の組み立て方やパスワードハッシュの選び方など、コードを書いてみないと判明しない問題 は、コミットされたコードに対してレビューする必要があります。

フェーズ2では、GitHubリポジトリを Security Agent と連携し、プルリクエストに対してAIが自動でコードレビューを行う流れをEnable code review capability for a GitHub repositoryの手順に沿って体験します。

5.1 Privateリポジトリの準備

コードレビューはPrivateリポジトリのみが対象のため（公式仕様）、まず事前準備でダウンロードしたコードをPrivateリポジトリにpushします。

GitHubで新規リポジトリを作成します。

作成後、ローカルにクローンします。

git clone https://github.com/＜あなたのユーザ名＞/tasks-api-handson.git

cd tasks-api-handson

事前準備でzipを展開した tasks-api-source/ の中身（design-doc.md と app/）を作業ディレクトリにコピーします。フェーズ2でレビュー対象になるのは app/main.py のコードですが、design-doc.md もフェーズ3のペネトレーションテスト時に ソースコードのコンテキスト として参照されるため、ここで一緒にpushしておきます。

cp -r ＜zip展開先＞/tasks-api-source/* .

リポジトリにpushします。

git add .

git commit -m "Add initial Tasks API"

git push origin main

GitHubの該当リポジトリで design-doc.md、app/main.py、app/__init__.py がmainブランチに表示されていれば、Privateリポジトリの準備は完了です。

5.2 GitHub統合の登録（テナントレベル）

コードレビューを動かすには、Security Agent と GitHub を信頼関係で結ぶ必要があります。Security Agent側に「どのGitHub組織・ユーザのリポジトリを見るか」、GitHub側に「Security Agent App にどんな権限を渡すか」を双方向で登録するのがこのフェーズです。テナント（AWSアカウント）レベルの一度きりの設定なので、ここで登録しておけば以降のエージェントスペースから再利用できます。

統合の追加モーダルを開く

GitHub統合の登録は、エージェントスペース詳細画面の「コードレビューを有効にする」を起点に進めるフローになっています。エージェントスペース詳細画面のコードレビューカードにある 「コードレビューを有効にする」 をクリックします。

「統合を追加」 モーダルが開きます。初回は登録済みのGitHub統合がないため、右側の 「新規登録を作成」 を選択し、下の GitHub を選択して 「次へ」 をクリックします。

「GitHub を AWS Security Agent に接続」 画面が開きます。この画面は ステップ1（GitHub App のインストール） / ステップ2（AWS Security Agent の認証） / ステップ3（登録の詳細） の3部構成になっており、上から順に進めます。

ステップ1: GitHub App のインストール

GitHub側に「Security Agent App」を入れることで、Security Agent が GitHub のリポジトリやPRを操作できるようになります。これがないとSecurity Agent側から GitHub にコメントを書き込んだり、PRを生成したりできません。ステップ1 の「GitHub で AWS Security Agent を開く」をクリックすると、GitHub の AWS Security Agent App ページが開きます。右上の 「Install」 をクリックします。

インストール範囲の選択画面になります。本セクションでは自分のアカウント配下の tasks-api-handson リポジトリだけが対象なので、「All repositories」 のままで問題ありません（「Only select repositories」で tasks-api-handson のみ指定してもOK）。「Install」 をクリックします。

ステップ2: AWS Security Agent の認証

ステップ1 はGitHub側のAppインストールだけなので、次はAWS側に「このGitHubユーザとして連携してよい」という認証情報を渡します。これがAWS↔GitHub の双方向トラスト関係を完成させるステップです。AWS Security Agent の画面に戻ります。次に ステップ2 の 「認証する」 をクリックします。

GitHub の認可画面にリダイレクトされます。AWS Security Agent が GitHub アカウントへアクセスする権限を確認し、「Authorize」 をクリックします。

AWS Security Agent の画面に戻ると、ステップ2に 「認証が成功しました」 のチェックマークが表示されます。

ステップ3: 登録の詳細を入力

最後にAWS側でこの統合を識別する名前と、対象とするGitHubアカウントタイプを登録します。これでテナント（AWSアカウント）レベルのGitHub統合の登録自体は完了します。ステップ3 の登録の詳細を入力します。

入力後、右下の 「接続」 をクリックします。

エージェントスペース画面に遷移し、上部に緑のバナー 「GitHub 統合が正常に接続されました」 が表示されれば、テナントレベルのGitHub統合登録は完了です。

5.3 エージェントスペースへのリポジトリ接続とコードレビュー有効化

ここからはエージェントスペースレベルの操作で、実際に監視対象となるリポジトリを fastapi-sample-app エージェントスペースに紐付けます。

統合追加モーダルから既存の登録を選択する

テナントレベルのGitHub統合を登録しただけでは、どのエージェントスペースから・どのリポジトリを 監視するかが決まっていません。同じモーダルからもう一度フローを開始し、今度は登録済みのGitHub統合を再利用してエージェントスペースに紐付けていきます。エージェントスペース詳細画面に戻ったら、コードレビューカードの 「コードレビューを有効にする」 を再度クリックします。

再び 「統合を追加」 モーダルが開きますが、今度は前項で登録したGitHub統合が 「利用可能な登録」 に表示されています。tasks-api-handson を選択して 「次へ」 をクリックします。

監視対象リポジトリを選択する

GitHub統合は組織やユーザ全体への接続なので、その配下に複数のリポジトリがある場合は、どれをこのエージェントスペースで監視するか を明示的に選ぶ必要があります。本セクションの対象は1つだけなので、それだけにチェックを入れます。「GitHub リポジトリを接続」 画面で、登録済み組織配下のリポジトリ一覧が表示されます。本セクションの対象である tasks-api-handson にチェックを入れて 「次へ」 をクリックします。

機能を有効化する

「機能を管理」 画面で、接続したリポジトリに対して有効にする機能を設定します。リポジトリ列のチェックを入れただけでは機能はONになりません。コードレビュー列とペネトレーションテストの修正列のトグルを、それぞれクリックして「有効化済み」に切り替える 必要があります。

コードレビュー設定で検出対象を選ぶ

コードレビューでは「汎用的な脆弱性パターンを検出する」「組織独自のセキュリティ要件への準拠性をチェックする」「両方」のいずれかを選べます。本セクションではフェーズ2で組織要件をまだ登録していないため、まずは汎用的な脆弱性検出のみを選び、AIが何を指摘してくれるかを体験します。次に 「コードレビュー設定」 で検出対象を選択します。

右下の 「接続」 をクリックします。

接続完了を確認する

設定が一通り終わっても、本当にエージェントスペースとリポジトリが正しく紐付けられているかを画面で確認しないと、後でPRを作っても「レビューが走らない」という事態に気付くのが遅れます。コードレビュータブの状態を確認することで、ここで連携の成立を確実にしておきます。エージェントスペース画面に戻り、上部に緑のバナー 「統合リソースが追加されました」 が表示されます。さらに 「コードレビュー」タブ を開き、tasks-api-handson が一覧に並んでいればコードレビューの有効化は完了です。

5.4 脆弱なコードのPR作成

ここまでの設定でコードレビューは有効になりましたが、レビューを動かす対象がまだありません。コードレビューが動くのはプルリクエストが作られた瞬間なので、わざと脆弱性を含んだPRを作って、AIが何を指摘してくれるかを確認します。

先ほどpushした app/main.py に、新しい脆弱なエンドポイント（タスク検索機能）を追加するPRを作成します。

ローカルでリポジトリを開き、ブランチを作成します。

git switch -c add-task-search

app/main.py の末尾（admin_list_users の関数定義の直後）に、以下のコードを追加します。

@app.get("/api/v1/tasks/search")
def search_tasks(q: str):
    conn = get_db()
    c = conn.cursor()
    c.execute(
        f"SELECT id, owner_id, title, body FROM tasks WHERE title LIKE '%{q}%'"
    )
    rows = c.fetchall()
    conn.close()
    return [
        {"id": r[0], "owner_id": r[1], "title": r[2], "body": r[3]}
        for r in rows
    ]

わざと以下の問題を埋め込んでいます。

• f-stringでクエリパラメータを直接SQL文に埋め込んでおり、SQLインジェクションが成立する
• 認証チェックがなく、全タスク（他ユーザのタスク含む）が誰でも検索可能になる

コードをコミットしてプルリクエストを作成します。

git add app/main.py

git commit -m "Add task search endpoint"

git push origin add-task-search

GitHubのリポジトリ画面を開くと、push直後は上部に 「Compare & pull request」 ボタンが表示されています。このボタンから、ベースブランチ main、比較ブランチ add-task-search の構成でプルリクエストを作成します。タイトルはコミットメッセージと同じ Add task search endpoint のままで構いません。

5.5 AIレビューコメントの確認

PR を作成したら、あとは AWS Security Agent が自動でレビューしてくれるのを待つだけです。普段のGitHubワークフローを離れずにAIレビューを受け取れるのが、コードレビュー機能の使い勝手の良さです。

PR を作成すると、ほぼ即時に aws-security-agent Bot から「AWS Security Agent is reviewing your pull request and will post feedback shortly.」というコメントが付き、レビューが開始されたことが分かります。

数分待つと、Bot が PR の解析を終え、全体の要約コメント と、追加した行に対するインラインコメント が投稿されます。

要約コメントでは、search_tasks エンドポイントに対する指摘が一括で提示されます。今回追加したコードに対しては、認証の欠如、owner_id での所有者スコープ不在による情報漏えい、f-string を使った SQL インジェクション の3点が、修正の方向性（get_current_user の呼び出し、WHERE owner_id = ? でのスコープ、パラメタライズドクエリ化）と合わせて指摘されます。

さらに該当行へのインラインコメントは、以下の3つの観点で構造化されています。

• What is the issue?: 何が問題か（コードのどの部分が脆弱か）
• Why is this important?: なぜ重要か（攻撃者に実際に何ができるか）
• What is the recommendation?: どう直すべきか（修正コード例つき）

PR上に要約コメントとインラインコメントが投稿され、SQLインジェクション・認証欠如・情報漏えいの3点に対して修正コード例つきの指摘が並んでいれば、コードレビューの体験は完了です。

6. フェーズ3: ペネトレーションテストを体験

フェーズ2でPrivateリポジトリにpushしたTasks APIと 同じFastAPIコード をCloudFormationでAWSにデプロイし、その稼働環境に対してAIエージェントによる多段階ペネトレーションテストを実行します。フェーズ2でコードレビュー用に連携したGitHubリポジトリを ソースコードのコンテキスト として参照させることで、Security Agentが 設計→コード→稼働環境を横断したコンテキスト で攻撃シナリオを組み立ててくれるのがポイントです。Quickstart: Run a penetration testの流れに沿って体験します。

6.1 Tasks APIをCloudFormationでデプロイ

テンプレートのダウンロード

ペネトレーションテストの対象として、Tasks APIをVPC・ALB・EC2・CloudFrontを含む構成で起動する必要があります。これらを手動で1つずつ作るのは時間がかかるうえ、設定ミスのリスクもあるため、本セクションでは予め用意したCloudFormationテンプレートで一括構築します。以下のボタンからCloudFormationテンプレートをダウンロードしてください。

このテンプレートを適用すると、以下のリソースが作成されます。

CloudFormationスタックの作成

ダウンロードしたテンプレートはローカルにあるだけでは実体が作られません。CloudFormationコンソールからこのテンプレートをアップロードしてスタックを作成することで、Tasks APIのインフラ一式が実際にAWS上にデプロイされます。AWSマネジメントコンソールでCloudFormationのダッシュボードを開き、スタックの作成 > **新しいリソースを使用（標準）**をクリックします。

画面下部の「AWS CloudFormation によって IAM リソースがカスタム名で作成される場合があることを承認します。」にチェックを入れ、スタックを作成します。

ステータスがCREATE_COMPLETEになったら、出力タブを開きます。以下の値をコピーしておきます。

• CloudFrontDomain（例: dXXXXXXXXX.cloudfront.net）: 後ほどSecurity Agentに登録する検証ターゲット
• TasksApiUrl（例: https://dXXXXXXXXX.cloudfront.net）: Tasks APIへのHTTPSアクセス用URL

Tasks APIの動作確認

CloudFormationがCREATE_COMPLETEになっても、EC2上のFastAPIアプリケーションやCloudFrontの伝搬がまだ完了していない可能性があります。ペネトレーションテストの設定段階でドメイン検証を行うため、その前に「CloudFront → ALB → EC2上のアプリケーション」までの経路が本当に通っているかを自分で確認しておくと、後の手順でつまずきません。以下のコマンドでヘルスチェックエンドポイントを叩きます。CloudFront経由のHTTPSでアクセスします。

curl https://＜CloudFrontDomain＞/health

以下のように応答が返れば、CloudFront → ALB → EC2上のFastAPIアプリケーションの経路が正常に稼働しています。

{"status":"ok"}

6.2 ペネトレーションテスト機能を有効化

CloudFormationでインフラが揃ったら、AWS Security Agent側でペネトレーションテストの設定を行います。エージェントスペース詳細画面のヘッダーから Enable penetration test をクリックします。3ステップの設定ウィザードが開きます。

ステップ1: ターゲットドメインの設定

テスト対象のドメインと、所有権の検証方法を指定します。ALBの自動DNS名ではなく、CloudFormationが出力したCloudFrontドメインを指定する のがポイントです（HTTPS要件を満たすため）。

Next をクリックして次へ進みます。

ステップ2: ドメインの検証

Target domainsテーブルで対象ドメインを選択し、Verifyをクリックすると、検証用の固定パス /.well-known/aws/securityagent-domain-verification.json と検証トークン（例: cib4P56CWznyz5vY3WQroA）が表示されます。

このパスへのリクエストに対して、検証トークンを含むJSONを応答させる必要があります。CloudFrontはオリジンであるALBにリクエストを素通りさせる構成のため、ALBのリスナールール に固定レスポンスを設定します。

1. EC2コンソールで ロードバランサー を開き、tasks-api-alb の詳細画面を表示
2. リスナーとルール タブで HTTP:80 のリスナーを選択 → ルールを管理 → ルールを追加

3. 以下の設定で固定レスポンスルールを作成します。レスポンス本文は JSON形式、Content-Typeは application/json が必要な点に注意してください。

ルールを保存したら、ターミナルから直接 CloudFront 経由でアクセスして、想定どおりのJSONが返ることを確認します。

curl -i https://＜CloudFrontDomain＞/.well-known/aws/securityagent-domain-verification.json

以下のように 200 OK ＋ content-type: application/json ＋ JSONボディが返れば成功です。

HTTP/2 200
content-type: application/json
...

{"tokens": ["cib4P56CWznyz5vY3WQroA"]}

curl で正しい応答が確認できたら、Security Agent の画面に戻り、対象ドメインのラジオボタンを選択した状態で 「検証」 ボタンをクリックします。1〜2分待ってからページをリロードし、ステータスが 「保留中」→「検証済み」 に変わっていれば成功です。検証済みのドメインに対してのみ、ペネトレーションテストが実行できます。

ステップ3: 追加リソースの設定（オプション）

ペネトレーションテストのカバレッジを広げるための任意設定項目です。本セクションでは最低限で構いません。

画面下部の Save をクリックします。AWS Security Agentが設定を検証し、必要なAWSリソースを作成します。

6.3 GitHubリポジトリの連携状態を確認

ペネトレーションテストで発見した脆弱性に対しては、修正PRを自動生成させる ことができます。これには エージェントスペースとGitHub リポジトリの連携が必要ですが、本セクションでは フェーズ2 の「エージェントスペースへのリポジトリ接続とコードレビュー有効化」で「ペネトレーションテストの修正」トグルもあわせて有効化済み のため、ここでの追加操作は不要です。

ペネトレーションテスト機能の設定画面下部の GitHub セクションに、tasks-api-handson リポジトリが「ペネトレーションテストの修正：有効化済み」で表示されていれば、フェーズ3の修正PR自動生成は使える状態です。次のセクションに進んでください。

6.4 ペネトレーションテストの実行

ここまでで エージェントスペースとGitHub リポジトリの連携が整ったので、いよいよ稼働中の Tasks API に対するペネトレーションテストを作成・実行します。

Security Agentコンソールのエージェントスペース画面で、ペネトレーションテストカードの 「ウェブアプリケーションで開始」 をクリックして Web Application を起動します。

Web Application のホーム画面に切り替わるので、「ペネトレーションテスト」セクションの 「ペネトレーションテストを作成」 をクリックします。

ここから先は 手順1〜手順4 の4ステップでペネトレーションテストを設定していきます。手順2〜4は「オプション」表記ですが、本セクションでは 手順3（認証リソース）と手順4（学習リソース）まで設定 することで、認証必須エンドポイントの脆弱性検出と、設計→コード→稼働環境を横断したコンテキスト分析の両方を有効化します。手順2のVPCのみスキップします。

手順1: ペネトレーションテストの詳細

最初の手順では、ペネトレーションテストの 基本情報・テスト範囲・実行権限 を設定します。

画面下部にスクロールし、「アクセス許可」 セクションでサービスロールを選択し、「自動コード修正」 セクションでチェックを入れます。

設定したら、画面右下の 「次へ」 をクリックします。

手順2: VPC リソース（オプション）

ターゲットドメインがVPC内のプライベート環境にある場合のみ、ペネトレーションテストを実行するVPCを指定します。本セクションでは Tasks API を CloudFront 経由でPublicアクセス可能な構成 にしているため、VPCの設定は不要 です。

VPC欄は空のままで、画面右下の 「次へ」 をクリックします。

手順3: 認証リソース（オプション）

Tasks APIには認証必須エンドポイント（/api/v1/tasks など）と認証不要エンドポイント（/api/v1/users/{id}、/api/v1/admin/users など）が混在しています。認証必須エンドポイントまで網羅的にテストするため、テストユーザの認証情報を登録します。

エージェントスペースログインプロンプトには、以下の英文をそのまま貼り付けます。

This application is a JSON-based REST API (FastAPI), not a web form.

To authenticate:
1. Send a POST request to /api/v1/auth/login
2. Set the request header: Content-Type: application/json
3. Set the request body (JSON): {"email": "<username>", "password": "<password>"}
4. The response will contain a JWT token in the "token" field of the JSON body
5. For subsequent authenticated requests, include the header: Authorization: Bearer <token>

Use this token to access protected endpoints under /api/v1/tasks.

設定したら、画面右下の 「次へ」 をクリックします。

手順4: その他の学習リソース（オプション）

最後の手順では、AIがアプリケーションの構造を理解しやすくするための追加リソースを設定します。フェーズ1〜2で既に tasks-api-handson リポジトリには design-doc.md、ソースコード、API実装が揃っているため、以下を追加できます。

これらを取り込ませることで、Security Agentは「設計書で cursor.execute を使うと宣言されている → 実装でも実際にf-stringの生SQL → 稼働環境でSQLインジェクションが成立する」という横断的な分析が可能になります。

設定したら、画面右下の 「ペネトレーションテストを作成」 をクリックします。

ペネトレーションテストの実行開始

「ペネトレーションテストが作成されました」の緑バナーが表示されたら、いよいよ実行に進みます。

確認が取れたら、画面右上の 「実行を開始する」 をクリックします。

「ペネトレーションテストが開始されました」の緑バナーが表示され、ステータスが 「進行中」 に切り替われば、ペネトレーションテストの開始は完了です。

6.5 ペネトレーションテスト結果の確認

ペネトレーションテストは最大数時間かかります（対象アプリケーションの規模とリスクカテゴリ数に応じて、本セクションの実測では3〜5時間程度）。実行中はステータスが「進行中」のままなので、完了するまで待ったうえで結果画面に進みます。

実行ステータスを確認する

検出結果の中身に入る前に、まずはテスト全体が正常に最後まで走り切ったかを確認しないと、サマリが信頼できません。途中で失敗していると意図していないFindingsだけが見えるため、対応の優先順位を見誤る原因になります。ペネトレーションテストが完走すると、ステータスが 「完了」 に切り替わり、検出結果の件数（重要・高・中程度・低）がサマリで表示されます。エージェントスペース詳細画面のペネトレーションテストタブで、対象のテスト名（tasks-api-handson-pentest）をクリックして詳細画面を開きます。

「現在の手順」が 「すべての手順が完了しました」、ステータスが 「完了」 になっていれば、テストは正常に終わっています。Tasks APIに意図的な脆弱性を仕込んでいるので、重要 / 高 / 中程度 が複数件、合計10件前後の検出結果が出ていれば期待どおりの状態です。

ペネトレーションテストの実行詳細を確認する

完走したことが分かったら、次は「全体としてどのカテゴリの脆弱性が、どのくらいの重大度で出ているか」を俯瞰して掴みます。最初から個別Findingsの中身を1件ずつ読むのではなく、まずサマリで全体像を把握すると、後で個別Findingsを読む順番（重要度の高い順）を判断しやすくなります。「すべての実行」テーブルから個別の実行行をクリックすると、実行詳細画面 が開きます。ここでは、4フェーズの進捗・重大度レベルの分布（円グラフ）・リスクタイプ別の件数（横棒グラフ）が一目で把握できます。

円グラフは 重大度（Severity） ごとの件数を表しています。重大度の判定基準は AWS Security Agent が出力するレポート（後述の「サンプルレポートのダウンロード」を参照）の Executive Summary に明記されており、重要（Critical） が最優先で対応すべきレベルです（英語表示時の原文。日本語表示の場合は翻訳された日本語が表示されます）。

Critical Requires immediate action; exploitation could lead to system compromise. High Requires prompt attention; exploitation could result in significant security impact. Medium Should be addressed in a reasonable timeframe; contributes to overall security risk. Low Can be addressed as part of regular maintenance; minimal immediate risk. Informational For informational purposes; minimal to no immediate risk.

横棒グラフの リスクタイプ には、Sql Injection、Insecure Direct Object Reference、Privilege Escalation、Server Error 500 など、Tasks APIに仕込んだ脆弱性カテゴリが並びます。Tasks APIで意図したとおり、SQLインジェクションとIDOR（認可の不備）が複数件検出されていれば、AIが想定どおりに脆弱性を発見できている証拠です。

個別Findingsの詳細を確認する

サマリで全体像が見えたら、次は1件ずつのFindingに踏み込みます。Security Agentの強みは「指摘するだけ」ではなく実際に攻撃した証跡（Reproduction Steps）まで残してくれる点なので、ここで詳細パネルを実際に開いて、AIが「どんな攻撃ペイロードで脆弱性を確定させたか」を読み解きます。「検出結果」タブ をクリックすると、検出された個別の脆弱性（Findings）の一覧が左ペインに表示され、選択したFindingの詳細が右ペインに展開されます。

各Findingには、以下の情報が表示されます。これらの指標の意味も、レポートの Executive Summary に定義があります。

エージェントの信頼度（Agent confidence level） は、AIエージェントがそのFindingを本物の脆弱性だと判定した確度です。

Agent confidence level: Indicates AWS Security Agent's certainty that a finding represents a genuine security vulnerability. High confidence findings have been verified and confirmed through successful exploitation. Medium and low confidence findings may require additional manual validation.

重大度（Severity） は前述の Critical / High / Medium / Low / Informational の5段階です。リスクスコア（Risk score） は CVSS v3.1 に基づく数値で、10.0 が最大 です。

Risk score: A numerical assessment combining the severity of the vulnerability with the likelihood of exploitation using Common Vulnerability Scoring System (CVSS) metrics. Higher scores indicate findings that should be prioritized for remediation. Risk scores are calculated using CVSS v3.1 (Common Vulnerability Scoring System version 3.1).

たとえばスクリーンショットで選択している 「SQL Injection Authentication Bypass in Login Endpoint」 は、レポートで以下のように説明されています。/api/v1/auth/login の email と password の両方からSQLインジェクションが成立し、認証をバイパスして管理者トークンを取得できることが確認されています。

The POST /api/v1/auth/login endpoint is critically vulnerable to SQL injection via both the email and password JSON body fields. The application constructs raw SQL queries using unsanitized user input against a SQLite 3.40.0 database, allowing multiple injection techniques:

1. OR-based predicate injection: Injects ' OR 1=1-- into the email field, making the WHERE clause always true and returning the first database row (admin user) without valid credentials.
2. UNION-based data extraction: Injects UNION SELECT sqlite_version(),2-- to append an attacker-controlled SELECT statement, causing the DB to return arbitrary data ...
3. Password field injection: The password field is equally vulnerable — injecting ' OR '1'='1 bypasses password verification and returns the admin token.

詳細パネルを下にスクロールすると、Reproduction Steps（再現手順）として実際に投げた curl コマンドと応答が掲載され、Risk Reasoning で CVSS の各メトリクス（AV / AC / PR / UI / S / C / I / A）の評価根拠が解説されます。「疑わしい」で止まらず 実際に攻撃リクエストを送って成功したログまで残している のが、AIペネトレーションテストの特徴です。

PDFレポートを生成する

画面で個別に確認する以外に、全Findingsを1つのPDFレポートにまとめて出力 できます。チームへの共有や、コンプライアンス監査の証跡として保管する用途を想定した機能です。

実行詳細画面の右上にある 「レポートを生成」 ボタンをクリックします。

レポートに含める内容を絞り込むダイアログが開きます。デフォルトではすべてのリスクレベル・リスクタイプ・タスクステータスが選択された状態になっています。

設定したら、画面右下の 「生成してダウンロード」 をクリックします。1分前後でPDFがダウンロードされます。

サンプルレポートのダウンロード

参考として、本セクションの制作時に Tasks API で実際に実行したペネトレーションテストのレポートPDFを配布します。実行を見送った場合でも、このPDFを読むことで「どのような検出結果が出力されるのか」「Findings の証跡がどこまで詳細に書かれるのか」を体感できます。

PDFは大きく以下の構成になっています。

• Executive Summary: テスト全体の概要と、Severity / Confidence / Risk score の判定基準
• Scope: テスト対象ドメインと使用した認証情報
• Methodology: 4フェーズの実行アプローチと、各リスクカテゴリで実行した攻撃シナリオの一覧
• Findings (12): 検出されたFindingsの一覧（タイトル・重大度・ステータス）
• Detailed Findings: 個別Findingごとの詳細（Description / Reproduction Steps / Risk Reasoning）

メソドロジーのセクションには、AIエージェントが取る4フェーズのアプローチが明記されています。

This penetration test was conducted using AWS Security Agent, which deploys specialized AI agents through a four-phase approach: Preflight (connectivity validation), Static Analysis (code and configuration review), Penetration Testing (runtime vulnerability exploitation), and Finalizing (validation and reporting). The agent analyzes application context from source code and documentation to identify vulnerabilities through tailored multi-step attack scenarios.

そして、Security Agent の最大の特徴である 「証跡ベースの検証」 がここで宣言されています。

AWS Security Agent validates findings through proof-based exploitation, providing reproducible attack paths with step-by-step evidence. Each finding includes CVSS v3.1 severity assessment, confidence rating based on validation success, and detailed reproduction steps.

サンプルレポートでは、Tasks APIに意図的に仕込んだ脆弱性が 12件のFindings として検出されています。重要（Critical）3件・高（High）5件・中程度（Medium）3件・参考情報（Informational）1件という内訳で、特に Critical の上位3件は SQLインジェクション・認証バイパス・複数の脆弱性を連鎖させた完全な権限昇格チェーン という、いずれも単独で本番システムを致命的に侵害できるレベルの脆弱性です。

6.6 修正PRを自動生成する

PDFレポートで結果を把握できたあと、AWS Security Agent には 検出された脆弱性に対する修正コードを生成し、GitHub にPRとして自動投稿する 機能が用意されています。Findingの詳細パネル右上にある「コードを修正」ボタンをクリックすると、Security Agent が修正案を考案し、フェーズ2で連携済みの tasks-api-handson リポジトリに 修正PRを自動作成 してくれます。

公式ドキュメントの Remediate a penetration test finding では、リポジトリ種別による挙動の違いが明記されています（英語表示時の原文。日本語表示の場合は翻訳された日本語が表示されます）。

For private GitHub repositories, AWS Security Agent opens a pull request with the proposed fix. For public repositories, the remediation is available as a downloadable diff file that you can apply locally.

本セクションの tasks-api-handson は Privateリポジトリ で連携しているため、ボタンを押すと修正PRがGitHubに自動作成されます。生成されたPRは Finding 詳細パネルの「Code Remediation」セクションにステータスとPRリンクが表示されるので、GitHubの Pull requests タブから通常のレビュー・マージのフローで適用できます。

なお、上記のスクリーンショットでは「コードを修正」ボタンが灰色で非活性になっています。Security Agent側で 修正対象のコード位置が明確に特定できたFinding に対してはこのボタンが活性化され、クリックすると修正PRが作成される、という挙動になります。

Findings一覧に複数件が表示され、PDFレポートをダウンロードできていれば、ペネトレーションテストの体験は完了です。

6.7 検出された脆弱性の解説と対策案

ここからは、サンプルレポートに掲載されている12件のFindingsの中から特に重要な4種類を取り上げ、レポートの記述を引用しながら何が問題で、どう直すべきか を解説します。Tasks APIには複数の脆弱性が連鎖した攻撃チェーンが成立していますが、根本原因は「入力値の検証不足」「暗号学的保護の欠如」「認可チェックの欠落」の3点に集約されます。Security Agent の「コードを修正」ボタンが自動生成するPRも、おおむねここで紹介する方針の修正コードになっています。

SQLインジェクション（Finding 1・2・6）

レポートの Finding 2 では、ログインエンドポイントが致命的なSQLインジェクションに対して脆弱であることが指摘されています（英語表示時の原文。日本語表示の場合は翻訳された日本語が表示されます）。

The POST /api/v1/auth/login endpoint is critically vulnerable to SQL injection via both the email and password JSON body fields. The application constructs raw SQL queries using unsanitized user input against a SQLite 3.40.0 database

Tasks APIの app/main.py ではログイン処理が、ユーザ入力を f-stringで生SQLに直接埋め込む 実装になっています。攻撃者が email フィールドに ' OR 1=1-- を渡すと、SQLが WHERE email='' OR 1=1--' AND password='...' のように展開され、WHERE 句が常に真になることで、認証なしに最初の行（管理者）のトークンが取得できてしまいます。

対策は、ユーザ入力を SQL構文の一部としてではなく値として扱わせる ことです。素のsqlite3を使う場合は ? プレースホルダによるパラメータ化クエリ、SQLAlchemyを使う場合はORMのfilterを利用します。

NGの実装例です。f-stringでSQLを組み立てており、入力値が構文として解釈されてしまいます。

cursor.execute(
    f"SELECT * FROM users WHERE email='{email}' AND password='{password}'"
)

パラメータ化クエリで書き換えると、入力値は値として渡されるためSQL構文に影響しません。

cursor.execute(
    "SELECT * FROM users WHERE email = ? AND password = ?",
    (email, password),
)

SQLAlchemy ORMを使うと、SQL文字列を組み立てる必要がなくなり、より安全です。

user = db.query(User).filter_by(email=email).first()

公式のFastAPI SQL (Relational) Databases でも、SQLAlchemyを通じたDB操作が標準パターンとして示されています。

偽造可能な認証トークン（Finding 3・8）

レポートの Finding 3 では、トークンに署名検証メカニズムが完全に欠落していることが指摘されています。

The application uses plain base64-encoded tokens in the format base64('user_id:role') with no cryptographic signature, HMAC, or integrity protection. Any attacker can forge a valid token for any user ID and any role purely locally (e.g., echo -n '3:user' | base64).

Tasks APIは base64('user_id:role') という形式のトークンを発行していますが、サーバ側に秘密鍵がなく、署名検証もしていない ため、攻撃者がローカルで echo -n '1:admin' | base64 を打つだけで管理者トークンを偽造できます。

対策は、JWT （JSON Web Token）を使い、サーバ側の秘密鍵で HMAC署名 を付けて発行・検証することです。秘密鍵を知らない攻撃者は payload を改ざんしても署名検証で弾かれます。

import os
from datetime import datetime, timedelta, timezone

import jwt

JWT_SECRET = os.environ["JWT_SECRET"]  # 本番ではSecrets Manager等から取得

def create_token(user: User) -> str:
    payload = {
        "sub": str(user.id),
        "role": user.role,
        "exp": datetime.now(timezone.utc) + timedelta(hours=1),
    }
    return jwt.encode(payload, JWT_SECRET, algorithm="HS256")

def verify_token(token: str) -> dict:
    return jwt.decode(token, JWT_SECRET, algorithms=["HS256"])

JWTライブラリは PyJWT 公式ドキュメント に記載があります。exp クレームを必ず含めてトークンに有効期限を設けることで、漏えい時の影響範囲を時間的に限定できます。

パスワードの平文保存とレスポンスへの露出（Finding 4・7）

サンプルレポートでは、Finding 4（タイトル: IDOR on /api/v1/users/{user_id} - Unauthenticated Access to Any User Profile with Plaintext Passwords）と Finding 7（タイトル: Unauthenticated and Unprivileged Access to Admin User List with Plaintext Passwords）の両方で、レスポンスに平文パスワードが含まれることが指摘されています。Finding 4 の Description には次のように記載されています。

The passwords stored and returned are in plaintext (not hashed), compounding the severity.

Tasks APIは登録時のパスワードを平文のままDBに保存し、さらに APIレスポンスのJSONにも password フィールドを含めて返却 しています。万一DBやレスポンスが漏えいすると、全ユーザのパスワードがそのまま攻撃者の手に渡ります。

対策は2つを必ず両立させます。1つ目は、保存時に bcrypt などの適応的ハッシュ関数でハッシュ化することです。bcryptは計算コストが調整可能で、ブルートフォース攻撃に対する耐性があります。

import bcrypt

def register(email: str, password: str) -> User:
    hashed = bcrypt.hashpw(password.encode(), bcrypt.gensalt()).decode()
    user = User(email=email, password=hashed)
    db.add(user)
    db.commit()
    return user

def login(email: str, password: str) -> User | None:
    user = db.query(User).filter_by(email=email).first()
    if user and bcrypt.checkpw(password.encode(), user.password.encode()):
        return user
    return None

2つ目は、APIレスポンスのスキーマから password を除外 することです。FastAPIでは response_model にPydanticモデルを指定することで、モデルに定義していないフィールドは自動的にレスポンスから除外されます。

from pydantic import BaseModel

class UserResponse(BaseModel):
    id: int
    email: str
    role: str
    # password フィールドはあえて定義せず、レスポンスから除外する

@app.get("/api/v1/users/{user_id}", response_model=UserResponse)
def get_user(user_id: int):
    return db.query(User).filter_by(id=user_id).first()

OWASP Password Storage Cheat Sheet では、現代のパスワードハッシュとして bcrypt / scrypt / Argon2 が推奨されており、平文保存や単純なMD5・SHA-1ハッシュは明確に非推奨とされています。

IDOR と認可チェックの欠落（Finding 4・7・10）

Finding 4 は IDOR と平文パスワード露出を1つにまとめたFindingで、ここでは IDOR の観点を取り上げます（平文パスワードの観点は前述の「パスワードの平文保存とレスポンスへの露出」セクションに記載があります）。レポートの Finding 4 の Description では、認証・認可の両方が完全に欠落していることが次のように指摘されています。

The GET /api/v1/users/{user_id} endpoint enforces no authentication or authorization controls. Any client — whether completely unauthenticated or authenticated as a low-privilege user — can access any user's full profile by manipulating the integer user_id path parameter.

Tasks APIは /api/v1/users/{user_id} で パスパラメータの user_id をそのままDB検索に使って返却 しているだけで、リクエスト元が誰かを確認していません。これは典型的な IDOR（Insecure Direct Object Reference、安全でない直接オブジェクト参照）です。

対策は、すべての保護対象エンドポイントで 2段階のチェック を行うことです。1段階目は 認証（リクエストに有効なトークンが付いているか）、2段階目は 認可（その認証ユーザがリソースにアクセスする権限を持つか）です。

FastAPIではDependsを使って認証処理を共通化し、エンドポイントの先頭で認可チェックを書きます。

from fastapi import Depends, Header, HTTPException

def get_current_user(authorization: str = Header(...)) -> User:
    token = authorization.removeprefix("Bearer ")
    try:
        payload = verify_token(token)  # 前述のJWT検証
    except jwt.PyJWTError:
        raise HTTPException(401, "Invalid token")
    user = db.query(User).filter_by(id=int(payload["sub"])).first()
    if not user:
        raise HTTPException(401, "User not found")
    return user

@app.get("/api/v1/users/{user_id}", response_model=UserResponse)
def get_user(
    user_id: int,
    current_user: User = Depends(get_current_user),
):
    # 認可チェック：自分自身か管理者のみアクセス可能
    if current_user.id != user_id and current_user.role != "admin":
        raise HTTPException(403, "Forbidden")
    user = db.query(User).filter_by(id=user_id).first()
    if not user:
        raise HTTPException(404, "Not found")
    return user

/api/v1/admin/users のような 管理者専用エンドポイント では、current_user.role == "admin" の確認を必ず行います。

@app.get("/api/v1/admin/users", response_model=list[UserResponse])
def admin_list_users(current_user: User = Depends(get_current_user)):
    if current_user.role != "admin":
        raise HTTPException(403, "Admin only")
    return db.query(User).all()

OWASP API Security Top 10 — API1:2023 Broken Object Level Authorization でも、オブジェクトIDを受け取るすべてのAPI操作にオブジェクトレベルの認可チェックを実装すること が原則として明記されています。

対策の優先順位

これら4種類の対策を Tasks API に適用すると、サンプルレポートで Critical / High に分類されているFindingsの大半が解消されます。実務で対応する際は、Findings の重大度の順（Critical → High → Medium → Informational）で着手するのが基本です。Critical の上位には複数の脆弱性が連鎖した攻撃チェーンが含まれていることが多く、チェーンの起点を1つ潰すだけで、連鎖していた複数のFindingsが同時に解消する ケースもあります。本セクションの場合、SQLインジェクションを潰すと、それを起点としていた認証バイパス・トークン取得・権限昇格のチェーンがまとめて成立しなくなります。

組織独自の追加要件（使用してよいライブラリ・ログ出力ポリシーなど）をコードレビューに組み込みたい場合は、次の「参考: 組織セキュリティ要件（Security requirements）の追加」セクションも参照してください。

7. 参考: 組織セキュリティ要件（Security requirements）の追加

ここまでのフェーズではAWS Security Agentが内蔵するセキュリティチェック（一般的な脆弱性・OWASP Top 10）を中心に体験してきました。Security Agentはさらに、組織固有のセキュリティポリシーをカスタム要件として定義し、設計レビュー・コードレビューで自動チェックさせることができます。本セクションは任意の発展課題として、その挙動を体験できる構成です。

7.1 セキュリティ要件（Security requirements）とは

セキュリティ要件は 組織レベル で定義され、全エージェントスペース共通で適用 されます。「使ってよいライブラリ」「ログ出力ルール」「DB接続方式」など、業務ドメインや組織のコーディング規約に合わせた独自ルールを言葉で記述しておくと、AIがレビュー時にそれらへの準拠性も判定してくれます。

7.2 セキュリティ要件の登録

組織独自のルールをAIに守ってもらうには、まずルール自体をSecurity Agentに登録する必要があります。本セクションでは、Tasks API で問題になっていた「f-string で組み立てる生SQL」を構造的に防ぐため、「DBアクセスはORM経由に限定する」というルールを1件登録します。Security Agent コンソールの左メニューから「セキュリティ要件」ページを開き、「カスタムセキュリティ要件」タブに切り替えて、画面右側の「カスタムセキュリティ要件を作成」をクリックします。タブには他に「マネージドセキュリティ要件」（AWSが提供するテンプレート一覧）と「有効なセキュリティ要件」（現在有効化されているもの）がありますが、組織独自の要件を一から定義する場合は「カスタムセキュリティ要件」タブを使います。

登録画面では、上部に「AWS マネージドセキュリティ要件をカスタマイズ - オプション」セクションがあります。AWSが用意するテンプレートを出発点にしたいときはここでテンプレートを選択しますが、本セクションでは一から定義するため未選択のまま進めます。その下の「セキュリティ要件の詳細」セクションに値を入力していきます。

ハンズオンでは、Tasks APIで露呈した f-string で組み立てた cursor.execute 起因のSQLインジェクション を構造的に防ぐ目的で、データベースアクセスを SQLAlchemy などのORM経由に限定する 生SQL禁止 の要件を1つ登録します。以下の値を入力し、画面右下の「セキュリティ要件の作成と有効化」ボタンで保存することで、作成と同時にレビュー対象として有効化できます（左隣の「セキュリティ要件を作成」は作成のみで有効化はしないボタンです）。

保存後、「カスタムセキュリティ要件」タブの一覧に ORM-only database access が表示され、「セキュリティ要件のステータス」列が 「有効化済み」 になっていれば登録完了です。

実務では認証ライブラリの統一・構造化ログによるPII保護など複数の要件を組み合わせて運用しますが、本セクションでは挙動の確認が目的のため、この1件で十分です。

7.3 コードレビュー設定の切り替え

セキュリティ要件を登録しただけでは、コードレビューはそれを評価対象としてくれません。フェーズ2でコードレビュー設定を「セキュリティ脆弱性検出結果」のみで作成しているため、登録した組織要件もレビュー対象に含めるには、エージェントスペースのコードレビュー設定を切り替える必要があります。

エージェントスペース fastapi-sample-app の詳細画面を開き、「コードレビュー」タブ に切り替えます。「コードレビュー設定」セクションの右上にある 「設定を編集」 ボタンをクリックします。

「コードレビュー設定を編集」モーダルが開き、3つの選択肢が表示されます。「セキュリティ要件と脆弱性検出結果」 を選択して 「変更を保存」 をクリックします。

「コードレビュー設定」セクションの 「選択」 が「セキュリティ要件と脆弱性検出結果」に変わっていれば、設定変更は完了です。これで、以降に作成されるPRから組織要件への準拠性チェックも追加で行われるようになります。

7.4 期待される挙動の変化

設定を切り替えたあとに新しくPRを作成すると、Tasks APIに対するコードレビューでは、通常の脆弱性検出に加えて 組織要件への準拠性チェック が動きます。今回登録した要件であれば、app/main.py の cursor.execute による生SQL実行が「ORM-only database access に違反」として、組織要件側の指摘として現れる、という挙動になります。

このように、組織独自のコーディング規約を コードレビューに自動で組み込める ことが、Security Agentを実務で運用する際の大きなメリットになります。認証ライブラリの統一やPII保護など、組織のセキュリティポリシーに合わせて要件を増やしていくことで、AIレビューが守るべきルール集をそのまま組織のガードレールにできます。

8. 不要リソースの削除

ハンズオン完了後、不要なリソースを削除して課金やセキュリティリスクを避けます。AWS Security Agent そのものについては、エージェントスペースを残しているだけでは課金は発生しません（設計レビュー・コードレビューはプレビュー相当の無料クォータ内で利用でき、ペネトレーションテストは実行時のみ task-hour 課金されるため）。一方で、フェーズ3でデプロイした Tasks API のインフラ（EC2・ALB・CloudFront等）は継続課金される ため、検証が終わったら 必ず削除 してください。

8.1 エージェントスペースの削除

エージェントスペース自体に課金は発生しませんが、検証で作成したワークスペースをそのまま残しておくと、後で別の本物のリポジトリ用途に使い回そうとしたときに混乱を招きます。検証用と分かるエージェントスペースは、用が済んだ時点で削除しておくのが安全です。Security Agent コンソールの左メニューから 「エージェントスペース」 を開きます。一覧で fastapi-sample-app を選択し、画面右上の 「エージェントスペースを削除」 をクリックします。エージェントスペース内のレビュー履歴・ペネトレーションテスト設定・検出結果に加えて、GitHubリポジトリとの連携も合わせて解除 されるため、別途連携解除の操作は不要です。

8.2 カスタムセキュリティ要件の削除（任意）

「参考: 組織セキュリティ要件」セクションで登録した ORM-only database access は 組織レベルの設定 として保存されているため、エージェントスペースを削除しても残ります。残しておいても課金には影響しないので、本番運用に向けて要件を育てていきたい場合はそのまま残して構いません。完全に片付けたい場合は、以下の手順で削除します。

Security Agent コンソールの左メニューから 「セキュリティ要件」 を開き、「カスタムセキュリティ要件」タブ に切り替えます。ORM-only database access の チェックボックスを選択 したうえで、画面右側の 「アクション」プルダウン から 「削除」 をクリックします。

カスタムセキュリティ要件の一覧から該当行が消えていれば削除完了です。

8.3 Tasks API環境の削除（必須）

ペネトレーションテスト用にデプロイしたTasks API環境（CloudFront・ALB・EC2など）は、そのままにしておくと料金が発生し続けます。検証が終わったら必ず削除してください。

AWSマネジメントコンソールで CloudFormation を開き、スタック一覧から tasks-api-handson を選択して、画面右上の 「スタックを削除」 をクリックします。スタックが完全に削除されると、VPC・ALB・EC2・CloudFrontディストリビューションなどすべてのリソースが一括で削除されます。

スタックのステータスが DELETE_COMPLETE になったら、Tasks API環境の削除は完了です。

8.4 Privateリポジトリの削除（任意）

フェーズ2で作成した tasks-api-handson リポジトリは、ハンズオン用のため後片付けの観点では削除しておくのが望ましいです。継続して別の検証に使う場合はそのまま残しても構いません。GitHubの該当リポジトリの Settings → Danger Zone → Delete this repository から削除できます。

9. まとめ

この章では、AWS Security Agentを使った次世代の統合セキュリティレビューを体験しました。

• AWS Security Agentを初期セットアップし、最初のエージェントスペースを作成できる
• 事前準備でダウンロードしたzipを起点に、設計書・ソースコード・稼働環境の3つを同じアプリケーション（Tasks API）で一貫して扱える
• 設計ドキュメントをアップロードし、AIが設計段階でセキュリティ問題を指摘する設計レビューを組み込める
• GitHub連携とコードレビュー設定により、プルリクエストに対してAIが自動でセキュリティレビューを行う運用にできる
• Tasks APIをCloudFormationでデプロイし、ドメイン検証を経てペネトレーションテストを有効化することで、稼働中のアプリケーションに対してAIエージェントによるペネトレーションテストを実行できる
• SQLインジェクション・IDOR・認証バイパス・認可の不備などの脆弱性を、実際に攻撃を再現する形で検出できる
• 単独では中程度のFindingsを、Security Agentのコンテキスト横断分析によって致命的な攻撃チェーンとして扱える
• エージェントスペース・Tasks API環境の削除まで含めて、不要リソースを後片付けできる

本講座の前半で扱ったBandit（SAST）・OWASP ZAP（DAST）・Checkov（IaC scanning）などの個別ツールは、それぞれの役割に特化した強力なツールです。一方、AWS Security AgentはこれらをAIエージェントに統合した次世代のセキュリティプラットフォームで、特に設計書・コード・稼働環境を1つのアプリケーションコンテキストとして横断分析できる 点と、ペネトレーションテストのコストを大幅に下げる点で革新的です。従来は外部ベンダ依頼で1回数百万円が相場でしたが、AWS Security Agentでは $50/task-hour の従量課金（小〜中規模のAPIなら1回あたり$400〜$600程度）で実行できます。実運用ではコスト管理（テストの実行頻度・スコープ設定）と従来ツール（Bandit・ZAP等）との併用戦略が重要になります。

これでDevSecOps講座は一通り終了です。ここまでで、Shift Leftの考え方を土台に、SAST・SCA・DAST・IaCスキャン・コンテナ・ランタイム・AI統合レビューまで、開発から運用までを多層的にカバーするDevSecOpsの基本を身につけました。