【プレビュー版】AWS Security Agent のフルリポジトリコードスキャン機能をSAST・SCAと比較してみる

こんにちは。
アプリケーションサービス本部、DevOps担当の兼安です。
5月中旬にAWS Security Agent（以降、Security Agentと記載）の新しい機能、リポジトリ全体のコードレビューが発表されました。

aws.amazon.com

Security Agentは以前からプルリクエストに対してはコードレビューができていましたが、今回のアップデートで、リポジトリ全体に対してコードレビューができるようになりました。
今回はこの新機能を試してみます。
同機能は、本記事執筆時点（2026年5月下旬）ではプレビュー版です。
プレビュー版での検証内容であることをご了承ください。
この機能は、SASTのようなパターンマッチングによるスキャンにとどまらないのが特徴のようなので、実際にSASTそしてSCAによるスキャン結果と比較をしてみようと思います。

なお、SAST・SCAが何かはこちらをご覧ください。

AWS Security Agentのコードレビューを有効化する
サンプルコードとSAST・SCAの用意
AWS Security Agentのコードレビューを開始する
AWS Security Agentのコードレビューの検出結果
SAST・SCA、AWS Security Agentによる検出結果の比較
まとめ

AWS Security Agentのコードレビューを有効化する

まずは、AWSマネジメントコンソールでSecurity Agentを利用開始してみます。
東京リージョンで利用開始できます。

セットアップ画面で、エージェントスペース名やユーザーアクセス設定を行います。
今回は、簡易的な検証のため、IAM専用アクセスを選択します。
この下にあるサービスアクセス、暗号化、タグの設定は今回はデフォルトのままにします。

エージェントスペースが作成されました。

エージェントスペースの画面を開くと、設計レビューとコードレビューの機能が確認できます。
どちらもプレビューとありますね。

左ナビゲーションペインの「統合」でGitHubとの接続を確立しておきます。

統合の種類を選択します。
プレビュー版なせいかGitHubしかないですね。

画面の指示に従い、AWS Security Agent GitHub アプリケーションをインストール。
AWS Security Agent の認証も行います。

GitHub と AWS Security Agent GitHub の接続設定

先ほどのエージェントスペースの画面で、コードレビューの有効化を行います。
「コードレビューの有効化」をクリックすると、次の画面が表示されます。

「接続された統合」で「追加」をクリック。
先ほど作成したGitHub接続を選択して追加します。

現状、コードレビューはプライベートリポジトリとしかできないようなので、接続するリポジトリはプライベートのものにします。

コードレビューが有効化されているのを確認。

コードレビュー設定に戻ります。
閉じてしまった場合は、エージェントスペースのコードレビュータブを開き、「設定を編集」をクリックします。

コードレビュー設定画面で、下部にある「セキュリティ要件と脆弱性検出結果」を選択して次へ。

Optional configurationsは今回はデフォルトのままにして保存。
これで有効化作業は終了です。

設定が完了すると、エージェントスペースのコードレビューに「ウェブアプリで起動」のリンクが表示されるので、これをクリック。

ウェブアプリのナビゲーションペインに「コードレビュー」があるのが確認できます。
これで準備は完了です。

サンプルコードとSAST・SCAの用意

では、Security Agentにコードスキャンをしてもらうサンプルコードを用意します。
サンプルコードはPythonを使用した、FastAPI + AWS Lambda（Mangum）＋Amazon Aurora構成のAPIとします。
以下の脆弱性をあらかじめ仕込んでおき、どのように検出されるか見てみます。

SAST（パターンマッチ）で検出されそうなもの、SCA（依存関係チェック）で検出されそうなもの、AIコードスキャンでないと検出が難しそうなものを混在させて仕込んでおきます。
仕込んでおいた脆弱性のリストは後の検出結果の項で一緒に述べます。
このサンプルコードに対し、GitHub ActionsのワークフローでSAST・SCAを動かして検出した結果と、AWS Security Agentのコードレビューで検出した結果を比較してみます。

Python、SAST、SCAの情報は以下の通りです。
SASTとSCAはGitHub Actionsで実行し、そのログから検出結果を確認するとします。

項目	ツール名	バージョン
言語	Python	3.14
SAST	Semgrep（Community Edition）	1.163.0
SCA	pip-audit	2.10.0

AWS Security Agentのコードレビューを開始する

ウェブアプリの画面で、「コードレビューを作成する」をクリック。

コードレビューの作成画面が開くので、タイトルの入力やGitHubリポジトリを選択を行います。

「アクセス許可」でサービスロールを選択、「自動コード修正」を設定し、作成リンクをクリックします。

コードレビューができます。
タイトル部分のリンクをクリック。

コードレビューの画面が開くので、「レビューを開始する」をクリック。

これでリポジトリ全体に対してのレビューが始まります。

AWS Security Agentのコードレビューの検出結果

今回のサンプルコードに対してAWS Security Agentのコードレビューを実行したところ、約1時間で検出結果が出ました。
思ったより時間がかかりました。
想像以上に深く調査してくれるようです。

検出結果のタブで、「レポートを生成」をクリックすると、ダイアログが開きます。

ダイアログで「生成してダウンロード」をクリックすると、PDFがダウンロードできます。

PDFを開くとコードレビューの結果を詳しく見ることができます。

SAST・SCA、AWS Security Agentによる検出結果の比較

サンプルコードに事前に仕込んだ脆弱性と、Security Agentのコードレビューのレポート、そしてSAST・SCAによる検出結果を比較します。

SAST検出想定の脆弱性と検出結果

#	脆弱性名	実装パターン	SAST検出	Security Agent検出
1	SQLインジェクション	f-stringでSQL文を組み立て、ユーザー入力を直接埋め込む	❌ 未検出	✅ Critical
2	コマンドインジェクション	`subprocess.run(shell=True)` でユーザー入力を含むコマンドを実行	✅ 検出	✅ Critical
3	ハードコードされた秘密情報	DBパスワード・APIキーをソースコードに直接記述	❌ 未検出	✅ Critical
4	パストラバーサル	ユーザー指定のファイル名をパス検証なしで直接使用	❌ 未検出	✅ High
5	安全でないデシリアライゼーション	`pickle.loads()` でユーザー入力をデシリアライズ（任意コード実行可能）	✅ 検出	❌ 未検出

SASTのSemgrep Community Editionでは、SQLインジェクション・ハードコードされた秘密情報・パストラバーサルを検出しませんでした。
例えばSQLインジェクションは、今回のサンプルコードではf-stringで組み立てたSQL文を自作のラッパー関数経由で実行していたため、うまくパターンマッチしなかったのだと思われます。
これについては、Semgrep Pro Editionであれば検出できていた可能性が高いです。
SASTが検出できなかったものでもSecurity Agentが検出してくれましたが、同時に逆もあったのでSecurity Agentが完全に優位とはなりませんでした。

SCA検出想定の脆弱性と検出結果

#	脆弱性名	実装パターン	SCA検出	Security Agent検出
6	脆弱な依存関係	既知CVEのある古いバージョンを指定（requests 2.25.0、Jinja2 2.11.0）	✅ 検出（18件）	△ 推移的依存関係は検出せず

SCAのpip-auditでは、意図的に含めたrequests 2.25.0とJinja2 2.11.0に加え、推移的依存関係のidnaとurllib3の脆弱性も検出されました（合計18件のCVE、4パッケージ）。
Security Agentはrequests（CVE-2023-32681）とJinja2（CVE-2024-22195、CVE-2019-10906）の脆弱性は指摘しましたが、推移的依存関係（idna、urllib3）のCVEには言及していません。
入り口となる脆弱性が検知されているならば、結果的には同じ効果があるとも言えますが、現状、依存関係の網羅的なチェックについてはSCAツールの方が安心感があるように思えます。

AIコードスキャン検出想定の脆弱性と検出結果

#	脆弱性名	実装パターン	SAST検出	SCA検出	Security Agent検出
7	IDOR（安全でない直接オブジェクト参照）	認証済みユーザーIDとリソースIDの一致を検証しない	❌	❌	✅ High
8	権限昇格	ロール変更時に現在のユーザー権限を検証しない	❌	❌	✅ Critical
9	TOCTOU（Time-of-Check to Time-of-Use）	ファイル存在確認と操作の間にタイムウィンドウが存在	❌	❌	✅ Medium
10	不適切なエラーハンドリング（Fail-Open）	権限チェック例外時にデフォルトでアクセスを許可	❌	❌	✅ High
11	SSRF（Server-Side Request Forgery）	ユーザー指定URLへのリクエスト時にURL検証を一切行わない	❌	❌	❌ 未検出

AIコードスキャン検出想定のものは、予想通りSAST・SCAいずれでも検出されませんでした。
Security Agentはこれらを検出してくれましたが、SSRFだけは検出されませんでした。
このSSRFのコードですが、後で見返したところ、どのエンドポイントからも呼び出されない到達不能コードになっていました。
到達不能コードであったために検出対象外になった可能性があり、ある意味妥当な結果かもしれません。

想定外に検出されたもの

Security Agentは、意図的に仕込んだ脆弱性以外にも以下の問題を検出しました。
今回のサンプルコードは実運用を強く想定したものではないために混入したものですが、それらもしっかり検出してくれました。

#	脆弱性名	重大度	内容
12	Aurora RemovalPolicy.DESTROY	High	CDKスタックでDBクラスターにDESTROYポリシーが設定されており、スタック削除時にデータが消失
13	CIセキュリティゲートのバイパス	Medium	`continue-on-error: true`によりSAST/SCAの検出結果がCIを止めない
14	監査ログの完全な欠如	High	アプリケーション・インフラ両方でセキュリティイベントのログが一切ない

特筆すべきは、Security Agentが単独のコードファイルだけでなく、AWS CDKのインフラ定義（TypeScript）やGitHub Actionsのワークフロー（YAML）まで横断的にスキャンし、アプリケーションコードとインフラ設定の不整合を指摘している点です。

まとめ

AWS Security Agentのリポジトリ全体のコードレビューを試したところ、SAST・SCAとは異なるアプローチで深くレビューしてくれることがわかりました。
ただし、SAST・SCAによるルールベースのチェックの方が有効な箇所も見つかりました。
GAの際には改善される可能性がありますが、現状ではSAST・SCAとAWS Security Agentは相互補完の関係であると捉えて、CIでSAST・SCAを実行した上で、AWS Security Agentにコードレビューを通すのが妥当と思われます。

さて、このAWS Security Agentのコードレビューですが、検出結果の画面にコードの修正というリンクがあります。
次回はこれを試してみます。