はじめに
昨今、開発フェーズのセキュリティのシフトレフトがよく言われていて、設計段階のセキュリティチェック、コードレビュー、本番リリース前のペネトレーションテストと、リリース前までに色々な取り組みがされています。この分野にAIエージェントを活用して推進しようということで、AWS Security Agentが2025年のre:Inventで発表されました。
その後、プレビュー期間を経て、2026年3月31日にペネトレーション機能が、GAされました。
リリース前は頑張ったのに、リリース後の対応に手が回らないといったことを耳にします。ペネトレーションテストは定期的に行われているでしょうか。その周期は侵害された際のリスクを踏まえて十分な周期になっているでしょうか。セキュリティルールが改定された後のシステムの適合度の確認はどのように行われているでしょうか。また、不適合と判断された部分の対応はいつ実施しているでしょうか。
リリースしたらセキュリティ対策は終わり、ではなく、運用フェーズでも対応をし続けなければなりません。
そういった繰り返し続いていく運用にもSecurity Agentが適用できるのではないかと思い、個人開発のWebアプリを対象に設計レビュー・コードレビュー・ペネトレの3機能を一気通貫で動かしてみました。
AWS Security Agentとは
まず、AWS Security Agentについて、簡単に説明していきます。
主に3つの機能があります。
| 機能 | ステータス（2026年4月時点） |
|---|---|
| 設計レビュー（デザインレビュー） | Preview |
| コードレビュー | Preview |
| ペネトレーションテスト | GA（2026.03.31） |
設計レビュー
要件定義書や設計書をアップロードすると、AWSのセキュリティベストプラクティスに照らして評価してくれる機能。自社のセキュリティ規程をカスタムルールとして追加できるのがポイントで、AWSのベストプラクティスに加えて、うちの規程も見てほしいという使い方が可能です。
コードレビュー
GitHubとの連携が必要で、PRを作成すると自動でセキュリティ観点のレビューコメントが付きます。
ペネトレーションテスト
実際にアプリに対して攻撃を行い、脆弱性を発見。さらにその修正PRまで自動生成してくれます。
注意
2026年4月30日時点で、設計レビューとコードレビューはPreview中となります。GAとなったペネトレーションテストもアップデートが継続的に行われると考えられますので、利用される際はマニュアルを確認しつつ、進めていただければと思います。
画面表示について
ちなみに、全機能Preview期間は、コンソール上の並び順が「設計レビュー→コードレビュー→ペネトレ」という順番だったのが、ペネトレがGAされたのを境に現在は「ペネトレ→設計レビュー→コードレビュー」に変わっています。開発ライフサイクルを意識した順番であるPreview期間中の方が、自然に感じます。
（参考）全機能Preview中
（参考）ペネトレGA後
検証対象アプリ
OWASP Juice Shopのような脆弱性が最初から仕込まれたアプリについては、昨年のre:InventのWorkshopで経験していたので、今回はあえて個人開発のWebアプリを対象にしてみました。
対象アプリは、Kahoot!風のリアルタイムクイズ大会Webアプリです。構成は以下のとおり。基本的なserverless構成で作ったアプリになります。
参加者は毎回変わる6桁のアクセスコードを入力して参加し、クイズに回答します。回答や結果はWebSocketで参加者側へ随時通知されます。管理者はCognitoでIDとパスワードを使って認証し、問題や進行を管理する設計です。
事前準備
Agent Spaceを作る
3つの機能（設計レビュー・コードレビュー・ペネトレ）はすべてAgent Spaceという単位で管理されます。まずAgent Spaceを1つ作ることがすべての出発点になります。
以下、作業の流れです。ペネトレのGAに伴い、東京リージョンで作成できるようになりました。
AWSマネジメントコンソールの検索バーで「Security Agent」を開き、「AWS Security Agentをセットアップ」をクリックします。
セットアップをしていきます。
- Agent Space名を入力する（後から変更できないため注意。後ほど、誤字に気づく･･･）
- ユーザーアクセス設定を選択（次節で詳述します）
- サービスアクセスで作成されるAgent用のロールが作られます
あとは「AWS Security Agentをセットアップ」をクリックします。
エージェントスペースができました。
ユーザーアクセスについて
作成時に「IAMアイデンティティセンターによるSSO」か「IAM専用アクセス」の2択が出てきます。
今回は「IAMアイデンティティセンターによるSSO」を選択して、既存のIICユーザーを割り当てました。本番環境でもSSO推奨と考えます。IAMユーザーを環境ごとに乱立させるとアカウント管理が煩雑になりますし、異動や退職者対応などを踏まえるとSSOに集約する方が楽です。
自動で作成されるIAMロールについて
Security Agentのセットアップで自動作成されたIAMロールはapplication-YYYYMMDDhhmmssといった名称になりました。
このロールには、カスタマー管理ポリシー1つとAWS管理ポリシー1つが割り当てられていました。
カスタマー管理ポリシーでは、2つの権限が付与されていました。中身はlogs:GetLogEvents（CloudWatch読み取り）とsecretsmanager:CreateSecret（ペネトレ実行時のログイン情報保管用）でした。secretsmanager:CreateSecretが付いているのを見て最初はなぜだろうかと思ったのですが、ペネトレーションテスト実行時にテスト用の認証情報がSecrets Managerに保管されているのを後程確認して腹落ちしました。
AWS管理ポリシーとしては、AWSSecurityAgentWebAppPolicyが追加されていました。こちらは、Security Agentが活動するための各種権限が付与されていました。
AWSSecurityAgentWebAppPolicy
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ApplicationAccess",
"Effect": "Allow",
"Action": [
"securityagent:ListAgentSpaces",
"securityagent:ListSecurityRequirements",
"securityagent:ListTargetDomains",
"securityagent:BatchGetTargetDomains"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceAccount": "${aws:PrincipalAccount}"
}
}
},
{
"Sid": "AgentSpaceAccess",
"Effect": "Allow",
"Action": [
"securityagent:AddArtifact",
"securityagent:BatchDeletePentests",
"securityagent:BatchGetAgentSpaces",
"securityagent:BatchGetArtifactMetadata",
"securityagent:BatchGetFindings",
"securityagent:BatchGetPentestJobs",
"securityagent:BatchGetPentests",
"securityagent:BatchGetPentestJobContentMetadata",
"securityagent:BatchGetPentestJobTasks",
"securityagent:CreateDesignReview",
"securityagent:CreatePentest",
"securityagent:DeleteArtifact",
"securityagent:GetArtifact",
"securityagent:DeleteDesignReview",
"securityagent:GetDesignReview",
"securityagent:GetDesignReviewArtifact",
"securityagent:ListArtifacts",
"securityagent:ListDiscoveredEndpoints",
"securityagent:ListDesignReviewComments",
"securityagent:ListDesignReviews",
"securityagent:ListFindings",
"securityagent:ListIntegratedResources",
"securityagent:ListPentestJobsForPentest",
"securityagent:ListPentests",
"securityagent:ListPentestJobTasks",
"securityagent:StartCodeRemediation",
"securityagent:StartPentestJob",
"securityagent:StopPentestJob",
"securityagent:UpdateFinding",
"securityagent:UpdatePentest",
"securityagent:GetDesignReviewFeedback",
"securityagent:PutDesignReviewFeedback"
],
"Resource": "arn:aws:securityagent:*:*:agent-space*",
"Condition": {
"StringEquals": {
"aws:ResourceAccount": "${aws:PrincipalAccount}"
}
}
}
]
}
これでエージェントスペースができました。
ユーザーアクセスのところのURLでSecurity Agentのサイトにアクセスできます。
アクセスするとこちらの画面が開きます。
設計レビュー（Preview）
準備ができましたので、設計レビューを実施していきます。
設計レビューの実施手順
エージェントスペースの左メニューから「デザインレビュー」を選択し、「デザインレビューを作成」をクリックします。
表示された画面で、デザインレビュー名を入力して、確認するファイルをアップロードして、「デザインレビューを開始する」をクリックします。
アップロードした設計書
対応形式はDOC、DOCX、JPEG、MD、PDF、PNG、TXTと幅広い形式に対応しています。
今回はClaudeを活用して書いたMarkdownの4ファイルをアップロードしました。
-
architecture.md（アーキテクチャ設計書） -
requirements.md（要件定義書） -
security-design.md（セキュリティ設計書） -
sequence-diagram.md（シーケンス図）
複数ファイルを横断して読んでくれるのかが不安でしたが、実際には横断的に解釈して評価してくれました。
初回の結果
非準拠となる項目はありませんでした。
そもそもどういった要件でチェックされているのか？という点についてですが、検出結果のレビューというところに表示されています。
セキュリティ要件について
具体的なチェック観点は、Security Agentのサービス側で設定できるようになっています。
AWSマネージドのベストプラクティス要件が10種類設定されていました。
中身はこのような形となっており、英語で書かれています。
カスタムルールは日本語でOK
AWSマネージドのルールはすべて英語でしたが、カスタムルールは日本語で書いてもAgentはちゃんと評価してくれました。日本のエンタープライズでよくありそうなルールを日本語で記載してみました。ログ保存期間と国内リージョン縛りです。
規程にそのまま書いてある文章を貼り付けて評価できるという点は、情シス部門にとって地味に大きいと考えます。翻訳や言い換えが不要なので、セキュリティ専門家でなくても、直接入力することが可能です。
一方で、CLIでは登録ができないようですので、1つずつ手入力が必要です。複数アカウントで登録をしていくのは非常に手間になるので、Organizationsで1AWSアカウントのみにセキュリティ要件を登録し、各システムがエージェントスペースにSSOでアクセスして、レビューを受けるというのが現実的な運用方法ではないかと考えました。
2回目のチェック
改めてデザインレビューを実施します。
前回実施のレビューをクローンしてルールだけを変えてレビューができるようになっています。この辺りは何度も繰り返すことを想定しての作りだと理解しました。
結果はこちら。今度はいくつか非準拠になりました。
このアプリはCloudWatch Logsの保存期間を意図的に3日に設定していたため、非準拠の判定が出ました。修正ガイダンスも自動で生成され、内容は「CloudFormationテンプレート内のすべてのCloudWatch Logsロググループでログ保存期間を365、またはそれ以上に設定すること」という具体的なものです。
※日本語に翻訳して表示しました
もう1つ追加した要件「業務データの国内リージョン保管要件」のチェック結果はこちらです。「業務データはすべて国内リージョン（ap-northeast-1）にのみ保管すること」というシンプルな日本語の要件で、この結果はデータ不足でした。設計書のどこにもAWSリージョンを明記していなかったため、Security Agentには判断できなかったと考えられます。
1回目と2回目で判定が変わる
第1回レビューの結果は準拠が9件、該当なしが1件でした。
第2回レビューでは、非準拠が2件、データ不足が1件、準拠が8件、該当なしが1件となりました。
セキュリティ要件を2つ追加したので総数は増えているのですが、同じドキュメントをレビューしたのに、結果が変わってしまった項目があります。
犯人は、「Secret Protection Best Practices」でした。1回目は準拠でしたが、2回目は非準拠に変わっていました。
ドキュメントは一切変えていないため、第1回のレビューでSecurity Agentは見落としていたことになります。第2回で改めて読んだ際に発見されました。
AIエージェントも見落とすというのは、見方によってはネガティブな事実ですが、複数回実施すれば検出率が上がるという運用上の示唆でもあると捉えました。人間のセキュリティレビューも1回で完璧には拾えないのと同じです。
指摘を受けた点を直して、3回目のレビューを行いました。
ログの保管期間は割り切りで非準拠のまま進めることにしました。
実運用でも、割り切るということはありますよね。
コードレビュー
事前準備：GitHub連携のセットアップ
コードレビューはGitHubアカウントとの連携が必要で、Security AgentのGitHub App インストールと認証の手順を踏む必要があります。
注意点として、1つのAWSアカウントにしかGitHub連携できないという点があります。
マルチアカウント構成を使っている場合は、どのAWSアカウントでコードレビューを管理するかを事前に設計しておく必要があります。
私はGitHubのアカウントで昨年、Workshopを実施した際に別AWSアカウントからSecurity Agentがインストール、認証されていたため、今回のAWSアカウントでインストールしようとした際に、連携ができなくなりました。解決策は「GitHub側からAppをアンインストールして、Security Agent側から再インストール」でした。
設定の流れは以下のとおりです。
左メニューから「統合」を選択し、「統合を追加」→「GitHub」をクリック
「インストールと認証」をクリック → GitHubのページにリダイレクトされる
GitHubアカウントでログイン後、リポジトリを選択して、インストールします。
アクセス対象のリポジトリ範囲を指定します（全リポジトリ or 特定リポジトリ）
AWSコンソールに戻ってくるので、登録名を入力して「接続」をクリックします。
改めて統合を追加の画面に戻ってきて、先ほど追加した接続を選択して次に進みます。
注意
「機能を管理」のページで、赤枠の部分のチェックを入れ忘れると、いくらやっても接続できません。
必ず対象のリポジトリにチェックを入れてから、接続ボタンを押下してください。
うまく接続できると以下のように「有効化済み」のステータスになります。
実際に検出された内容
Security Agentのレビューを行う前から、WebアプリはGitHub上のリポジトリで開発をしていました。Security Agentをインストールした後に、Webアプリで機能修正を実施して、PRを作成したところ、aws-security-agent[bot]からコメントが付きました。しばらくすると、具体的な指摘が追加されました。
指摘内容としては、XSSの脆弱性が含まれているというものでした。
内容を確認して、Claudeに修正を指示し、改めてPRを作成、Security Agentのレビューを実施ということを繰り返していきました。
なお、コメントの最後に以下の記載がありました。
Customize which findings are reported by adding a filtering.md file to your repository. Use it to exclude files from analysis and provide context hints that reduce false positives.
こちらの記載によると、リポジトリにfiltering.mdファイルを追加することで、報告する検出結果から除外するファイルや、誤検出を減らすためのコンテキストを設定できるようです。
機能追加を終えたら、いよいよペネトレーションテストに入っていきます。
ペネトレーションテスト
事前準備：ターゲットドメインの設定
インターネット公開のWebアプリに対してペネトレーションテストを実施するには、ターゲットドメインの登録が必要となります。エージェントが勝手に別サイトを攻撃をしてはいけないので、重要なポイントです。
まずはターゲットドメインの追加を実施していきます。
ペネトレーションテストのタブを選択し、「ドメインを追加」を選択します。
「ドメインを追加」を選択し、ドメインを記載し、検証方法として「DNSテキストレコード」を選択し「次へ」をクリックして進みます。
ターゲットドメインの仮登録ができました。
この検証トークンを自身のドメインに登録していきます。
私は、個人Organizations内の別AWSアカウントのRoute 53で管理していましたので、先ほどのDNSレコード名、検証トークンを設定してTXTレコードを作成しました。
「検証」ボタンを押下すると、しばらくしてステータスが「検証済み」となりました。
事前準備：ペネトレーションテストの設定
続いてウェブアプリ側で設定していきます。
ペネトレーションテストの設定をしていきます。
「範囲外のURL」でチェックを除外するURLを指定できます。
また、「アクセス可能なURL」は指定したドメイン以外でアクセスが必要となる（ただし、ペネトレの対象外となる）URLを指定する形になります。
画像では指定していませんが、Cognitoを使用している場合、こちらで指定しておかないとテストに失敗します。東京リージョンでは以下のURLを指定しました。
https://cognito-idp.ap-northeast-1.amazonaws.com
サービスロールは以下のものが自動作成されていましたので選択しました。
security-testing
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:GetRole",
"iam:SimulatePrincipalPolicy"
],
"Resource": "arn:aws:iam::{ACCOUNT}:role/service-role/security-testing-20260419105234"
},
{
"Effect": "Allow",
"Action": "secretsmanager:GetSecretValue",
"Resource": [
"arn:aws:secretsmanager:ap-northeast-1:{ACCOUNT}:secret:quizz_web_app*"
]
},
{
"Effect": "Allow",
"Action": "logs:CreateLogGroup",
"Resource": "arn:aws:logs:ap-northeast-1:{ACCOUNT}:log-group:/aws/securityagent/quizz_web_app*",
"Condition": {
"StringEquals": {
"aws:ResourceAccount": "{ACCOUNT}"
}
}
},
{
"Effect": "Allow",
"Action": [
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": [
"arn:aws:logs:ap-northeast-1:{ACCOUNT}:log-group:/aws/securityagent/quizz_web_app*:log-stream:quizz_web_app*"
],
"Condition": {
"StringEquals": {
"aws:ResourceAccount": "{ACCOUNT}"
}
}
}
]
}
最後の設定項目に自動コード修正があります。こちらは、検出結果に対してGitHub上で自動PR作成してくれるものになります。今回はチェックを入れて進めました。
続いてVPCリソースですが、今回はVPCレスの構成のため、スキップしました。
次の画面では、認証リソースを設定しました。また、ログイン方法については、自然言語で記載をしました。設定項目を見る限り、2要素認証のTOTPシークレットにも対応しているようでした。
ちなみに、こちらで設定したユーザー名、パスワードの内容は、AWS Secrets Managerにシークレットとして登録されていました。
その他の学習リソースとしては、リポジトリを対象としました。
ここまででようやくペネトレーションテストの準備ができました。
ペネトレーションテストの実施
「実行を開始する」を選択して、進めていきます。
確認のポップアップが出るので、進めていきます。
実行を開始しました。
1回目：失敗
ちなみに、初回実行は2時間半ほどで失敗しました。
原因は先ほど記載したCognitoのアクセスURLを指定していなかったため、エージェントがログインを何度も試行し続けた結果、失敗していました。
ちなみに要したタスク時間は2.33時間、116.5USDです（1タスク時間あたり50USD)。おおよそ2万円弱が消える結果になりました。
離席して、戻ってきたら失敗しているという悲しい結果でした。
2回目：成功
ログを調べて、Cognitoの件が特定できましたので、設定を修正し、気を取り直してリトライします。
今度は成功しました。
処理時間としては、7時間44分掛かりました。タスク時間としては34.41時間で、1,720.5USDです。日本円でおおよそ30万円弱になりました。なかなか終わらないので、用事を済ませて戻ってきたらこの結果でした。
テスト中はエージェントがパラレルで動きますので、その合計時間がタスク時間となっているようです。
結果画面では、処理時間やタスク時間、検出された重大度レベルなどを見ることができます。
エージェントの動きを見てみる
実行中のエージェントの処理内容は随時見られるようになっています。
例えばプリフライト時のログインの処理などは以下のようになっています。1回目失敗した時は見ていなかったのですが、2回目はログインできるか心配だったので見届けました。
また、ペネトレーションテスト自体では、78のアクションを並行して処理していきました。
まず目を引いたのはCode scanner（16件）が最多ということでした。ペネトレーションテストというと実際にアプリを叩く動的テストのイメージがありましたが、Security Agentはリポジトリのコードをしっかりと静的解析してから動的テストに入るということが分かります。また、Network scannerで構成を把握し、Code scannerで攻撃の糸口を探してから各種攻撃を実行するという順序になっていると考えます。
次にInsecure Direct Object Reference（10件）も多いです。IDORについて調べたところ、/api/user/123 の 123 を 124 に変えたら他人のデータが見えたという類の脆弱性で、ロジックの問題となるため、自動スキャナーが最も検出を苦手とするカテゴリとのことでした。それを10バリエーション試みているのは、単純なパラメータ置換だけでなく、予測可能なID体系や権限境界の抜けを多角的に突こうとしているのだと理解しました。（専門家の方、間違っていたらご指摘ください）
Privilege escalation（9件）も多いです。単一の脆弱性を1つ見つけるだけでなく、この脆弱性から何段階昇格できるかという連鎖攻撃を想定して試行を繰り返していると考えられます。
最後にCleanup（5件）がありました。Security Agentはテストの際にテストデータを書き込みます。そのデータを後始末するためのアクションが自動で組み込まれていました。攻撃した痕跡を残さないという攻撃者としての動きなのか、テスト後の環境整合性を保つという動きなのか気になりました。（きっと後者のはず）
なお、アクションの結果も1つ1つのタスクがどう動いたかがログや画像で保存されています。それを見ていくだけでも勉強になりました。
実行結果のサマリー
さて、7時間44分掛けて、検出された脆弱性は以下になりました。
| 重大度 | 件数 |
|---|---|
| Critical | 1件 |
| High | 5件 |
| Medium | 7件 |
| Low | 2件 |
| Info | 2件 |
| 合計 | 17件 |
リスクタイプは、Business Logic Vulnerabilities、Server Error 500、Information Disclosure、Security Misconfiguration、Insecure Direct Object Reference、Default Credentials、Authentication Bypass、Unrestricted Resource Consumption、Privilege Escalationと幅広かったです。
ちなみに参考までに、チェックを行ったアプリの規模は以下になります。
| 指標 | 値 |
|---|---|
| コード規模 | 3.5Kstep |
| エンドポイント数 | 22件 |
コードレビューで見つからなかったものを発見
検出された脆弱性の中で最も印象に残った検出がCritical判定の1件、「Plaintext Admin Credentials and Live Infrastructure Identifiers Committed to Repository」です。
今回の検証を行うのにあたって、GitHub連携のテストを行う前に意図的にダミーのクレデンシャルをリポジトリに置いていました（管理者メールアドレス、パスワード、CognitoのUser Pool ID、Client IDなど）。
前段のコードレビューで検出をされると思っていたのですが、コードレビューのチェック対象はPRで変更されたコードでした。元々配置していたダミークレデンシャルは差分に含まれていなかったため、コードレビューでは検出されることがありませんでした。
一方、ペネトレーションテストにおける静的コード解析では、リポジトリのコード全量をスキャン対象としていました。その結果、今までチェックから漏れていたダミークレデンシャルを検出することができました。
その後の流れも面白かったです。Security Agentが自動でPR（"Security Fix: Remove Hardcoded Credentials and Enable MFA (CWE-798, CWE-312)"）を作成し、そのPRに対してSecurity Agentのコードレビューが走り「No issues identified.」という確認まで一気通貫で完結しました。
コードレビューとペネトレーションテストは対象範囲が異なるということが明確に分かりました。どちらか一方ではなく、両方を適切なタイミングで使うことが正しいと理解しました。
ペネトレーションテストレポートは英語
検出結果を含め、テスト結果はレポートとして出力することができます。
Executive Summaryから始まり、各FindingについてDescription、Steps to Reproduce（再現手順）、CVSS v3.1 Vector、推奨対応策まで記載されていました。ただ、生成されるPenetration Test ReportはPDF、すべて英語でした。
作りとしては、脆弱性診断会社に診断を依頼して報告してもらうレポートと同じようなフォーマットになります。情報量は十分と感じましたが、日本語環境での運用を考えると、レポートの日本語対応は今後の改善に期待したいところです。
コスト：30万円弱の考え方
今回は34.41タスク時間 × 50USD = 1,720.5 USD（約30万円）になりました。
個人で検証するには厳しい金額でした。フリートライアル（初回実行から2ヶ月間、最大200タスク時間まで無料）が存在していなければ、今回の検証自体が成立しませんでした。
一方で、企業で本番運用する場合、十分に受け入れられる金額感になると考えました。ただし、ペネトレーションテストの費用をどう計画するかは事前に考えておく必要があります。タスク時間はアプリの規模・複雑さ・エンドポイント数によって変わり、事前に正確に見積もることは難しいです。今回は3.5KStep・22エンドポイントのアプリで34.41タスク時間でしたが、この数字をそのまま別のアプリに当てはめることはできないと考えています。フリートライアル期間中に小さな範囲で感覚をつかんでから、本番導入の費用計画を立てるのが現実的だと考えます。
なお、実行回数にもクォーターがあるため、月に何回ペネトレを実施するかも計画に含めておく必要があると考えます（クォーターの緩和申請はできるようです）。
使ってみての所感・注意点
Organizations集約をするか最初に検討する
複数のAWSアカウントをOrganizationsで管理している場合、カスタムセキュリティ要件をどのアカウントで一元管理するかを最初に決めておくと良いと考えました。個々のアカウントでバラバラに管理すると、規程改訂のたびに全アカウントを更新する手間がかかります。ただし、コードレビューのGitHub連携は1AWSアカウントに限定されるため、この制約との整合性を取った設計が必要になります。
Agentは確率論的。複数回実施が前提
今回の経験から、エージェントのレビューを1回だけ実施して問題なしと判断するのはリスクがあると改めて感じました。実際に2回目のレビューで異なる指摘が出て、設計書更新漏れが発覚しました。設計レビュー、コードレビューGA後のコストとのトレードオフにはなりますが、重要な判断材料にするなら複数回実施して差分を見ることが必要と考えました。
ペネトレのコスト試算は事前にできない
このアプリにペネトレを走らせたら何タスク時間かかるかを事前に正確に計算する方法はありません。実行してみないとわからないというのが正直なところです。フリートライアル期間を最大限に活用して感覚値を積み上げていく必要があります。
一方で、予算枠内で何を優先してテストするかメニューで選択できるようにしたり、エージェントと相談してアプリケーションの特性に応じてリスクが高いポイントを重点的にテストしたりできると、さらに使いやすいサービスになると感じました。（実際、診断会社に依頼する際も、予算に応じてそういった調整をみなさん行われていると思います）
まとめ
人手のペネトレは当面なくならない
AWS Security Agentのペネトレーションテストは、専門家によるペネトレーションテストを置き換えるものではないと考えています。少なくとも現時点では、監査対応や金融・医療など規制業界で求められる認定ベンダーによるペネトレの代わりにはなりません。
一方で、目的の整理は必要だと考えます。監査要件を満たすためのペネトレと継続的なセキュリティ状態の把握は別物と考えられます。Security Agentが埋められるのは後者の領域であって、前者の人手ペネトレを廃止するためのツールではないと考えます。開発フェーズでのセキュリティのシフトレフトに加えて、運用フェーズでの間を埋めるツールとして位置付けると、導入の理屈が立つのではないかと考えます。
今までできなかったことができるようになる
セキュリティの設計レビュー・コードレビュー・ペネトレは、新規開発プロジェクトのフェーズでしか実施できていなかったり、人手と予算の制約で、リリース後のシステムに継続的にセキュリティチェックをかけるのは現実的ではないという声も聞きます。
こうした現状に対して、Security Agentを使うことで改善できるのではないかと考えました。
例えば、以下のようなシナリオです。
- 社内セキュリティルール改訂後の棚卸し：カスタムセキュリティ要件を更新して既存システムの設計書を一括評価
- PoCアプリの本番化前チェック：気づいたらPoCのはずが本番で使われていた、PoCだったからチェックが甘かったといったことを防ぐ
- 運用引き継ぎ時の設計書スキャン：担当者が変わって引き継ぐ際、このシステム、大丈夫？といった不安への回答
どれも、今まで人がいないからやれなかった、スキルが足りないから見送っていたということが、コストと工数を下げた形で実行できるようになると考えます。
組織への導入に向けて
AIがセキュリティチェックしてくれるという表現は誤解を招くとも感じました。エージェントが出した結果の最終的な判断責任は人間にあります。Security Agentが問題ないと言ったので大丈夫、は通りません。設計レビューの結果をレポートとして使う場合でも、人間が内容を確認して判断した上で使用する、というプロセスを組織として明確にしておく必要があると考えます。
また、費用の計上方法も事前に考えておく価値があります。ペネトレの従量課金は今月いくらかかったか後から判明するモデルで、IT部門の年間予算計画と相性が悪いです。フリートライアル期間中にベースラインを把握してから、年間予算に組み込む手順を踏む方が承認を取りやすいのではないかと考えました。
セキュリティ専門家がいないから難しいと思っている組織ほど、まず試してみるのハードルを下げる意味があると考えます。専門家がいなくても一定水準のチェックができる、というのが今回の検証から得た最も大きな収穫でした。
この内容が、運用フェーズでのセキュリティ向上を考えるどなたかの参考になれば幸いです。