【AWS re:Invent 2025】AWS Security Agent が示すプロアクティブ AppSec の設計思想

本記事は、re:Invent 2025 のセッション 「[NEW LAUNCH] AWS Security Agent: Proactive AppSec from Design to Deployment (SEC348)」 の公式説明およびセッション内容をもとに、 AWS がアプリケーションセキュリティをどのように再設計しようとしているのかを整理したものです。

AppSecを人の判断に依存する設計は限界に来ている

セッション冒頭で、講師はこの状況を次のように表現していました。

"Security expertise doesn't scale. But software does."

セキュリティの専門知識そのものはスケールしないが、 ソフトウェアとして仕組みに落とせばスケールする。 この一言が、このセッション全体の前提です。

AWS はセキュリティ要件を「共通」と「組織固有」に再定義した

AWS はセキュリティ要件を次の 2 つに整理します。

①共通：多くの企業で共通して採用されているセキュリティ要件

②組織固有：その会社のビジネス・組織・リスク許容度に基づくセキュリティ要件

この整理について、講師は次のように述べていました。

"Every company shares some security requirements. And every company has requirements that are uniquely their own."

どの会社にも共通するセキュリティ要件があります。 そして同時に、各社にしか存在しない固有の要件もあります。

AWS Security Agent が新しいのは、 ②組織固有の要件を、①共通要件と同じ評価モデル上で 「カスタムセキュリティ要件」として定義し、 設計レビュー・コードレビュー・ペネトレーションテストに一貫して適用する点です。

これにより、セキュリティは一般論としてのチェック項目ではなく、 組織固有の要件を開発プロセス全体に適用する仕組みとして扱われるようになります。

AWS Security Agent ：セキュリティ要件を中心に据えた設計

AWS Security Agent は、 設計・実装・テストをそれぞれ独立したセキュリティ工程として扱いません。 代わりに、単一のセキュリティ要件セットを定義し、 それを開発ライフサイクル全体に一貫して適用します。 この設計により、「どの工程で、どの基準で判断するか」を人の判断に委ねず、 同じセキュリティ要件をもとに、継続的に評価できる状態を作ります。

AWS Security Agent では、前章で整理した 「共通要件」と「組織固有要件」を、 それぞれマネージド／カスタムの形で扱います。

①共通：多くの企業で共通して採用されているセキュリティ要件
　⇒マネージドセキュリティ要件

②組織固有：その会社のビジネス・組織・リスク許容度に基づくセキュリティ要件
　⇒カスタムセキュリティ要件

マネージドセキュリティ要件

マネージドセキュリティ要件は、 AWS が共通要件をもとに定義した標準のセキュリティ要件セットです。 各要件は、設計や実装を評価するための基準として定義されています。

AWS Security Agent はこれらの要件を使って、設計書やコードを機械的に評価します。

この画面キャプチャは、マネージドセキュリティ要件 が 「人向けのガイドライン」ではなく、 AWS Security Agent が解釈・評価できる仕様として定義されていることを示しています。

各セキュリティ要件には、

• どの種類のリソースや設計に適用されるのか
• どの状態を「準拠」と判断するのか
• 有効化・無効化・カスタマイズが可能か

といった情報が明示されており、 Design Review や Code Review において機械的に評価できる構造になっています。

カスタムセキュリティ要件

企業は、マネージドセキュリティ要件 をベースに、 自社固有のセキュリティ要件を同じ形式で定義できます。

下の画面は、AWS マネージドのセキュリティ要件を起点に、 組織固有の判断をカスタマイズ要件として追加・調整できることを示しています。

マネージドセキュリティ要件、カスタムセキュリティ要件は そのまま Design Review / Code Review / Penetration Testing の評価基準として使われます。

セキュリティ要件を開発プロセスに組み込む

ここからは、前章で定義したセキュリティ要件が、 実際の開発プロセスの中でどのように適用されるのかを見ていきます。

なお、AWS Security Agent は Pull Request を用いた一般的な開発フローを前提に設計されています。 そのため、Pull Request ベースでコードレビューを行うリポジトリ上のコードが評価対象になります。

Design Review：設計段階からのセキュリティ評価

Design Review の説明に入る際、講師はこう述べていました。

"This is not about finding issues at the end. It's about preventing them before the code even exists."

AWS Security Agent は、設計ドキュメントを入力として、 各セキュリティ要件に対し

• Compliant
• Not applicable
• Insufficient data
• Not compliant

を判定します。 重要なのは、コードを書く前にセキュリティ上の制約が可視化される点です。 セキュリティレビューを後工程に押し込まない、という思想が明確でした。

AWS 内部でも、設計段階で問題を検出できたことで、 後工程での大きな手戻りを避けられたと紹介されていました。

Code Review：すべての Pull Request に自動適用されるセキュリティチェック

Code Review は、設計時に定義された要件が 実装段階でも守られているかを継続的に確認する位置づけです。 Code Review では、AWS Security Agent がすべての Pull Request を自動で評価します。 ここでの講師の発言が印象的でした。

"Every pull request deserves the same level of security review. Not just the ones a human has time to look at."

設計段階と同じ要件セットでレビューされるため、 人によるレビューのばらつきが排除されます。

Penetration Testing Agent：ペネトレーションテストの自動化

この図は、AWS Security Agent によるペネトレーションテスト（ペンテスト）が、 単発のスキャンではなく、複数のエージェントが連携する 一連の自動プロセスとして実行されることを示しています。

ペンテストの説明に入る際、次の発言がありました。

"Penetration testing shouldn't be a calendar event."

AWS Security Agent のペンテストは、以下をエージェントループとして回します。 図中の各エージェントは、それぞれ次の役割を担っています。

• 計画（Planning Agent）
• 実行（Agentic Pentesters）
• 妥当性検証（Validators）
• 修正Pull Requestの生成（Remediation Agent）

AWS Security Agent の設計思想が最も表れているポイント

人に任せない前提で要件を適用する

セッションでは、社内での実運用を通じて得られた教訓として、 次のような考え方が示されていました。

"If we just tell teams to use the right library, it won't scale. The agent has to enforce it."

セキュリティ要件や標準を「使ってほしい」と伝えるだけでは、 組織規模では必ずばらつきが生まれます。 AWS Security Agent は、それらの判断を人に委ねるのではなく、 実際に守られているかを仕組みとして検証・強制することを前提に設計されています。

未完成なドキュメントも評価対象にする

Security Agent の特徴は、整った設計書を前提としない点です。 Feature Request や議事録のデモに入る前、講師はこう述べていました。

"This is super useful when you don't even have a proper design doc yet."

たとえば、Pull Request に添付されるドキュメントや、 リポジトリ内で管理される設計メモ・議事録であっても、 AWS Security Agent はそれらを入力として扱います。 外部公開・認証未定義・監査ログ不備といった要素は、 その時点でセキュリティ要件に照らして評価され、 「未決定」であること自体がリスクとして可視化されます。

作成途中の段階であっても、AWS Security Agent がセキュリティ要件に照らして評価を行い、 未決定事項をリスクとして可視化し続ける点で、非常に実務的だと感じました。

まとめ

GitHub Copilot の自動レビューと似て見えますが、 AWS Security Agent は「コードを書く人を支援する仕組み」ではなく、 「組織としてのセキュリティ判断を一貫して適用する仕組み」である点が決定的に異なります。 技術的な要点は次のとおりです。

• セキュリティ要件を「文章」ではなく「評価可能な仕様」として扱う
• 設計・コード・テストを同一の基準で評価する
• 社内標準を人の判断に委ねず、仕組みとして強制できる

AWS Security Agent は、セキュリティ自動化ツールというよりも、 セキュリティ要件の運用そのものを再設計する試みだといえます。

補足：実運用を考えたときの所感

AWS Security Agent は強力ですが、導入すれば即座に楽になる仕組みではありません。 マネージドセキュリティ要件は自社に合うか精査が必要ですし、 カスタムセキュリティ要件の定義・運用には一定の負荷がかかります。 また、導入初期はレビュー指摘が増え、煩わしく感じる場面もあるでしょう。

それでも本質は、 セキュリティ判断を人の裁量に任せず、 組織として明示化し、仕組みで適用し続ける点にあります。この点に、AWS Security Agent の思想的な価値を感じました。 AWS Security Agent は「便利な自動化ツール」というより、 組織のセキュリティ成熟度そのものを問う仕組みだと感じました。

この記事は私が書きました

河野 桂子

記事一覧

ヨシ！