こんにちは。 アプリケーションサービス本部、DevOps担当の兼安です。 最近、SNS上でAIによるGitHubリポジトリの誤操作を見かけるようになりました。 怖いですね。 ということで、今回はGitHubのブランチ保護と、 各種AIエージェントによるパーミッションでgit pushを禁止する方法を紹介します。 なお、本記事ではAIエージェントとして、Claude CodeとKiro CLIを取り上げます。 AIによるGitHubリポジトリの誤操作とは Gitのおさらい ブランチの意味と、直接git pushしてはいけないブランチ Gitのアップロードは2段階、git commitとgit p…

はじめに 金融IT本部 3年目の坂江 克斗です。 re:Invent 2025 で公開されたFrontier Agentの1つとして AWS Security Agent が発表され、3月には AWS Security Agentのペネトレーションテストが一般公開 されました。 AWS Security Agentは、開発フローにセキュリティを統合する DevSecOps において、その「Sec（セキュリティ）」を担うようなサービスです。 本記事では、AWS Security Agent 全体の使用感を、コンソール操作とCICDへの組み込みイメージも含めて紹介します。 ※本記事は2026年6月時点の情報です。 本記事執筆時の2026年6月17日に、 AWS Continuum が発表され、AWS Security Agent のペネトレーションテスト・コードスキャン機能は「Continuum for penetration testing」「Continuum for code scanning」（プレビュー）として Continuum の一部にもなりました。本記事の操作内容は引き続き参考になりますが、AWS Security Agent の名称や提供形態は今後変わっていく可能性があります。 はじめに Frontier Agent とは AWS Security Agent の概要 全体像 コスト クォータ データ保護 テスト・レビュー コンソール画面 実際に試してみる 管理者側の設定手順 AWS Security Agent アプリケーションの作成・エージェントスペースの作成 【AWS Security Agent アプリケーションが既に存在する場合】エージェントスペースだけの作成 セキュリティエージェントを使用可能な開発者の登録 ターゲットドメインの登録 リポジトリの統合 セキュリティ要件 コードレビューの有効化 ペネトレーションテストの有効化 開発者用コンソールの確認 開発側の実行手順 設計レビューの実行 コードレビューの実行 脅威モデルの実行 ペネトレーションテストの実行 レポートの確認 デザインレビュー 脅威モデル コードレビュー・ペネトレーションテスト CI/CDへの組み込み CLIコマンドの基本構造 共通： AWS 認証（OIDC） develop マージ時： コードレビュー stg デプロイ完了後： 軽量ペンテスト（DAST・対象を絞る） リリース時 / 定期： フルスコープのペネトレーションテスト 設計ドキュメント更新時： デザインレビュー（脅威モデリング） まとめ おわりに Frontier Agent とは 少し前になりますが、2025年のre:Inventにて「フロンティアエージェント（Frontier Agent）」という新しいカテゴリのAIエージェントが発表されました。 フロンティアエージェント とは、 自律的に動作する開発チームの拡張機能 として位置づけられたAIエージェントです。 個々のタスクをサポートする従来の AI アシスタントとは異なり、フロンティアエージェントはチームの拡張機能として機能し、多様なユースケースにわたって包括的な成果をもたらします。 AWSが定義するフロンティアエージェントには、以下の3つの特徴があります。 自律的 — 人間が常に介入しなくても、独立して動作します スケーラブル — 大規模なスケーリングにより、複数タスクを同時実行します 長時間実行 — 24時間365日、継続的に動作できます 2025年re:Inventで発表されたフロンティアエージェントは以下の3種類です。 エージェント 役割 AWS Security Agent 仮想セキュリティエンジニア。設計・コード・稼働中アプリを横断してセキュリティを担保する AWS DevOps Agent 仮想SREメンバー。インシデントのトリアージや根本原因分析、復旧を自律的に行う Kiro autonomous agent 仮想開発者。仕様書からコード生成・テスト・デプロイまでを担う 中でも今回は、インフラ構築の文脈で特に気になった AWS Security Agent を調査しましたので、その仕組みをまとめます。 去年のre:Invent直後に宮崎さんが AWS re: Invent2025で登場した3つのFrontier Agentsの1つである「AWS DevOps Agent」を触りつつ、概要について整理してみる。 という記事を書いていますので、気になる方はぜひご覧ください。 AWS Security Agent の概要 全体像 AWS Security Agentは機能としては、 SAST（Static Application Security Testing）・ DAST（Dynamic Application Security Testing） ・ペネトレーションテスト を単一のエージェントに統合し、 設計ドキュメントからソースコード・IaC・脅威モデルまでを取り込んでアプリの全体像（コンテキスト）を把握 することで、個々の脆弱性の連鎖まで含めた精度の高い検出と実用的な修復提案を実現するサービスです。 Security Hub/GuardDuty/Inspector などによる従来の事後的なセキュリティ調査では、本番デプロイ後に問題が見つかるため、設計やコードに起因する脆弱性ほど手戻りが大きくなりがちです。こうした背景から、 開発からデプロイまでのフローの早い段階にセキュリティのチェックを寄せる「シフトレフト」や、それを開発プロセスに組み込む「 DevSecOps 」 が重視されるようになってきました。AWS Security Agentは、この考え方を踏まえたサービスとなります。 DevOpsによって開発サイクルが高速かつ高頻度で回るようになった一方、セキュリティが従来どおりの体制のままでは開発スピードに追いつけません。この課題に対して生まれたのが DevSecOps で、開発初期からセキュリティを考慮するシフトレフトの動きを取りつつ、DevOpsの効率性を損なわないようにセキュリティレビュー等を自動化に組み込むことが重視されます。 AWS Security Agentは、大まかに以下の構成となっています。 設計レビュー（デザインレビュー） ・ コードレビュー ・ 脅威モデリング ・ ペネトレーションテスト という4つの作業を行うことができ、各レビュー・テストにおいては、管理側・開発側でコンソールを切り替えることができます。 そのため、開発側は作業中に管理側を意識する必要がなく、不要に管理設定を変更してしまうことを防げます。 コスト コストについては、現在のところ ペネトレーションテストの料金 のみが公開されており、1タスク時間あたり50ドル、かつ初回は2か月間・最大200タスク時間分が無料となっています。 AWS 公式ドキュメントによると、 平均的なアプリケーションテストには約 24 タスク時間かかり、包括的な侵入テストと修復にかかる費用は通常 1,200 ドル の見込みとのことです。 このタスク時間は、ペネトレーションテスト実行中にタスクごとに独立してエージェントが稼働していた場合、それぞれのエージェントの稼働時間を合算したものがそのままタスク時間に換算されます。 クォータ Service Quotas より、各レビューやテスト、連携可能なリソース数などに上限が設定されています。ただし、AWSサポート経由で申請することで上限を変更できます。 データ保護 アップロードするドキュメントなどのデータは、既定でAWSマネージドキーにより暗号化され、任意でカスタマーマネージドキー（CMK）を指定して自社で鍵を管理することも可能です。 S3・CloudWatch Logs・Secrets Managerを連携する際も、CMKで暗号化したものを渡して使用できます （各リソースのKMSキーポリシーと、サービスロールへの復号権限の設定が必要）。 ただし、 CMKを指定できるのはリソース（エージェントスペースや統合）の作成時のみで、既存リソースへの後付けや鍵の差し替えはできない点に注意が必要です （CMKで運用する場合はリソースの再作成が必要）。 テスト・レビュー 各テスト・レビューの内容を紹介します。詳細な設定方法や実際の動作については次の章をご参照ください。 なお、ポイントについてはドキュメントの内容に加えて私の解釈も含むため、セキュリティエンジニアの方のご意見もぜひ伺いたいです。 項目 概要 ポイント（普通のAI・既存ツールとの差分） 設計レビュー 設計書などのドキュメントを、組織で定義したセキュリティ要件（AWSマネージド／カスタムのガイドライン）に照らして自動レビューし、コードを書く前の段階で指摘。数分～数十分程度で完了。 セキュリティチームが基準を一元的に定義し、開発者側は変更・迂回できない（責務の分離）。組織横断で同じ基準を強制でき、結果が監査ログ・レポートとして残る。従来のSASTと異なり、（アプリ実行時のコンテキストを含まない）パターンマッチングではなく、 アプリの実際の動作・コンテキストを推論して脆弱性を検出 。 コードレビュー 連携したリポジトリやS3のコードを、セキュリティ要件に照らしてレビュー。フルリポジトリ／差分を選択でき、PRへのレビューコメントや自動修正PRまで対応。数分～数十分程度で完了。 設計レビューと同様。Gitにも統合でき、差分レビューなど使いやすい構成。 脅威モデル 攻撃者視点で潜在的な脅威を洗い出して分析。コード以外の信頼境界・権限設計・外部連携なども含め、広範な攻撃経路を整理。数分～数十分程度で完了。 実装上の問題を中心に見るコードレビューと異なり、アーキテクチャ全体のリスクを俯瞰。 ペネトレーションテスト （ 副作用を考慮し、検証環境での実施を推奨 ）稼働中のアプリに対し、ソースコードやドキュメントソースをもとにした多段階の攻撃シナリオで脆弱性を検出。再現手順・PoC・CVSS・修正PRまで提示。数時間～数十時間程度で完了。 従来の DAST と異なり、ブラックボックス的なアプローチではなく、 ソースコードやAPI仕様、設計書をもとにアプリの詳細なコンテキストを構築して検証 。テスト項目の設定によりスコープ調整も可能。 コンソール画面 操作するインターフェースは2層に分かれています。テストのスコープ・セキュリティ要件・リポジトリ統合などを設定する管理者コンソール（AWSマネジメントコンソール内）と、実際にレビューやテストを実行する開発者向けのWebアプリです。 開発者向けのWebアプリは、明示的にアクセス権限を設定でき、運用しやすい構成となっています。 実際に試してみる 本記事では、管理者側・開発者側それぞれの操作方法を紹介しながら、基本的な使用方法について共有します。 その他の詳細な設定について参照が必要な場合は、 AWS Security Agent ： User Guide をご参照ください。 前提として以下のリソースを準備します。 ドキュメント 設計書やAPI仕様（OpenAPIまたはSwagger）等 コードソース GitHub リポジトリ（今回はこちらで検証） S3バケット内のZIPファイル セキュリティ要件 上記のドキュメントやコードソースに対して準拠させたいガイドラインやポリシー ペネトレーションテスト用のエンドポイント情報（ 本番ではなくステージング環境を推奨 ） ターゲット情報（ 外部APIや決済処理、データの削除・更新等の副作用を伴うエンドポイントは除外 ） ドメイン パス VPC内のプライベートなアプリケーションの場合（Security Agent自身がENIを使用してアクセス） VPC ID サブネット ID セキュリティグループ ID アプリケーション接続時に認証情報が必要な場合 静的な認証情報（平文 or Secrets Managerシークレット） 動的な認証情報の生成方法をまとめたプロンプト Security Agent自体の運用管理 CloudWatch ロググループ（コンソールから作成する場合は自動作成されるため任意） IAM サービスロール（コンソールから作成する場合は自動作成されるため任意） KMSキー（デフォルトはAWSマネージドキーで管理されるため任意） 開発者に対応する IAM Identity Center のユーザ（Security Agentを使用可能なユーザを明示的に指定） 管理者側の設定手順 AWSコンソールのAWS Security Agentの画面より、管理者側の設定を行います。 AWS Security Agent アプリケーションの作成・エージェントスペースの作成 各レビュー設定に入る前に、AWSコンソールから全体で必要な設定をしておきます。 Security Agentのコンソール画面に遷移したら、「AWS Security Agentをセットアップ」ボタンを押下します。 AgentSpaceの設定を入力しつつ、AWSマネージドキーではなく、CMK（カスタマーマネージドキー）でデータを保護したい場合には、「Customize encryption settings (advanced)」チェックボックスにチェックを入れ、任意のCMKを紐付けてください。 タグについては、エージェントスペースタグがエージェントスペースに付与されるタグ、アプリケーションタグがAWS Security Agentアプリケーション自体に付与されるタグとなります。 また、 IAM Identity Centerもここで紐づくため、インスタンスを再作成すると連携が切れてしまう点に注意が必要です。（コンソールやCLI経由での更新不可です） 完了後、AWS Security Agent アプリケーションとエージェントスペースが作成されます。 【AWS Security Agent アプリケーションが既に存在する場合】エージェントスペースだけの作成 既にAWS Security Agentアプリケーションを作成済みの状態で、エージェントスペースのみ作成する場合は以下のように作成します。 Security Agentのコンソール画面に遷移したら、「最初のエージェントスペースを作成」ボタンを押下します。 AWSマネージドキーではなく、CMK（カスタマーマネージドキー）でデータを保護したい場合には、「Customize encryption settings (advanced)」チェックボックスにチェックを入れ、任意のCMKを紐付けてください。 作成画面の入力後、「作成」ボタンを押下します。 セキュリティエージェントを使用可能な開発者の登録 作成したエージェントスペース画面のウェブアプリタブにおいて、「ユーザの追加」を押下します。 IAM Identity Centerで設定したユーザーを選択し、「ユーザーを追加」ボタンを押します。 画面遷移後、ユーザーが追加されていることを確認できます。 ターゲットドメインの登録 サイドバーの「ターゲットドメイン」を押下し、ターゲットドメインのページから「ドメインを追加」ボタンを押下します。 ペネトレーションテストの対象となるドメイン・検証方法を選択し、「ドメインを追加」ボタンを押下します。 今回は検証方法としてDNS TXTレコードを指定しました。その他のHTTPルートやプライベートVPCの検証については「 Managed target domains used for penetration testing」 をご参照ください。 ターゲットドメインの追加完了後、「ワンクリック検証」を押下します。レコードの追加も含めマネージドに対応してくれるので、そのまま進めます。 検証が完了すると、ステータスが検証済みになります。 リポジトリの統合 サイドバーの「統合」から、「統合の追加」ボタンを押下します。今回はGitHubを選択して進めていきます。 設定画面に遷移したら、ステップ1より順に設定します。 ステップ2の「GitHubでAWS Security Agentを開く」を押下すると、GitHubアプリのインストール画面に遷移するのでインストールします。 この際、連携するリポジトリをアカウント内すべてにするか、特定のリポジトリに限定するかを選択できます。 インストールの完了後、ステップ3で認証するボタンを押下します。「認証が成功しました」という表示が出ることを確認します。 最後にステップ4で、登録名・アカウントタイプ・CMKによる暗号化を設定したら、「接続」ボタンを押下して完了です。 セキュリティ要件 コンソールサイドバーのセキュリティ要件より、マネージドまたはカスタムのセキュリティ要件を設定することができます。 セキュリティ要件は、設計レビューやコードレビューの際のガイドラインとなる設定であり、各セキュリティ要件項目と、それをまとめたパックの単位で管理を行います。 マネージドセキュリティ要件パックについては、 AWS managed security requirement packs またはコンソールから各設定値をご参照ください。 デフォルトではASA Base Packのみ有効化されています。 カスタム設定については、「Create security requirements pack」ボタンを押下してパックを作成した後に、パック内でセキュリティ要件を個々に設定します。 セキュリティ要件パックの作成後、セキュリティ要件の追加時には、手動での入力またはドキュメントを読み込ませて自動生成する方法を選ぶことができます。 マニュアル設定 の場合は、以下に示すように、条件を適用するシナリオ、具体的な違反内容、修正方法の提示について入力が必要となります。 ドキュメントをアップロードして自動生成する場合は、ファイルサイズにもよりますが、60KB程度のmdファイルを読み込ませて、数分程度で20個のセキュリティ要件が生成されました。 ただし、注意点として、 https://docs.aws.amazon.com/ja_jp/securityagent/latest/userguide/security-requirements.html にあるとおり、既存の要件を置き換えることになる点に注意が必要です。 Uploading new source documents regenerates all requirements for the pack. Any existing requirements, including ones you added manually, are replaced. コードレビューの有効化 コードレビューを有効にするボタンを押下して進めます。 接続された統合項目の追加ボタンを押下し、先ほど連携したGitHubアカウントを選択します。 今回は使用しませんが、S3バケットもコードの保存先として参照可能です。 アカウント内のリポジトリを選択し、「次へ」ボタンを押下します。 以下の設定を確認し、「接続」を押下します。 コードレビューコメント：PR作成時にレビューコメントを追加してくれる許可 PR修正：レビューやテスト後に脆弱性の箇所を自動でPR作成する許可 完了すると、コードレビューの設定画面に戻り、統合が追加されたことが確認できます。 その他の項目も確認し、「次へ」ボタンを押下します。 オプション設定画面に遷移したら、CloudWatchログとサービスロールを設定します。これらは事前に準備したもの、もしくは入力を更新せずにマネージドに作成されるものも使用可能です。設定ができたら、保存を押下します。 エージェントスペース画面に戻ると、脅威モデルについてもセットで有効化されていることが確認できます。 ペネトレーションテストの有効化 最後にペネトレーションテストの有効化ボタンを押下します。 先ほど設定したターゲットドメインを選択し、「次へ」ボタンを押下します。 ターゲットドメインが検証済みであることを確認し、「次へ」ボタンを押下します。 以下の設定項目について確認し、入力が完了したら保存を押下します。 VPC：VPC内でプライベートなエンドポイントを叩く場合など、Security AgentがVPC内のENIからターゲットにアクセスする際の設定 VPC、サブネット、セキュリティグループ CloudWatchログ：ログの出力先、任意 シークレット：テスト打鍵時にログインなどの認証情報を保存しておくために使用 Lambda関数：動的な認証情報生成用に独自デプロイしたものがあれば指定 Lambdaがない場合でも、テスト実行時のプロンプトでカバー可能かどうかは要検討 S3バケット：ペネトレーションテスト実行時にアプリケーションの構成などを学習するためのリソースとして使用可能 全項目が準備完了のステータスであることを確認して完了です。 開発者用コンソールの確認 エージェントスペース画面において、ウェブアプリケーションの項目から開発者用のコンソール（レビューやテストを実行する場所）を開くことができます。 管理者アクセスの場合は「管理者アクセス」ボタンを押下し、直接エージェントスペースに対応するコンソールに移動します。 エージェントウェブアプリのURLよりアクセスする場合は、紐付けたIAM Identity Centerユーザでログインしたのちに、そのユーザが使用可能なエージェントスペースの一覧が表示され、そこから指定のエージェントスペースに遷移する形となります。 以上で管理者側の設定は完了です。次に、実際にテストを実行します。 開発側の実行手順 開発者用のコンソール画面より、開発者側の操作（レビュー・テスト）を行います。 設計レビューの実行 ホーム画面から「設計レビューを作成する」を押下し、レビュー対象のファイルをアップロードして、「開始する」ボタンを押下します。 デザインレビューが進行中となります。 完了すると、コンソールからそのまま実施結果を確認することができます。 「レポートをダウンロード」ボタンを押下するとレポートが出力されます。レポートの詳細については、後の章でまとめて紹介いたします。 コードレビューの実行 ホーム画面から「コードレビューを作成する」を押下し、以下の項目を設定して、「作成する」ボタンを押下します。 ソース：コードソースを選択。今回は先ほど設定したGitHubリポジトリを設定 サービスロール：管理者画面で設定したサービスロールを選択 CloudWatchロググループ：未入力で自動生成されます 自動コード修正：有効にするとレビュー結果に応じてPRを自動作成します 作成したコードレビューを押下します。 「レビューを開始する」ボタンを押下し、コードレビューを開始します。 ただし、プルダウンから差分コードレビューも選択可能です。2回目以降、頻繁に回す場合は差分レビューが推奨されると考えられます。（毎回フルリポジトリレビューを実行するとコストに響いていく想定） コンソールから結果を確認することができます。 「レポートを生成」ボタンを押下するとレポートが出力されます。レポートの詳細については、後の章でまとめて紹介いたします。 脅威モデルの実行 ホーム画面から「脅威モデルを作成する」を押下し、以下の項目を設定して、「脅威モデルを作成する」ボタンを押下します。 リポジトリ：先ほど設定したコードソースを選択 機能仕様書：ドキュメントをアップロード サービスロール：管理者画面で作成したサービスロールを選択 CloudWatchロググループ：未入力で自動生成されます 設定完了後、「実行を開始する」ボタンを押下します。 実行結果についてはコンソールから取得できます。 「レポートを生成」ボタンを押下するとレポートが出力されます。レポートの詳細については、後の章でまとめて紹介いたします。 ペネトレーションテストの実行 ホーム画面から「ペネトレーションテストを作成する」を押下し、以下の項目を設定して、「次へ」ボタンを押下します。 ターゲットや除外対象を調整することで、テストスコープを大まかに調整することができます。 ターゲットURL：検証済みのドメインをもとにURLを入力 リスクタイプを除外する：テストで検証しなくてもよい項目を選択し除外可能 範囲外のURL：テストでアクセスしてほしくないURLを入力（外部APIや決済処理、データの削除・更新などの副作用を伴うエンドポイント等） アクセス可能なURL：テスト中に攻撃対象ではないが、アクセスを許可するURLを入力 カスタムHTTPヘッダ：静的なヘッダのキーと値を設定（動的な設定がしたい場合は、以降の手順で対応） サービスロール CloudWatchロググループ VPCリソースの設定画面に遷移しますが、今回は設定項目がないため「次へ」ボタンを押してスキップします。 管理者画面で設定していた場合は、VPC、サブネット、セキュリティグループを設定可能です。 認証リソースの設定画面に遷移しますが、今回は設定項目がないため「次へ」ボタンを押してスキップします。 認証情報についてはシークレットまたは平文での静的情報が入力可能なほか、エージェントスペースのログインプロンプトに動的な認証方法に関する記載をすることで、動的な認証にも対応できます。 実際に、動的にトークンを生成してカスタムヘッダに載せる必要があるアプリで動作を確認できました。 その他の設定画面において、以下を設定し、「ペネトレーションテストモデルを作成する」ボタンを押下します。 リソース：コードソースなどを設定 自動コード修正：有効化するとペネトレーションテストの結果に応じてPRを自動作成 検出結果のパーソナライゼーション（ オンオフでの差分未確認 ） リソースを可能な限りクリーンアップ（ オンオフでの差分未確認 ） 作成後、「実行を開始する」ボタンを押します。 実行結果についてはコンソールから取得できます。 テストの取得結果数が少ないのは、実行中に裏側で呼び出しているBedrockの存在に気づき、コスト懸念のため途中で中止したためです。 レポートの確認 デザインレビュー デザインレビューについては、「レポートをダウンロード」からCSV形式でレポートを取得できます。 デザインレビューは手動でファイルを読み込ませる形式で自動修正等もないため、このCSVを手元のAIエージェントに読み込ませて修正することを想定しています。 脅威モデル 脅威モデルの場合は、「レポートを生成」ボタンを押下すると、レポートをPDF形式で取得することができます。 体裁（抜粋） 構成 Introduction 脅威モデルの対象、実施日、検出された脅威件数、重大度の内訳 System Overview 対象システムの目的、機能、アーキテクチャ、主要コンポーネントの説明 Configuration 脅威モデルに使用したスコープ文書、連携リポジトリ、S3ソース、ドキュメントなどの設定情報 Threats 実際に検出された脅威シナリオの一覧 Detailed Threats 各脅威シナリオに対する攻撃者、攻撃が成立するための前提条件、具体的な攻撃方法、攻撃成功時の影響、脅威の根拠、脅威の判断に紐づく構成箇所 System Overview章では設計書やコードから、アプリの構成に関する洞察がかなり細かく記載されており、セキュリティ上のリスクを多角的に把握する上で非常に有用であると感じます。 コードレビュー・ペネトレーションテスト 同様に、コードレビューやペネトレーションテストの場合は、「レポートを生成」ボタンを押下すると、レポートをPDF形式で取得することができます。 体裁（抜粋） 構成 Report Filters Applied このレポートに含めるリスクレベル、信頼度、ステータスなどの抽出条件 Executive Summary テスト対象、実施日、検出された脆弱性件数、重大度の内訳 Scope ペネトレーションテスト：対象URL、対象外URL、利用した認証情報 コードレビュー：対象リポジトリ、S3バケット Methodology AWS Security Agent がどのような流れ・観点でテストを実施したかの説明 ペネトレーションテストの場合は、表形式でXSS、SQL Injection、SSRF、Path Traversalなど、実際に実施されたテスト項目の一覧を記載 Findings 実際に検出されたセキュリティ指摘の一覧 Detailed Findings 各セキュリティ指摘に対する、概要、再現手順、 CVSS（Common Vulnerability Scoring System）評価 の根拠、推奨修正方針、修正対応PR ペネトレーションテストの結果におけるMethodology章では、例えば私のサービスではバックエンドにDynamoDBやSQLを使用している点から、それらの要素を突くような攻撃を実施した旨が記載されていました。これは、学習リソースとしてGitHubリポジトリを与えたために、IaCで管理しているリソースやアプリケーションロジックを総合して攻撃方法を検討していることが確認できました。 まさに、 AWS Security Agent のオンデマンドペネトレーションテストの一般提供を開始 で紹介されていたような、 アプリケーションコンテキストを追加して精度と検出の深度を向上 させるという面が見られたのではないかと感じます。 また、今回はコードレビューとペネトレーションテストの際にリポジトリへの修正PRを許可していることから、自動でPRを立てていました。 実施理由から変更内容、サマリまでが簡潔にまとめられていることがわかります。コードの質に関しては、今回はそこまで複雑なアプリではないこともあり、特に気になる点はなかったと感じますが、ぜひ皆さんの使用時に確認していただければと思います。 CI/CDへの組み込み AWS Security Agent は、CodePipeline 等の CI/CD や定期的な管理タスクとして実行させることが可能で、 AWS CLI / API 経由でジョブを起動できます。 今回は、GitHub Actions での使用イメージを記載します。以下は、デザインレビュー・コードレビュー・ペネトレーションテストを、大まかに GitHub Actions に組み込んだ場合のイメージです。 タイミング 実行するもの 性質 develop マージ リポジトリ全体のコードレビュー 軽量・低コスト・高頻度 main マージ stg へ反映（テストは伴わないデプロイトリガー） — stg デプロイ完了後 軽量ペンテスト（対象を絞る） 中コスト・中頻度 リリース時 / 定期 フルスコープのペンテスト 高コスト・低頻度 設計ドキュメント更新時 デザインレビュー 随時 CLIコマンドの基本構造 AWS Security Agent の各機能は、以下の流れで実行します。AWS Security Agent 関連リソースはあらかじめコンソールまたは create コマンドで定義しておき、CI/CD からは名前を基に list-* コマンドでIDを取得し start-*-job で起動するのが基本です。 機能 起動コマンド 主な必須引数 コードレビュー aws securityagent start-code-review-job --agent-space-id / --code-review-id ペネトレーションテスト aws securityagent start-pentest-job --agent-space-id / --pentest-id デザインレビュー（脅威モデリング） aws securityagent start-threat-model-job --agent-space-id / --threat-model-id 例えばペネトレーションテストの起動は、コンソールから設定した場合は名前を元に以下のようになります。Agent Space やペンテスト定義の実IDは list-* 系コマンドで name / title を条件に取得し、 start-pentest-job に渡します。 $ AGENT_SPACE_ID=$(aws securityagent list-agent-spaces \ --query "agentSpaceSummaries[?name=='$AGENT_SPACE_NAME'].agentSpaceId | [0]" \ --output text \ --region ap-northeast-1) $ PENTEST_ID=$(aws securityagent list-pentests \ --agent-space-id "$AGENT_SPACE_ID" \ --query "pentestSummaries[?title=='$PENTEST_NAME'].pentestId | [0]" \ --output text \ --region ap-northeast-1) $ aws securityagent start-pentest-job \ --agent-space-id "$AGENT_SPACE_ID" \ --pentest-id "$PENTEST_ID" \ --region ap-northeast-1 start-pentest-job は pentestJobId と status （ IN_PROGRESS / COMPLETED / FAILED など）を返します。短時間で完了するコードレビューやデザインレビューは、この status をポーリングして完了を待つ構成にできます。一方、数時間〜数十時間かかるペネトレーションテストは、GitHub Actions の実行時間制限（後述）の都合から、起動のみ行う非同期キック構成とします。 以下では、各フェーズで実行する workflow の YAML ファイル例を示します。なお、いずれの例も Agent Space 名や各リソース名（ title ）、AWS 認証情報（OIDC ロール等）を GitHub の Secrets / Variables に登録している前提です。リソース ID は workflow 内で list-* から動的に解決するため、ID 自体は Variables に持ちません（コンソール側で再作成された場合の追従が楽になります）。 共通： AWS 認証（OIDC） 各 workflow で共通して使う、OIDC による AWS 認証部分の例です。長期のアクセスキーを GitHub に保存せず、フェデレーションでロールを引き受ける構成にしています。 permissions : id-token : write contents : read steps : - name : Configure AWS credentials (OIDC) uses : aws-actions/configure-aws-credentials@v4 with : role-to-assume : ${{ secrets.AWS_SECURITY_AGENT_ROLE_ARN }} aws-region : ap-northeast-1 develop マージ時： コードレビュー develop への push（マージ）をトリガーに、リポジトリ全体のコードレビューを起動します。高頻度で回すため、軽量・低コストなレビューを想定しています。 # .github/workflows/code-review.yml name : security-agent-code-review on : push : branches : [ develop ] permissions : id-token : write contents : read jobs : code-review : runs-on : ubuntu-latest env : AWS_REGION : ap-northeast-1 AGENT_SPACE_NAME : ${{ vars.AGENT_SPACE_NAME }} CODE_REVIEW_NAME : ${{ vars.CODE_REVIEW_NAME }} steps : - name : Configure AWS credentials (OIDC) uses : aws-actions/configure-aws-credentials@v4 with : role-to-assume : ${{ secrets.AWS_SECURITY_AGENT_ROLE_ARN }} aws-region : ${{ env.AWS_REGION }} - name : Resolve resource IDs id : resolve run : | AGENT_SPACE_ID=$(aws securityagent list-agent-spaces \ --query "agentSpaceSummaries[?name=='$AGENT_SPACE_NAME'].agentSpaceId | [0]" \ --output text) CODE_REVIEW_ID=$(aws securityagent list-code-reviews \ --agent-space-id "$AGENT_SPACE_ID" \ --query "codeReviewSummaries[?title=='$CODE_REVIEW_NAME'].codeReviewId | [0]" \ --output text) if [ -z "$AGENT_SPACE_ID" ] || [ "$AGENT_SPACE_ID" = "None" ] \ || [ -z "$CODE_REVIEW_ID" ] || [ "$CODE_REVIEW_ID" = "None" ] ; then echo "Failed to resolve IDs: AGENT_SPACE_ID=$AGENT_SPACE_ID CODE_REVIEW_ID=$CODE_REVIEW_ID" exit 1 fi echo "agent_space_id=$AGENT_SPACE_ID" >> "$GITHUB_OUTPUT" echo "code_review_id=$CODE_REVIEW_ID" >> "$GITHUB_OUTPUT" - name : Start code review job id : start run : | JOB_ID=$(aws securityagent start-code-review-job \ --agent-space-id "${{ steps.resolve.outputs.agent_space_id }}" \ --code-review-id "${{ steps.resolve.outputs.code_review_id }}" \ --query 'codeReviewJobId' --output text) echo "job_id=$JOB_ID" >> "$GITHUB_OUTPUT" echo "Started code review job: $JOB_ID" - name : Wait for completion run : | JOB_ID="${{ steps.start.outputs.job_id }} " AGENT_SPACE_ID=" ${{ steps.resolve.outputs.agent_space_id }} " for i in $(seq 1 60); do STATUS=$(aws securityagent batch-get-code-review-jobs \ --agent-space-id "$AGENT_SPACE_ID" \ --code-review-job-ids "$JOB_ID" \ --query 'codeReviewJobs[0].status' --output text) echo "status=$STATUS" case "$STATUS" in COMPLETED) echo "Code review completed" ; exit 0 ;; FAILED|STOPPED) echo "Code review did not succeed: $STATUS" ; exit 1 ;; esac sleep 30 done echo "Timed out waiting for code review" ; exit 1 stg デプロイ完了後： 軽量ペンテスト（DAST・対象を絞る） main マージ後の stg デプロイ完了を受けて、対象を絞った軽量なペネトレーションテストを実行します。 ペネトレーションテストは数時間〜数十時間かかる場合があり、GitHub ホストランナーの 1 ジョブ最大 6 時間という実行時間制限を超える恐れがあります。そのため、ここでは 起動のみを行い、完了は待たない（非同期キック） 構成とします。テストの進捗・結果は、コンソールや EventBridge 通知などジョブの外で確認する想定です。 # .github/workflows/pentest-light.yml name : security-agent-pentest-light on : workflow_run : workflows : [ "deploy-stg" ] # stg デプロイ workflow 名 types : [ completed ] permissions : id-token : write contents : read jobs : pentest-light : # デプロイが成功したときだけ実行 if : ${{ github.event.workflow_run.conclusion == 'success' }} runs-on : ubuntu-latest env : AWS_REGION : ap-northeast-1 AGENT_SPACE_NAME : ${{ vars.AGENT_SPACE_NAME }} PENTEST_NAME : ${{ vars.PENTEST_NAME_LIGHT }} steps : - name : Configure AWS credentials (OIDC) uses : aws-actions/configure-aws-credentials@v4 with : role-to-assume : ${{ secrets.AWS_SECURITY_AGENT_ROLE_ARN }} aws-region : ${{ env.AWS_REGION }} - name : Resolve resource IDs id : resolve run : | AGENT_SPACE_ID=$(aws securityagent list-agent-spaces \ --query "agentSpaceSummaries[?name=='$AGENT_SPACE_NAME'].agentSpaceId | [0]" \ --output text) PENTEST_ID=$(aws securityagent list-pentests \ --agent-space-id "$AGENT_SPACE_ID" \ --query "pentestSummaries[?title=='$PENTEST_NAME'].pentestId | [0]" \ --output text) if [ -z "$AGENT_SPACE_ID" ] || [ "$AGENT_SPACE_ID" = "None" ] \ || [ -z "$PENTEST_ID" ] || [ "$PENTEST_ID" = "None" ] ; then echo "Failed to resolve IDs: AGENT_SPACE_ID=$AGENT_SPACE_ID PENTEST_ID=$PENTEST_ID" exit 1 fi echo "agent_space_id=$AGENT_SPACE_ID" >> "$GITHUB_OUTPUT" echo "pentest_id=$PENTEST_ID" >> "$GITHUB_OUTPUT" - name : Start light pentest job (fire-and-forget) run : | JOB_ID=$(aws securityagent start-pentest-job \ --agent-space-id "${{ steps.resolve.outputs.agent_space_id }}" \ --pentest-id "${{ steps.resolve.outputs.pentest_id }}" \ --query 'pentestJobId' --output text) echo "Started light pentest job: $JOB_ID" echo "進捗・結果はコンソールまたは EventBridge 通知で確認してください。" リリース時 / 定期： フルスコープのペネトレーションテスト リリースタグの push、または定期実行でフルスコープのペネトレーションテストを起動します。高コスト・低頻度の枠です。 ペネトレーションテストは数時間〜数十時間かかる場合があり、GitHub ホストランナーの 1 ジョブ最大 6 時間という実行時間制限を超える恐れがあります。そのため、ここでは 起動のみを行い、完了は待たない（非同期キック） 構成とします。テストの進捗・結果は、コンソールや EventBridge 通知などジョブの外で確認する想定です。 # .github/workflows/pentest-full.yml name : security-agent-pentest-full on : push : tags : [ "v*" ] # リリースタグ schedule : - cron : "0 18 * * 0" # 毎週日曜 18:00 UTC（=月曜 3:00 JST）に定期実行 permissions : id-token : write contents : read jobs : pentest-full : runs-on : ubuntu-latest env : AWS_REGION : ap-northeast-1 AGENT_SPACE_NAME : ${{ vars.AGENT_SPACE_NAME }} PENTEST_NAME : ${{ vars.PENTEST_NAME_FULL }} steps : - name : Configure AWS credentials (OIDC) uses : aws-actions/configure-aws-credentials@v4 with : role-to-assume : ${{ secrets.AWS_SECURITY_AGENT_ROLE_ARN }} aws-region : ${{ env.AWS_REGION }} - name : Resolve resource IDs id : resolve run : | AGENT_SPACE_ID=$(aws securityagent list-agent-spaces \ --query "agentSpaceSummaries[?name=='$AGENT_SPACE_NAME'].agentSpaceId | [0]" \ --output text) PENTEST_ID=$(aws securityagent list-pentests \ --agent-space-id "$AGENT_SPACE_ID" \ --query "pentestSummaries[?title=='$PENTEST_NAME'].pentestId | [0]" \ --output text) if [ -z "$AGENT_SPACE_ID" ] || [ "$AGENT_SPACE_ID" = "None" ] \ || [ -z "$PENTEST_ID" ] || [ "$PENTEST_ID" = "None" ] ; then echo "Failed to resolve IDs: AGENT_SPACE_ID=$AGENT_SPACE_ID PENTEST_ID=$PENTEST_ID" exit 1 fi echo "agent_space_id=$AGENT_SPACE_ID" >> "$GITHUB_OUTPUT" echo "pentest_id=$PENTEST_ID" >> "$GITHUB_OUTPUT" - name : Start full pentest job (fire-and-forget) run : | JOB_ID=$(aws securityagent start-pentest-job \ --agent-space-id "${{ steps.resolve.outputs.agent_space_id }}" \ --pentest-id "${{ steps.resolve.outputs.pentest_id }}" \ --query 'pentestJobId' --output text) echo "Started full pentest job: $JOB_ID" echo "長時間ジョブのため、結果はコンソールまたは EventBridge 通知で確認してください。" 設計ドキュメント更新時： デザインレビュー（脅威モデリング） 設計ドキュメント（ docs/design/ 配下など）の更新をトリガーに、デザインレビュー（脅威モデリング）を起動します。STRIDE 形式での脅威モデル生成を想定しています。 # .github/workflows/design-review.yml name : security-agent-design-review on : push : paths : - "docs/design/**" # 設計ドキュメントの更新時のみ permissions : id-token : write contents : read jobs : design-review : runs-on : ubuntu-latest env : AWS_REGION : ap-northeast-1 AGENT_SPACE_NAME : ${{ vars.AGENT_SPACE_NAME }} THREAT_MODEL_NAME : ${{ vars.THREAT_MODEL_NAME }} steps : - name : Configure AWS credentials (OIDC) uses : aws-actions/configure-aws-credentials@v4 with : role-to-assume : ${{ secrets.AWS_SECURITY_AGENT_ROLE_ARN }} aws-region : ${{ env.AWS_REGION }} - name : Resolve resource IDs id : resolve run : | AGENT_SPACE_ID=$(aws securityagent list-agent-spaces \ --query "agentSpaceSummaries[?name=='$AGENT_SPACE_NAME'].agentSpaceId | [0]" \ --output text) THREAT_MODEL_ID=$(aws securityagent list-threat-models \ --agent-space-id "$AGENT_SPACE_ID" \ --query "threatModelSummaries[?title=='$THREAT_MODEL_NAME'].threatModelId | [0]" \ --output text) if [ -z "$AGENT_SPACE_ID" ] || [ "$AGENT_SPACE_ID" = "None" ] \ || [ -z "$THREAT_MODEL_ID" ] || [ "$THREAT_MODEL_ID" = "None" ] ; then echo "Failed to resolve IDs: AGENT_SPACE_ID=$AGENT_SPACE_ID THREAT_MODEL_ID=$THREAT_MODEL_ID" exit 1 fi echo "agent_space_id=$AGENT_SPACE_ID" >> "$GITHUB_OUTPUT" echo "threat_model_id=$THREAT_MODEL_ID" >> "$GITHUB_OUTPUT" - name : Start threat model job id : start run : | JOB_ID=$(aws securityagent start-threat-model-job \ --agent-space-id "${{ steps.resolve.outputs.agent_space_id }}" \ --threat-model-id "${{ steps.resolve.outputs.threat_model_id }}" \ --query 'threatModelJobId' --output text) echo "job_id=$JOB_ID" >> "$GITHUB_OUTPUT" - name : Wait for completion run : | JOB_ID="${{ steps.start.outputs.job_id }} " AGENT_SPACE_ID=" ${{ steps.resolve.outputs.agent_space_id }} " for i in $(seq 1 60); do STATUS=$(aws securityagent batch-get-threat-model-jobs \ --agent-space-id "$AGENT_SPACE_ID" \ --threat-model-job-ids "$JOB_ID" \ --query 'threatModelJobs[0].status' --output text) echo "status=$STATUS" case "$STATUS" in COMPLETED) exit 0 ;; FAILED|STOPPED) echo "Threat model did not succeed: $STATUS" ; exit 1 ;; esac sleep 30 done echo "Timed out" ; exit 1 まとめ 最近よく話題に挙がるDevOpsにセキュリティを加えた概念、 DevSecOps に沿ったモダンなサービスだと感じました。 今回のAWS Security Agentでは、 コンソール操作だけでなくAPI経由でCICDに取り込める点 、 レビューから修正までをAIで一括管理できる点 、さらに コードレビューやペネトレーションテストにおいて差分レビューやターゲットURL・除外項目の設定などでスコープを調整できる点 から、このDevSecOpsのコンセプトを強く反映しています。 また、単なる効率化にとどまらず、ドキュメントとして人向けに残す成果物まで整備されている点も充実しています。 一方で、懸念点としては以下の3点が挙げられます。 コスト ：プレビュー中の機能もありますが、実際にCI/CDへ組み込んだ際の料金イメージが読みにくい点。エージェントを個別に構築する場合と比較した、運用コスト・性能とのバランス。 秘匿ドキュメントの管理 ：社内の機密情報や個人情報を含むドキュメントをクラウド上にアップロードすることになるため、要件によっては慎重な判断が必要。 データは既定でAWSマネージドキーにより暗号化され、任意でカスタマーマネージドキー（CMK）を指定して自社で鍵を管理することも可能であり、保護の仕組みは用意されている。そのため、最終的には自社のセキュリティ要件に照らして判断することになる想定。 レビューやテストの性能 ：現在の検出性能や今後の伸びしろについて、セキュリティエンジニアの視点でのご意見をぜひお聞きしたいと感じています。 おわりに 本記事では、AWS Security Agentの概要を紹介しました。今後も、機能の追加や検出性能そのもののアップグレードが期待されます。 ただし、偽陽性が多いのではないかという声も聞いたため、検出性能については別途、評価・比較してみたいと考えています。 ご精読いただき、ありがとうございました。 余談になりますが、先輩と話した際に挙がった、「ペネトレーションテストを主軸に開発を進める中で、アプリケーションのコンテキストを理解させるために、結局は設計レビュー・コードレビュー・脅威モデリングが必要になり、機能として統合されていったのではないか」という見方には、かなり納得できました。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @sakae.katsuto レビュー： @miyazawa.hibiki （ Shodo で執筆されました ）

こんにちは。 アプリケーションサービス本部、DevOps担当の兼安です。 2026年6月末、AWS CloudFormationとAWS CDKのExpressモードがリリースされました。 aws.amazon.com 本機能は「デプロイ時間を最大4倍短縮する」という触れ込みの新機能です。 本記事ではこの新機能をAWS CDKの方に絞って試してみたので、その検証結果を共有します。 本記事では、AWS CDKをCDK、AWS CloudFormationをCloudFormationと記述します。 AWS CDKのExpressモードとは テンプレート変更は不要と、ロールバック無効の意味 テンプ…