自律ペンテストAI「AWS Security Agent」を試してみた

この記事でわかること

対象のURLを登録するだけで、AIが自律的に脆弱性を探し、実際に攻撃ペイロードを送り、悪用が成立するところまで実証してくれる。
そんな触れ込みのサービスが2026年3月に GA（General Availability、一般提供開始）しました。
AWS Security Agent です。

本当にそこまでやるのなら、どこまで見つけて、どこから先を見つけられないのか。
その境目が知りたくなりました。
そこで、答えが公開されているテスト用アプリを的にして、検出力を実測してみます。
ソースコードを見せない「ブラックボックス」と、見せる「ホワイトボックス」の二段で回し、結果を突き合わせました。

実測して分かったことは、三つあります。

• ブラックボックス（対象URLだけ渡す）では、採点対象9カテゴリのうち4カテゴリしか立ちませんでした。確定した指摘は19件です。
• ソースまで渡すと7カテゴリに増え、確定50件になりました。増えたのは暗号、設計、認証の三つです。
• そして、どちらで回しても最後まで埋まらないカテゴリが二つ残りました。

セキュリティテストの自動化に関心がある方、あるいは「AIが自律でペンテストする」という言葉の実際を知りたい方を、読者に想定しています。

AWS Security Agent とは何か

AWS Security Agent は、テスト対象のURLを登録すると、自律的に脆弱性を探し、実際に攻撃ペイロードを送って悪用が成立するかどうかまで検証するサービスです。
出力は、一般的なペネトレーションテスト（システムへ実際に侵入を試みて安全性を評価する手法。以下ペンテスト）の報告書に近いものになります。
発見ごとに、脆弱性の種別、説明、CVSS（Common Vulnerability Scoring System、脆弱性の深刻度を数値化する標準）スコア、再現手順、検証用スクリプトが付きます。

料金は作業時間に対して課金されます。
稼働した1時間あたりで課金され、ジョブを流していない待機中は課金されません。
新規利用者には一定の無料枠があり、今回の検証はその枠内で実費ゼロに収まりました。

的は OWASP Juice Shop

検出力を測るには、正解が分かっている的が要ります。

OWASP Juice Shop は、学習用にわざと脆弱性を仕込んだ Web アプリケーションです¹。
SQL インジェクション、クロスサイトスクリプティング、権限の回避など、実際の攻撃で問われる欠陥がひととおり埋め込まれています。
docker run 一発で起動でき、脆弱性の一覧も公式に公開されているため、検出ツールの答え合わせに向いています。
この「答えが公開されている」点が、あとで評価の設計に効いてきます。

評価を二段に分けた理由

答えが公開されている、という長所には裏があります。
Juice Shop のリポジトリには、全チャレンジの答えとヒントを載せた公式ファイルが同梱されています。
これをそのまま AWS Security Agent に読ませると、答案を渡した状態で検出率を測ることになり、その数字は素の検出力を反映しません。

そこで評価を二段に分けました。

1. ブラックボックス：対象URLだけを登録し、ソースコードは一切渡さない。これを主指標にします。
2. ホワイトボックス：ソースコードも渡す。「ソースを見せると何件上乗せされるか」という差分の参考値として扱います。

ブラックボックスを主役にしたのは、答えを伏せたときにどこまで自力で見つけるかが、実運用にいちばん近いからです。

検証環境

対象アプリは脆弱性だらけで踏み台などになる可能性もあるため、外から誰でも触れる状態でインターネットに置きたくはありませんでした。
そこで、AWS の VPC（Virtual Private Cloud、AWS上に作る隔離された仮想ネットワーク）の中に Juice Shop を閉じ込め、外部から到達できない構成にしました。
構築は AWS CDK（Cloud Development Kit、インフラをコードで定義するツール）の Python 版で書き、あとから同じ環境を再現できるようにしています。

[VPC]
  ├ プライベートサブネット
  │   ├ EC2 上で docker run bkimminich/juice-shop（Juice Shop 本体）
  │   └ AWS Security Agent のエージェント（ここに配置される）
  └ NAT ゲートウェイ（プライベート側から外部への通信を中継）

対象アプリ自体は外から到達できないまま、エージェントだけが NAT（Network Address Translation、内側から外側への通信を中継する仕組み）ゲートウェイ経由で外へ出られる構成です。

件数の数え方

結果の前に、何を1件と数えるかを決めておきます。

AWS Security Agent は、スキャナがまず疑わしい箇所を挙げ、後段の検証役が実際に試して本物かどうかを判定します。
判定の結果、ツール自身が偽陽性（False Positive、実際には問題でない検出）と結論づけて取り下げるものがあります。
本記事では、この取り下げ分を除いた 確定 の件数を主に使い、報告された総数と併記します²。

採点は、OWASP Top 10 の10カテゴリのうち9カテゴリで行います³。
A08（ソフトウェアとデータ完全性の失敗）は、Juice Shop を Docker で動かすと該当設問がアプリ側の安全機構で無効化され、測定そのものができないため外しました。

ブラックボックスの結果

対象URLだけを渡すと、どこまで見つかるでしょうか。

報告は23件、うち4件をツール自身が偽陽性として取り下げました。
残る確定は19件で、深刻度は Critical が4件、High が4件、Medium が9件、その他が2件です。

確定分の種別を見ると、動的に叩けば表面化するものが並びました。

• SQL インジェクション（SQL Injection、データベースへの問い合わせ文を注入する攻撃）が3件
• IDOR（Insecure Direct Object Reference、他人のデータを識別子の付け替えだけで参照や改ざんできる欠陥）が3件
• クロスサイトスクリプティング（Cross-Site Scripting、他人のブラウザで任意のスクリプトを実行させる攻撃）が2件

しかも報告は、指摘するだけで済ませていませんでした。
「認証済みなら誰でも他人の商品レビューを改ざんできる」という IDOR は、実際にリクエストを送って改ざんが成立することを示した上で報告しています。
ファイル取得エンドポイントに対しては、ヌルバイト注入で拡張子チェックを回避し、機微なファイルを読み出す手順まで再現していました。

ただ、カテゴリ単位で採点すると景色が変わります。
確定分が立ったのは9カテゴリ中4カテゴリ（アクセス制御、インジェクション、設定ミス、SSRF）で、カバレッジは44.4%でした。
半分を割っています。
外から叩くだけでは、届かない領域があるようです。

ホワイトボックスの結果と差分

では、その届かない領域は、ソースを見せれば埋まるのでしょうか。

ソースコードも渡したホワイトボックスでは、59件が報告され、9件が取り下げられ、確定50件が残りました。
Critical だけで12件、High が15件です。
新しく立ったのは、暗号、設計、認証のカテゴリでした。

OWASP カテゴリ	ブラックボックス	ホワイトボックス
A01 アクセス制御の不備	7	13
A02 暗号の失敗	0	3
A03 インジェクション	7	7
A04 安全でない設計	0	7
A05 セキュリティ設定ミス	4	9
A06 脆弱なコンポーネント	0	0
A07 認証の失敗	0	7
A09 ログと監視の失敗	0	0
A10 SSRF	1	1

この表は上記9カテゴリに分類できた確定分を数えています。
ホワイトボックスの確定50件のうち3件は、セッション管理やオブジェクト権限といった、この9分類にそのまま乗らない種別のため表からは外しています。

埋まったカテゴリの中身が、この検証でいちばん見応えがありました。
暗号（A02）では、全ユーザーのパスワードがソルト無しの MD5 でハッシュ化されており、レインボーテーブルで平文に戻せる、という指摘が立ちました。
HMAC の秘密鍵がソースにハードコードされていて、セキュリティ質問の答えを事前計算できる、という発見もありました。
設計（A04）では、数量にマイナスを入れると残高が増える、現在のパスワード確認なしにパスワードを変更できる、といった業務ロジックの穴が上がってきました。
認証（A07）では、JWT（JSON Web Token、署名付きのトークン）の署名アルゴリズムを alg:none に差し替えて任意の利用者になりすます、という古典的な回避が確定で挙がりました。

これらが、ブラックボックスでゼロだった領域です。
実は、ブラックボックスでも認証まわりの指摘は2件出ていました。
ただしどちらも「403の回避に見えるが、実際は単一ページアプリが同じ画面を返しているだけ」としてツール自身が取り下げています。
確定した認証の欠陥は、ブラックボックスではゼロでした。

つまり、ブラックボックスが取りこぼしたのは、暗号、設計、認証という、コードを見ないと確信しにくい領域です。
外から通信を叩いているだけでは、そこにあると確信するところまで届きません。
ソースを渡すと、その壁が外れました。

答えを何件解けたか

ここまではカテゴリの広さで見てきました。
別の物差しも当ててみます。
Juice Shop の既知の答えそのものを、何件攻略できたか。
分母は、この Docker 環境で実際に発火する OWASP Top 10 のチャレンジ67件です（公式の答えのうち、環境で無効化される17件を除いたもの）。

叩ける67件のうち、ブラックボックスで14件（21%）、ホワイトボックスで30件（45%）を攻略しました。

ここで、21%という数字を44.4%より「悪い」と読まないでください。
両者は測っているものが違います。
前者は答えを一つずつ解いた完答率、後者は種類の網羅であり、種類が広くても一つずつの完答は残るからです。

完答率の内訳を見ると、最後まで手薄だった領域が二つありました。

• 依存ライブラリの既知脆弱性：古いバージョンのライブラリに既知の脆弱性がある、という類のリスク。
• ログと監視が十分か：攻撃の記録や検知が足りているか、という運用側の問い。

一つめが埋まらないのは、種類の違う道具が要るからです。
依存ライブラリのバージョンを既知脆弱性の一覧と突き合わせるのは、SCA（Software Composition Analysis、依存関係の構成解析）の仕事であって、動的な攻撃や汎用のコード解析とは別系統になります。
二つめは、ログファイルが露出しているような「見えてしまう」問題なら拾えます。
ですが、ログが検知に十分かという設計の妥当性は、外から叩くだけでは判定しづらいものです。

自律ペンテストAIは、動的に叩ける範囲と、コードで確信できる範囲を広くカバーします。
それでも、この二つは外に残ります。
依存ライブラリの診断とログ設計の妥当性確認は、別の手段で補う前提で組み込むのがよいでしょう。

偽陽性はどう出たか

取り下げられた偽陽性は、ブラックボックスで4件、ホワイトボックスで9件でした。
報告総数に対する割合は、それぞれ17.4%と15.3%になります。

代表的なものは、単一ページアプリがどんなURLにも同じ画面を返す挙動を、スキャナが「アクセス制御の回避」と誤認したケースでした。
最初のスキャナは疑わしいと騒いだものの、後段の検証役が実際に試して誤りだと結論づけています。
偽陽性そのものは一定数出ます。
ただし、ツール自身が取り下げるぶん、利用者の手元に残るノイズは小さくなります。

料金の考え方

作業時間で課金される、と聞くと、割高ではないかという疑問が湧くかもしれません。

今回は、課金の単位となる作業時間（複数のエージェントが並行で動くため、経過した実時間とは別物になります）を、ブラックボックスで18.3時間ぶん、ホワイトボックスで31.3時間ぶん消費しました。
無料枠の内側だったため実費はゼロですが、枠がなければ1時間あたり50ドルで、合計およそ2,481ドルにあたります。
偵察や静的な解析といった攻撃の前段にも、この時間は乗ります。

ただ、これは人間へ外注したときと同じ構造です。
外注のペンテストでも、偵察、環境準備、空振りに終わった検証、報告書の執筆まで、すべて時間で請求されます。
確定した脆弱性の数だけ払う外注は存在しません。
ですから、作業時間あたりの料金は、外注の人日単価とそのまま比べられます。

つまずいたところ

環境づくりで、一箇所だけ長く詰まりました。
エージェントの通信経路です。

AWS Security Agent は、検証のためにプライベートサブネット内へ ENI（Elastic Network Interface、仮想的なネットワークインターフェース）を作って動きます。
そのエージェントは、検証結果を外へ送るために外部への出口を必要とします。
プライベートサブネットに外部への経路がないと、エージェントは動き出せずにタイムアウトします。
対象アプリは外から到達できないままにしたい、しかしエージェントは外へ出したい。
この両立の答えが、プライベートサブネットに NAT ゲートウェイ経由の出口を用意することでした。

残りは、一度わかってしまえば手順に落とせるものばかりです。

• ENI を作る IAM（Identity and Access Management、AWSの権限管理）の権限は、公式ドキュメントどおり広めに与える必要がありました。狭めると事前チェックで止まります。
• 対象アプリのメモリが小さい（1GB）と、長時間ジョブの途中でアプリ側が力尽きて503を返します。2GBに上げて緩和しました。
• ホワイトボックスでソースを渡すときは、圧縮形式に指定があります。tar.gz は受け付けられず、ZIP でアップロードし直しました。

ドキュメントを渡しても読まれない、という落とし穴

ソースを渡すと暗号・設計・認証のカテゴリが埋まりました。
ならば、もっと文脈を厚くすればさらに伸びるのではないか。
そう考えて、設計ドキュメント（アーキテクチャ概要や API 仕様）や複数ロールの認証情報を上乗せする追試を試みました。

このうち認証情報は、条件として素直に受理され、認証込みのペンテストとして走りました。
一方でドキュメントを渡す方は、そもそもエージェントに読まれない、という落とし穴に突き当たりました。

AWS Security Agent の API には、対象アプリの文脈を与える documents という入力枠があり、設計書や API 仕様を渡せると公式は説明しています。
ところが、実際に渡してもエージェントがそれを読んだ形跡が出ません。
念のため渡し方を三通り変えて試しました。
1: S3 に ZIP で置く
2: S3 に個別ファイル（.md / .yaml）で置く
3: API のアップロード機能で型を明示して登録する

が、いずれでも、エージェントの実行ログに、渡したドキュメント固有の文言は一度も現れませんでした。
ソースコードの中身は逐語でログにヒットするのに、渡したドキュメントだけが出てきません。
つまり、ドキュメントは受理・保存はされるものの、ペンテストの実行時にはエージェントの文脈へ供給されていない、ということです。

設定ミスを疑って、裏も取りました。
AWS 自身が公開している多エージェント構成の解説記事でも、ペンテストのエージェントが取り込むのは「発見したエンドポイント」「検証済みの指摘」「コード解析が生成した文書」であって、利用者が渡したドキュメントを読む仕組みは書かれていません。
GA 直後にサービスを逆解析した第三者の記事でも、文脈源は CodeBuild 環境と対象アプリの応答とソースコードで、ドキュメント取り込みの機構は見当たらないと報告されています。
公式 API の形式どおりに指定しても読ませられなかった、というのが実測と裏取りの結論です。

そのため、ペンテストで文脈を足すレバーは、いまのところ「ソースを渡す」と「認証情報を渡す」の二つに実質絞られます。
documents はおそらく設計レビューなど別モード向けの入力で、ペンテスト側の取り込みは未実装か今後の対応待ちなのでしょう。
ここが埋まれば、文脈を厚くするとどこまで伸びるかを、もう一度きちんと測り直したいところです。

この結果をどこまで一般化できるか

冒頭の問い、どこまで見つけてどこから先を見つけられないのか、には答えが出ました。
その答えを、そのまま実プロダクトへ持ち出せるかは、別の話になります。

Juice Shop は、学習用に脆弱性を過剰に濃縮したアプリです。
ここで一定のカバレッジが出たとしても、実際のプロダクトでの検出力をそのまま保証するものではありません。
加えて、Docker で動かすと一部のチャレンジはアプリ側の安全機構で最初から無効化され、測定そのものができません。
明らかに宝探し的なチャレンジや、実在の人物やSNS投稿に依存する設問も、評価から外しています。

それでも、二段の比較から言えることははっきりしています。
ソースを渡すかどうかで、暗号と設計と認証のカテゴリが立つかどうかが変わります。
そして、依存ライブラリとログの二カテゴリは、この道具の外で手当てするしかありません。

自動化できる範囲は、思っていたより広いものでした。
その外側に何が残るかを見取り図にした上で使うなら、有効な道具だと感じています。
残った二つを誰がどう埋めるかは、この道具を導入する側が次に考えることになります。

1. OWASP は Open Worldwide Application Security Project の略で、Web アプリケーションのセキュリティに関する標準やツールを公開しているコミュニティ。「OWASP Top 10」は代表的な10カテゴリのリスクをまとめたもの。 ↩

2. ツールは、悪用が成立すると高い信頼度で実証したものと、疑わしいが確証までは至らなかったもの（低信頼度や未検証）を区別しています。ここでいう「確定」は後者も含む、取り下げられなかったものすべてを指します。高信頼度のものだけに絞ると、ブラックボックスで17件、ホワイトボックスで41件になります。ただし後述するカテゴリ単位のカバレッジは、高信頼度だけで数えても同じ結果になります。 ↩

3. Juice Shop 独自のカテゴリ名は OWASP Top 10 の2017年版や2013年版の名称を引きずっているため、2021年版への対応づけは公式の移行対応表を基準にしました。ただし一部（入力検証の不備を A04 に寄せるなど）は公式マッピングが存在せず、本評価での判断による当てはめです。他の評価者なら別の切り方を選び得ます。数値の絶対値より、ブラックボックスからホワイトボックスへの伸びと、カテゴリ間の相対差を見てください。 ↩