AWS Continuum for Penetration Testing に Deep Dive してみる

DevelopersIO 2026 Tokyo で「AWS Continuum for Penetration Testing にDeep Diveしてみる」というタイトルで登壇しました。AI がペネトレーションテストを自動実行する AWS Continuum を検証用アプリで複数回実行し、検証で分かったポイントを共有します。

1. AWS Continuum for Penetration Testing にDeep Diveしてみる クラウド事業統括本部 浅野 晴輝 プロフェッショナルサービス事業本部
2. ⾃⼰紹介 浅野 晴輝 クラウド事業統括本部 ソリューションアーキテクト 普段の業務: AWS / AI駆動開発 / Claude ⽀援 好きな技術: コンテナ / サーバーレス / アプリ開発
3. アジェンダ 01 サービスの概要 機能、実⾏環境、注意点、テストの観点 02 実⾏の流れ エージェントの処理、認証、認証情報テスト 03 結果の⾒⽅ finding、実⾏例、レポート、管理表 04 カバレッジと予算管理 ナレッジによる変化、最⼤タスク時間 05 修正と再検証 コード修正、コードレビュー、再検証 06 運⽤ CI/CD 統合
4. AWS Continuum for Penetration Testing AWS Continuum の機能 (東京リージョン) ペンテスト コードレビュー 設計レビュー 脅威モデリング GA $50 / タスク時間 プレビュー プレビュー プレビュー 主なアップデート 2025/12 プレビュー 2026/08 メール MFA、予算上限、再検証 2026/03 ペンテストが GA 2026/09 認証情報テスト 2026/06 AWS Continuum に統合 2026/10 CI/CD 統合（プレビュー） コード脆弱性 GA（東京はまだ）
5. 実⾏できる環境 ドメインを登録し、エージェントから到達できれば実⾏できる
6. 実⾏前の注意点 本番環境では実⾏しないでください 使うツール Kali Linux 由来のペンテストツール 起こりうる影響 データの変更や削除、サービスの停⽌、セキュリティアラートの発報 作成されたデータ テストで作ったアカウントやデータは、終了時に削除を試みるが、残 ることがある WAF がある場合 リクエストには User-Agent: securityagent が付く。カスタムヘッ ダーも⾜せるので、WAF で許可する 実⾏する環境 本番を模した開発‧STG 環境で、影響を確認してから実施する
7. テストの観点（リスクタイプ） Web アプリケーションのリスクタイプ（13 種類） 任意のファイルアップロード コードインジェクション コマンドインジェクション クロスサイトスクリプティング XSS 安全でない直接オブジェクト参照 IDOR JSON ウェブ上の脆弱性 JWT ローカルファイルの内容 パストラバース 特権の昇格 サーバーサイドリクエストフォージェリ SSRF サーバーサイドテンプレートインジェクション SSTI SQL インジェクション XML 外部エンティティ XXE エンドポイントとリスクタイプは指定 / 除外できる
8. エージェントの処理の流れ 01 認証 02 スキャン 03 マネージド実⾏ 04 ガイド付き探索 05 レポート⽣成 Authentication Agent Scanning Agents Managed Execution Agent Guided Exploration Agent Report Generation Agent 各段の結果は Validator Agent が検証 他エージェントが発⾒した脆弱性の信頼性を実際の攻撃で確認 出典: AWS 公式ブログ（マルチエージェント構成の解説）図 1
9. アプリケーションの認証 認証ユーザー テスト⽤のユーザー 認証⽅式 直接⼊⼒、Secrets Manager、 Lambda MFA TOTP、メール MFA（受信⽤ア ドレスは⾃動で⽤意） 未対応 SMS、プッシュ通知、ハード ウェアキーなど ログイン⼿順 プロンプトで指⽰。テンプレー トあり 保存先 直接⼊⼒した認証情報は Secrets Manager へ
10. 認証情報テスト ⽬的 本番の前に、サインインでき るかだけを確認 料⾦ 無料。ペンテスト本体を回さ ずに試せる 所要 多くは 2 から 3 分（最⼤ 15 分） ⾒えるもの 操作ログと画⾯遷移。MFA の ⼊⼒まで確認できる ドメイン サインイン後に到達したドメ インを候補に表⽰
11. 検出結果（finding） 単位 1 件 = 1 つの脆弱性 評価 重⼤度、信頼度、リスクタイ プ、CVSS 根拠 説明、再現⼿順、ログ、検証ス クリプト 表⽰ 既定では信頼度の⾼いものだ けを表⽰ 編集 誤検知にする、重⼤度を変え る
12. 実⾏例: OWASP Juice Shop 規模 約 17 万⾏、エンドポイント 200以上 検出 18 件（重要 5、⾼ 6、中 7） ⾮表⽰ 12 件（信頼度が低‧誤検知） 実⾏⽅法 ナレッジは⼀切渡さずに実⾏ 料⾦の⽬安（AWS 公式の料⾦例と、今回の実⾏） ケース 実時間 タスク時間 料⾦ 新しい API 1 時間 3.46 時間 $173 EC アプリ（⽉次） 4 時間 24 時間 $1,200 ⼤規模 SaaS 9.5 時間 31.26 時間 $1,563 今回: Juice Shop 4.2 時間 15.47 時間 $773.69
13. レポート ページ数 約 100 ページ（finding 30 件 の場合） 構成 サマリー、CVSS、finding ごと の詳細 ⾔語 英語のみ 誤検知 誤検知も掲載可能 ステータス レポートを出し直すと、その 時点の状態が反映される（解 決済みは Resolved）
14. 検出結果管理表のススメ 検出 → 修正 PR → 再検証 を 1 ⾏で追う
15. ナレッジによる探索範囲の変化 指標（OWASP Benchmark） 仕様書なし 仕様書あり 探索したエンドポイント数 43 125 11.09 時間 19.61 時間 料⾦（$50 / タスク時間） 約 $555 約 $981 実時間 3.8 時間 5.5 時間 タスク時間 OWASP Benchmark 同じ種類の脆弱性を持つ、よく似たエンドポイントが 2,740 個並ぶテス ト⽤アプリ 渡したもの 全エンドポイントを列挙した OpenAPI 仕様書 指⽰しても従わなかった 仕様書に「全件を個別にテストし、省略しないで」と書いても、似たエ ンドポイントは代表だけテストされた
16. カバレッジを上げる回し⽅ 渡せる情報 仕様書、S3上のドキュメント、GitHub のソース、認証情報 結果は実⾏ごとに変わる 複数回まわして、結果を重ねる ロールを変えて実⾏する 権限の異なる認証ユーザーで回す 前回の編集を引き継ぐ Findings Personalization（検出結果のパーソナライゼーショ ン）で、誤検知などの判断が次の実⾏に反映される 時間は渡す情報で変わる エンドポイント数だけでは、タスク時間を⾒積もるのは難しい
17. 予算管理（最⼤タスク時間） 最⼩値 20 時間 タスク時間 エージェントの作業時間の合 計。並列で動くため、実時間 より⻑い 実時間との違い 実時間 4 時間 14 分で、タスク 時間は 15.47 時間 課⾦ 使った分だけ。上限を⾼くして も増えない 設定値 最低20時間以上（もう少し短 くしてほしい）
18. 上限到達時の挙動と記録 タスク時間 19.93 時間（上限 20 時間） 実時間 5 時間 20 分 ジョブ 完了扱い。finding は残る 停⽌理由 バナー、API errorInformation CLI: batch-get-pentest-jobs CloudWatch Logs 停⽌の旨は出ない。途中で途切れ る レポート 停⽌の旨は出ない。未完了タスク が Aborted になる 停⽌コード STOPPED_BY_USER（⼿動停⽌ と同じ）
19. コード修正（修正 PR の作成） 作成⽅法 finding を選んで作成、または ⾃動で作成 対象 接続したプライベートリポジ トリ 単位 finding ごとに 1 本の PR 有効化 「機能を管理」でコード修正 をオンにして保存 PR 作成の進捗 コンソールには出ない。CLI の batch-get-findings で確認 料⾦ 2026 年 10 ⽉時点でプレ ビューとして無料
20. 修正 PR の例: SQL インジェクション 脆弱性 検索語が SQL に直接⼊り、全 テーブルを読めた 修正の内容 クエリを、パラメータ置換に 変更 変更の範囲 対象の処理と、関連するテス ト 2 ファイル PR の本⽂ 問題、修正内容、変更ファイ ルを記載 コミット [skip ci] が付く。CI は⾃分で 回す 結果 そのままマージして再検証する と Resolved
21. PR のコードレビュー（プレビュー） 対象 ユーザーが作成したPRに 発⽕タイミング‧ブランチを フィルターで指定可能 確認コメント ユーザーがPR発⾏後、約 20秒 程で「確認中」と付与される レビュー結果 確認コメント付与から⼤体 4 ~5分程度で「Severity」 「Evidence」を分けて指摘 修正 PR エージェント⾃動の修正 PR に は、レビューは付かない
22. 検出結果の再検証 料⾦ finding ごとに 3 回まで無料。 以降はタスク時間で課⾦ 対象 選んだ finding だけを再テスト する タイミング 誤検知の疑い / コード修正後 結果 Active（残る）/ Resolved（解 消） 所要 脆弱性1つにつき 約30 ~ 40 分
23. 再検証のジョブと記録 ジョブ 再検証のたびに、実⾏⼀覧に ジョブが追加される finding 再検証で脆弱性が解消される と元のfindingのステータスが 「Resolved」に変更される レポート 再検証ジョブはその finding だ けのレポートが記録される 履歴 再検証ごとの結果が、finding の履歴に残る
24. 再検証の例: インフラ側の対策とアプリの修正 対象の finding 認証なしで GET /rest/memories を呼ぶと、他ユーザーのメールアドレスやパ スワードハッシュが返る 項⽬ 1 回⽬: インフラ側だけの修正 2 回⽬: アプリを修正 対策 ALB のルールで /rest/memories を 403 に 返すユーザー情報を、必要な項⽬に限定 再検証結果 Active Resolved 判定の理由 ALB は⼤⽂字⼩⽂字を区別するため、 /rest/Memories で到達できた レスポンスに機密情報がないことを確認 追加の finding 迂回経路が新しい finding として起票 なし 所要 38 分（0.37 タスク時間） 32 分（0.35 タスク時間）
25. CI/CD 統合でサイクルを回す この体制が整うと、ペンテスト以外の脆弱性対応も回しやすくなる CI/CD 統合は 2026 年 10 ⽉時点でプレビュー
26. まとめ 01 準備: 本番ではなく STG ‧開発環境で実施 02 実⾏: ソースや認証情報を渡しユーザー権限を変えて複数回実⾏ 03 予算: 上限タスク時間を決める‧ナレッジに応じて実⾏時間は変わる 04 修正: ⾃動PR は⼈がレビュー。再検証まで 1 セットで実⾏ 05 運⽤: CI/CD に組み込み、差分だけ継続して回す
27. ご清聴ありがとうございました 詳しい挙動は DevelopersIO の記事で紹介しています
28. アンケートにご協⼒お願いします！ DevIO Passから回答が可能です
29. スタンプラリーに挑戦しよう！ イベント会場（20会場）には QRコードが設置されております！ 全部集めて景品をGETしよう！ ※先着10名様に豪華景品をプレゼント！ 感想は ハッシュタグ #devio2026
30. 会場マップ