AWS Security Agentで自分のサイトにペネトレーションテストをしてみた

本記事は夏休みクラウド自由研究2026 8/31付の記事です。

みなさま、こんにちは
夏バテで晩御飯がアイスになっていた。どうもいとさんです。

先日、AWSの新機能「AWS Security Agent」を使って、自分のWebサイトに対してペネトレーションテスト（侵入テスト）を実施してみました。実際に使ってみると、想定外のトラブルにも遭遇しましたが、最終的には具体的な脆弱性レポートを得ることができました。この記事では、その検証内容と気づきをまとめて紹介します。

なお本記事では、コードレビューや設計段階でのセキュリティレビュー、脅威モデリングの結果には触れず、あくまで「実際に動いているアプリに対するペネトレーションテスト」の実施結果に絞って解説します。

詳細な手順はこちらの資料に記載しておりますのでぜひご覧ください。

AWS Security Agentとは
1. 料金
2. 分析方法（侵入テストの仕組み）
検証の概要
1. 想定した攻撃シナリオ
2. 検証環境と設定手順
実行結果：3度目の正直
検出対象となった脆弱性カテゴリ
他の検証環境との比較
まとめ
おわりに

AWS Security Agentとは

AWS Security Agentは、2025年12月2日（re:Invent 2025）にプレビュー版として発表された、開発ライフサイクル全体を通じてアプリケーションをプロアクティブに保護する「フロンティアエージェント」です。組織のセキュリティ要件に沿った自動レビューと、状況に応じたオンデマンドの侵入テストを提供し、設計段階からデプロイまで継続的にセキュリティを検証することで、開発の早い段階で脆弱性を防ぐことを狙ったサービスです。

AWS セキュリティエージェント

AWS Security Agent の特徴

提供される機能は大きく4つに分かれています（現在は「AWS Continuum」というサービス群の一部として位置づけられています）。

設計セキュリティレビュー：コードを書く前の段階で、アーキテクチャ文書や製品仕様書を解析し、組織が定義したセキュリティ要件（AWSが提供する業界標準ベースの「マネージドセキュリティ要件」と、独自に定義できる「カスタムセキュリティ要件」の両方）への準拠状況を評価します。評価結果は「非準拠」「データ不足」「準拠」「該当なし」の4つのステータスに分類され、是正ガイダンスも提示されます。
脅威モデリング：2026年6月にパブリックプレビューとして追加された比較的新しい機能です。設計ドキュメントやソースコード（あるいはその両方）を解析してアプリケーションのアーキテクチャ・データフロー・信頼境界を把握し、STRIDE（なりすまし／改ざん／否認／情報漏えい／サービス拒否／権限昇格の6分類）に基づいた脅威モデルを自動生成します。出力は、システムの構成や挙動をまとめた「システム概要」と、深刻度・STRIDE分類・対応する緩和策付きの「脅威一覧」の2つで構成されます。KiroやClaude CodeなどのIDEから「Build a threat model for this application」のように指示して実行することもでき、生成された脅威モデルは.security-agent/threat_model.mdとして保存されます。
コードセキュリティレビュー：GitHub・GitLab・Bitbucketのプルリクエストを解析し、SQLインジェクションやクロスサイトスクリプティング（XSS）、不適切な入力検証といったOWASP Top Tenの一般的な脆弱性に加えて、監査ログの保持期間など組織独自のポリシー違反も検出します。
オンデマンド侵入テスト：稼働中のWebアプリケーションやAPIに対して、偵察・エンドポイント列挙によるアタックサーフェスの把握から始まり、認証・認可・インジェクション攻撃などを含む13のリスクカテゴリーにわたって専用エージェントが多段階の攻撃を自律的に実行します。ソースコードやAPI仕様、ビジネス文書を追加で与えると、それらから学習したコンテキストをもとに、より的を絞った攻撃シナリオを組み立ててくれます。

2026年8月時点では、設計レビュー・脅威モデリング・コードレビューの3機能はプレビュー提供で、オンデマンド侵入テストのみが一般提供（GA）済みです。今回はこの侵入テスト機能を使って検証しました。

料金

オンデマンド侵入テスト機能は2026年3月31日に一般提供（GA）が開始され、初期費用・最低利用料なしの完全従量課金制が採用されています。課金単位は「タスクアワー」で、テスト全体の経過時間ではなく、エージェントが実際にテストを実行していた時間（アクティブな稼働時間）に対して1タスクアワーあたり50USDが発生します。新規に利用する顧客は2か月間の無料トライアルが用意されており、この期間中は月あたり一定時間（目安として200タスクアワー程度）まで無料で利用できます。今回の検証もこのトライアル枠を使って行いました。

なお、設計レビュー・脅威モデリング・コードレビューの3機能は本記事執筆時点ではまだプレビュー提供であり、追加費用なしで利用できます（脅威モデリングもパブリックプレビュー中は無料）。ただし正式な料金体系は今後変更される可能性があるため、最新の条件は必ず公式の料金ページでご確認ください。

分析方法（侵入テストの仕組み）

侵入テストは、まずアプリケーションへの偵察とエンドポイントの列挙によってアタックサーフェスを体系的に洗い出すところから始まります。そのうえで、Webアプリケーションやアプリケーション全体をOWASP Top Tenの脆弱性タイプに沿ってテストし、静的解析ツールでは見つけにくい「実際に悪用可能な」問題を特定していきます。たとえば、通常のDAST（動的アプリケーションセキュリティテスト）ツールがサーバーサイドテンプレートインジェクション（SSTI）のペイロードを直接探すのに対し、AWS Security AgentはSSTI攻撃とエラーの強制発生・デバッグ出力の分析を組み合わせることで、より複雑な悪用手順まで検証できるとされています。

対象URLや認証情報、脅威モデル、関連ドキュメントといったテスト範囲を人間の侵入テスト担当者に説明するのと同じ要領で定義すると、AWS Security Agentはそれをもとにアプリケーションのコンテキストを構築し、アプリケーションからのレスポンス（エンドポイント、ステータスコード、エラーコード、認証情報など）に応じて攻撃計画そのものを実行時に動的に調整していきます。なお、侵入テストの実行には対象ドメインの所有権確認があらかじめ必要です。

検証の概要

想定した攻撃シナリオ

想定した攻撃者：外部の攻撃者によるWebアプリへの侵入試行
対象範囲：AWS環境内にある、指定した公開エンドポイント
ゴール：脆弱性の検出とリスク評価を完了させること

検証環境と設定手順

対象サイトはAWS上に構築したWordPressサイトです。設定はおおよそ次の4ステップで進みます。

対象スコープの定義：テスト対象となるAWSリソースやドメインを確認する
Security Agentの有効化：AWSコンソールから機能を有効化する
テスト設定の入力：URLやログイン情報、調査したい項目などを設定し、スキャンの対象範囲と深度を調整する
実行前の最終確認：現在稼働中の環境に影響が出ないか、事前に状態を確認する

実行結果：3度目の正直

実は今回、一発でうまくいったわけではなく、3回試行してようやく成功しました。

1回目：SSL証明書の期限切れで失敗

最初の実行では、SecurityAgentが対象サイトのSSL証明書の期限切れを検知し、スキャンが途中で中断されてしまいました。エラーログには「Certificate has expired」の記録が残っており、TLS接続の確立自体に失敗していたことが分かりました。証明書を更新したうえで再実行することにしました。

2回目：環境汚染により失敗

2回目は接続自体はできたものの、想定外の影響が発生しました。テスト中にWordPress側の安全装置（Fatal Error）が働き、サイトが停止してしまったのです。原因を調べると、送信されたテストデータがデータベースのwp_optionsテーブル（theme_mods_cocoon-masterなど）に書き込まれてしまい、環境が汚染された状態でその後の診断が進んでしまったため、正確な結果が得られませんでした。

対策として「コードインジェクション」のテスト項目を除外指定し、テストデータによる再汚染が起きないようにブロックしたうえで、3回目の実行に臨みました。

3回目：検証成功

3回目でようやくペネトレーションテストが正常に完了し、脆弱性レポートを取得できました。ここでの一番の気づきは、事前に環境をきれいな状態にクリーンアップしておくことが成功の鍵になるという点です。検出された脆弱性と、それぞれに対する改善推奨事項も具体的に提示されました。

実行時間とコスト

3回目の成功時点での実行時間とコストは以下の通りです。

タスク時間：17時間4分
実稼働時間：6時間3分14秒
費用：約850USD

検出対象となった脆弱性カテゴリ

今回のテストでは、次のようなカテゴリを対象に診断が行われました（具体的な検出結果は伏せていますが、カバー範囲の参考にしてください）。

Security Misconfiguration（セキュリティ設定不備）
Cross Site Scripting（XSS）
Local File Inclusion（LFI）
Path Traversal
Insecure Direct Object Reference（IDOR）
Information Disclosure（情報漏えい）
Authentication Bypass（認証回避）
Privilege Escalation（権限昇格）
Server Error 500
Server Side Template Injection（SSTI）
Command Injection
SQL Injection
Arbitrary File Upload
Server Side Request Forgery（SSRF）
JSON Web Tokenの脆弱性
暗号関連の脆弱性
XML External Entity（XXE）
クリーンアップ処理

OWASP Top 10を土台にしつつ、かなり幅広いカテゴリを自動でカバーしてくれる印象です。

他の検証環境との比較

同じAWS Security Agentを、条件を変えて実行した場合の比較結果も紹介します。

検証環境	タスク時間	実稼働時間	費用
今回の環境（WordPressサイト）	17時間4分	6時間3分14秒	約850USD
Webサイト URLのみ（設計書なし）	15時間55分	4時間42分28秒	約850USD
Webサイト URL＋設計書あり	34時間54分	7時間53分59秒	約1,750USD

似たような構成の環境同士では費用に大きな差は出ませんでしたが、設計書ありの環境では実稼働時間・タスク時間・費用のいずれも大きく増加していました。エージェントが設計書を読み込んで学習するコストが、そのまま実行コストの増加につながっているようです。

まとめ

主な成果

環境に応じてカスタマイズされた診断を行うことができた

主な課題

環境ごとにエージェントの料金・稼働時間がどう変動するかが分かりにくい
事前の見積もり機能があるとうれしい

今後の展望

現状レポートが英語のみのため、日本語対応してくれるとうれしい

おわりに

AWS Security Agentのペネトレーションテスト機能は、環境の事前準備さえきちんとしておけば、実際に動いているサイトに対して自動で多段階の攻撃を試し、具体的な改善提案まで得られる便利な機能だと感じました。一方で、SSL証明書切れや環境汚染など、実運用ならではのハマりどころもあったので、これから試す方は事前のクリーンアップと除外設定をしっかり検討することをおすすめします。