はじめに
AWS関連の有志の皆様の re:Invent 2025 のポストを眺めてキャッチアップすることしかできないので、少しでも実際に利用しての体験談を残します。
P.S
早速中の人に対応してもらえそうです^^
背景
従来のSAST/DASTツールは 一次元的 であり、アプリケーションの設計やセキュリティ脅威、実行環境を理解していません。その結果、セキュリティチームは手動レビューに追われ、ペネトレーションテストも数週間待ちになることがあります。
このような課題を解決するために、AWSは AWS Security Agent をプレビュー版として発表しました。
概要
AWS Security Agent は、設計から本番デプロイまでの開発ライフサイクル全体でアプリケーションを積極的に保護する コンテキスト認識型 のフロンティアエージェントです。主な機能は以下の3つです。
- デザインレビュー - コードが書かれる前にアーキテクチャドキュメントを分析してセキュリティリスクを特定
- コードレビュー - GitHubのプルリクエストを分析してセキュリティ脆弱性と組織ポリシー違反を検出
- オンデマンドペネトレーションテスト - マルチステップの攻撃シナリオを通じて包括的なセキュリティテストを実行
今回、このAWS Security Agentを実際に試してみました。その結果、興味深い 誤検知（False Positive） に遭遇したので、その調査過程と結論を共有します。
内容
試験対象の環境構成
今回試験を実施した環境は以下の構成です。
- ドメイン - app.example.com（※事例用FQDN）
- インフラ - AWS ALB（Application Load Balancer）
- 証明書 - AWS Certificate Manager（ACM）で発行
- DNS - Route 53でALBへのエイリアスレコードを設定
報告された脆弱性
AWS Security Agentによるペネトレーションテストの結果、以下の脆弱性が報告されました。
| 項目 | 内容 |
|---|---|
| タイプ | SECURITY_MISCONFIGURATION |
| 名前 | 証明書ホスト名の不一致 - TLS信頼検証失敗 |
| 重大度 | CRITICAL |
| 総合評価 | M（証明書/信頼性の問題） |
※日本語翻訳しています
報告書には「サーバーが提示したSSL証明書は要求されたホスト名と一致しておらず、証明書はAWS EC2のデフォルトホスト名（ec2-xx-xxx-xx-xxx.us-west-2.compute.amazonaws.com）に対して発行されている可能性が高い」と記載されていました。
しかし、ALBでACMを利用しているため、この報告には疑問を感じました。
調査プロセス
1. Route 53の設定確認
まず、DNS設定を確認しました。
| 項目 | 設定値 |
|---|---|
| レコード名 | app.example.com |
| タイプ | A（エイリアス） |
| ルーティング先 | my-app-alb-xxxxxxxx.us-west-2.elb.amazonaws.com |
Route 53の設定は正しくALBを指していました。
2. IPアドレスの逆引き検証
次に、報告書で指摘されていたIPアドレスの逆引きを確認しました。
$ nslookup xx.xxx.xx.xxx
名前: ec2-xx-xxx-xx-xxx.us-west-2.compute.amazonaws.com
Address: xx.xxx.xx.xxx
$ nslookup my-app-alb-xxxxxxxx.us-west-2.elb.amazonaws.com
名前: my-app-alb-xxxxxxxx.us-west-2.elb.amazonaws.com
Addresses: xx.xxx.xx.xxx
xx.xxx.xx.xxx
xx.xxx.xx.xxx
xx.xxx.xx.xxx
ここでAWSあるあるなのですが、ALBのIPアドレスを逆引きすると、すべて ec2-*.compute.amazonaws.com という形式で返される のですが、これはAWSの正常な動作であり、ALBは内部的にEC2インフラ上で動作しているためです。
3. 証明書の直接確認
最終確認として、ブラウザで実際の証明書を確認しました。
| 項目 | 確認結果 |
|---|---|
| 証明書チェーン | Amazon Root CA 1 → Amazon RSA 2048 M03 |
| 発行先 | app.example.com |
| SAN（サブジェクトの代替名） | DNS名: app.example.com ✅ |
証明書のSANフィールドに 対象ドメインが正しく含まれている ことを確認できました。
結論：誤検知（False Positive）
調査の結果、この脆弱性報告は 誤検知 であると判断しました。
| レポートの主張 | 実際の状況 |
|---|---|
| 証明書のSANにドメインが含まれていない | 含まれている |
| EC2ホスト名用の証明書を使用 | ACMで正しいドメイン用に発行 |
| 証明書の信頼検証失敗 | 正常に検証成功 |
誤検知の原因
スキャナーがALBのIPアドレスを逆引きした際に ec2-*.compute.amazonaws.com が返されたことを、EC2への直接接続と誤認した可能性が高いです。これはAWSインフラの正常な動作であり、セキュリティ上の問題ではありません。
終わりに
AWS Security Agentは強力なセキュリティツールですが、今回のようにAWSインフラ特有の動作を誤検知するケースも存在します。セキュリティスキャンの結果は重要な参考情報ですが、最終的な判断は人間が行う必要があります。
特にALB + ACMの構成でTLS証明書の問題が報告された場合は、今回紹介した調査手順（Route 53設定確認 → IP逆引き検証 → 証明書の直接確認）が参考になれば幸いです。
誤検知を適切に識別し、真の脆弱性に集中することで、限られたセキュリティリソースを効率的に活用しましょう。
一言
もしこの記事が気に入って頂けたらここでのいいね＆フォローとX( @___nix___ )でのフォローもお願い致します。