1. はじめに

皆さん、こんにちは。クラウド技術部のR.Aです。

昨今、設定の誤りによる公開範囲や権限の問題がセキュリティインシデントにつながり、取引先や監査からどの基準にどこまで準拠しているかを文書で示すよう求められるようになっています。
その時に使うのが、設定をコンプライアンス基準に照らして自動で評価するCSPM製品です。
今回はAWSにおける主要なCSPMである以下の3製品の、AWS Foundational Security Best Practices v1.0.0基準の出力結果を比較しました。

1. AWS Security Hub
2. Prowler
3. Steampipe

目次

1. はじめに
2. 検証環境・前提
   1. 検証環境
   2. 用語
3. 検証内容
   1. 各製品のスキャン実行
   2. 基準の比較方法
   3. 比較マトリクス作成の流れ
4. 検証結果
   1. 管理策カバレッジ
   2. 判定不一致
   3. リソース種別ごとの検出数
   4. 3製品すべてがFAILの79通り
5. 分析結果
   1. 管理策カバレッジからわかること
   2. 判定不一致からわかること
   3. 検出数からわかること
   4. 全会一致FAILからわかること
6. おわりに

---

2. 検証環境・前提

記事中のAWSアカウントID・リソース名・リソースIDは公開にあたって別の値へ置き換えています。
引用の中の識別子も同じ規則で置き換えており、それ以外の文字列は取得した値のままです。

2.1 検証環境

表1に検証環境をまとめます。

表1: 検証環境

項目	内容
対象基準	AWS Foundational Security Best Practices(全411管理策)
対象製品	AWS Security Hub / Prowler / Steampipe
対象アカウント	単一のAWSアカウント、ap-northeast-1リージョン
データ取得日	3製品とも同一日
突合キー	リソースのARN
AWS Configの状態	2026-01-22にレコーダーが停止しており、スキャン時点で無効

前提として押さえておく点を挙げます。

1. AWS Configのレコーダーが停止していること
   • FSBPではこの影響が最も大きく出ます。(詳細は 5.1章を参照)
2. Security Hubの公式定義は、ap-northeast-1を主として取得し、us-east-1を補足に使うこと
   • Security Hubの describe-standards-controls は、そのリージョンで有効な管理策しか返しません。
   • CloudFrontやWAFのようなグローバルサービスの管理策はus-east-1でしか返らず、東京だけでは公式対応の一覧から抜け落ちます。
   • 何が評価され得る管理策なのかを取りこぼさないため、両リージョンの和を公式定義として扱っています。今回はus-east-1でのみ返った管理策が20ありました。
3. 判定はap-northeast-1で取得した分のみであること
   • 公式定義と取得範囲がずれるため、us-east-1でしか評価されない管理策は公式対応に載るが判定が無い状態になります。(詳細は 5.1章を参照)
4. Service Screener V2はこの比較に参加していないこと
   • FSBPの管理策番号へ対応させる表を持っていません。

2.2 用語

表2に、CSPMやコンプライアンス基準の文脈で一般的に使われる用語をまとめます。

表2: 一般的に使われる用語

用語	定義	備考
基準	セキュリティ設定の要求事項をまとめたもの	今回はAWS Foundational Security Best Practices。AWSが自社で定義した基準
管理策	基準を構成する個々の要求項目を表したもの	FSBPには411ある。`S3.5`、`ECR.1` のようにサービス名と連番で表される
スキャン	各製品を1回実行すること、およびその出力のこと	チェックの実行単位ではなく、実行そのものを指す
チェック	管理策を判定するために製品が実装した処理のこと	Security Hubは管理策番号がそのままチェック名になる。Prowlerは `ecr_repositories_scan_images_on_push_enabled` など
判定	チェックを実行した結果のこと	PASS(問題なし)とFAIL(問題あり)のほかに、手動確認や対象外がある
カバレッジ	製品が基準の管理策をどこまで評価できるかを表したもの	状態の種類は表4

表3に、この記事で意味を決めて使う用語をまとめます。
※製品側の呼び方ではなく、比較を説明するために定義したものです。

表3: この記事で定義した用語

用語	定義	備考
公式定義	製品が公開している「どの管理策に自動チェックを持つか」の一覧のこと	Security Hubは `describe-standards-controls` の応答、ProwlerとSteampipeは同梱の定義ファイルです
評価対象	判定が向けられている先のこと	今回はリソース単位が1,647、アカウント単位が289ありました
比較マトリクス	3製品の判定を、管理策と評価対象の組み合わせごとに並べた表のこと	自作した突合スクリプトの出力です。今回は1,936通りで、同じ管理策でも評価対象が違えば別の組み合わせになります
名寄せ	製品ごとに書き方が違うリソースの識別子をARNへ揃え、同じ対象への判定を1つの組み合わせにまとめること	3製品ともARN形式で出すため、識別子の組み立ては不要です
縮約	1つの管理策を複数のサブチェックで評価している製品の判定を、「1つでもFAILなら全体としてFAIL」に畳み込むこと	縮約前は53通り、縮約後は43通りです
判定不一致	同じ組み合わせで2製品以上が判定を出していて、PASS/FAILの結論が異なっている状態のこと	今回は43通りありました
全会一致FAIL	同じ組み合わせで、対象の全製品がFAILと判定している状態のこと	今回は79通りありました

表4に、カバレッジの状態の種類をまとめます。
この記事では管理策ごとに、製品がどの状態だったかを数えています。

表4: カバレッジの状態

状態	定義	備考
公式対応	公式定義にこの管理策の自動チェックがあること	環境によらず決まる
評価済	公式対応があり、今回のスキャンで判定が出たこと	環境によって変わる
評価済(裏付けなし)	PASSを返しながら、判定の裏付けが無いと製品が自己申告していること	Security Hubのみ。理由コード `CONFIG_EVALUATIONS_EMPTY`。今回は223
手動確認	製品が「自動評価の対象外」と報告したこと	人が確認する項目
出力なし(全製品)	公式対応はあるが判定が1件も出ず、他の製品も同じ対象を検出していないこと	対象リソースがこの環境に無い場合が多い
出力なし(他製品は検出)	公式対応はあるが判定が1件も出ず、他の製品は同じ対象を検出していること	検知範囲から外れている疑いがある
出力なし(取得範囲外)	公式定義には載るが、判定を取得したリージョンの外でしか評価されないこと	Security Hubのみ。今回は20(詳細は 5.1章を参照)
スキップ	製品が実行を飛ばしたと報告したこと	Steampipeのみ。今回は16
機能なし	公式定義にこの管理策のチェックが無いこと	製品がこの管理策を評価できない
要調査	公式定義に無いはずの管理策に判定が存在すること	Security Hubのみ。今回は1(`ELB.1`)

数を数えるときの単位に注意してください。

• カバレッジの数字は管理策の数
• 比較マトリクスの数字は組み合わせの数
• 同じ「411」でも指しているものが違う

---

3. 検証内容

3.1 各製品のスキャン実行

各製品のスキャン出力から、FSBPの判定だけを抽出した結果が表5です。

FSBPの判定として扱う条件は、製品ごとに次のとおりです。

• Security Hubは、Compliance.AssociatedStandards の StandardsId に aws-foundational-security-best-practices を含む判定を対象にする
• Prowlerは、基準ごとにファイルが分かれるため scan_prowler_fsbp.csv の全行を対象にする
• Steampipeは、scan_steampipe_fsbp.json を読み、各コントロールの識別子を管理策番号として使う

数字の読み方を補足します。

• 全体件数
  • 各製品のスキャン出力ファイルの行数
• FSBP
  • 同じファイルから、上の条件に当てはまる判定の件数
• 全体件数は製品ごとに単位が違う。Security HubはFindingsの数、ProwlerとSteampipeは取得した全基準分の出力を合わせた判定数
• Steampipeの1,604は、対象リソースが0件の管理策に184件を補った数。JSON上の判定は1,420件

表5: 各製品の取得データとFSBPの抽出結果

製品	取得したもの	全体件数	FSBP
Security Hub	Findings(APIで全件取得、72ページ)	7,124	1,337
Prowler	基準ごとのコンプライアンスCSV	42,783	894
Steampipe	基準ごとのJSON	68,366	1,604

この3つを名寄せした結果が、1,936通りの組み合わせです。

実行時の条件を挙げます。

• Prowlerには --scan-unused-services を付けていない
• Security Hubの公式定義は、ap-northeast-1を主として取得し、グローバルサービスの管理策を取りこぼさないためus-east-1を補足に使う
• Security Hubの判定はap-northeast-1で取得した分のみ

3.2 基準の比較方法

この記事には、製品が提供するものと、自作したものが混ざって出てきます。
先に区別しておきます。

製品が提供するもの

• 各製品のスキャン出力(Security HubのFindings、ProwlerのCSV、SteampipeのJSON)
• 各製品の公式定義(Security Hubは describe-standards-controls の応答、ProwlerとSteampipeは同梱の定義ファイル)
• 各製品のチェック実装のソースコード

自作したもの

• 突合スクリプト(表6の5段階を実行する)
• 比較マトリクス(突合スクリプトの出力)

3.3 比較マトリクス作成の流れ

製品ごとにレポートの形が違うため、そのままでは並べられません。
表6の5段階で同じ形に揃えます。

表6: 比較の手順

段階	処理	出力
1. 抽出	各製品のレポートから管理策番号・リソース・PASS/FAILを取り出す。公式定義も別に取り出す	製品ごとの判定一覧と公式定義
2. 番号の正規化	製品ごとの管理策番号をFSBPの番号へ揃える	同じ番号体系に揃った判定一覧
3. 名寄せ	リソースの識別子をARNへ揃え、同じ対象への判定を1つの組み合わせにまとめる。ARNを持たない判定は疑似ARNを立てる	比較マトリクス(1,936通り)
4. 縮約	複数のサブチェックの判定を「1つでもFAILなら全体としてFAIL」に畳み込む	製品ごとに1つに定まった判定
5. 検証	比較マトリクスの全組み合わせを生データと再照合する	不整合の一覧(今回は0件)

段階3と段階4の補足を挙げます。

• 3製品ともARN形式でリソースを出すため、識別子の組み立ては不要
• FSBPは管理策番号がサービス名と連番のため、CIS系のような枝番の正規化は起きない
• 段階5の検証では、1,936通りすべてで生データとの不整合は0件

名寄せの共通キーにARNを選んだ理由

3製品ともARN形式で評価対象を出しているため、ARNを共通キーにしました。

• 評価対象をARNで示しているのは、Security Hubが1,337件中1,096件、Prowlerが894件中789件、Steampipeが1,420件中1,205件
• ARNにならない残りはアカウント全体を指す判定と、手動確認に回された判定で、疑似ARNを立てている
• Security Hubの疑似ARN241件はすべてアカウント単位
• Prowlerの疑似ARN105件は手動確認80件とアカウント単位25件
• Steampipeの疑似ARN215件はすべてアカウント単位
• 比較マトリクス1,936通りのうち、どの製品も判定を出していない行は101通り

---

4. 検証結果

検証結果の事実を記載します。分析は5章に書きます。

4.1 管理策カバレッジ

表7に、各製品がFSBPの411管理策をどこまでカバーしたかをまとめます。
数字は管理策の数です。

• 公式対応
  • 各製品の公式定義。Security Hubは describe-standards-controls の応答、ProwlerとSteampipeは同梱の定義ファイル
• 評価済以降
  • 上の公式定義と、実際のスキャン結果を管理策ごとに突き合わせた数

表7: 管理策カバレッジ(全411管理策)

製品	公式対応	評価済	評価済(裏付けなし)	手動確認	出力なし	スキップ	機能なし
Security Hub	366	119	223	0	24	0	44
Prowler	206	114	0	1	91	0	205
Steampipe	339	138	0	1	184	16	72

表7の読み方を挙げます。

• Security Hubの出力なし24の内訳は、取得範囲外が20、全製品が2、他製品は検出が2。取得範囲外の20はCloudFront系で、詳細は 4.2.4章を参照
• Security Hubはこのほかに要調査が1つ(ELB.1)ある。公式対応366と機能なし44と要調査1を足すと411になる
• Prowlerは411のうち205に公式定義のチェックが無い。評価できる範囲が他の2製品より狭い
• Steampipeの出力なし184は、対象リソースがこの環境に無い管理策が大半

---

4.2 判定不一致

表8に、判定不一致43通りのうち、同じ管理策で複数の組み合わせで判定が異なったものをまとめます。
残る20の管理策は各1通りです。

• 通り
  • 比較マトリクスのうち、2製品以上が判定を出していて結論が異なった組み合わせの数
• 判定の並び
  • 同じ管理策の中で最も多い並び

表8: 判定不一致が複数出た管理策

管理策	内容	通り	判定の並び	詳細
ECR.1	ECRリポジトリのイメージスキャン設定	6	Security HubがPASS、ProwlerがFAIL、SteampipeがPASS	4.2.1章
SecretsManager.4	シークレットの一定期間内のローテーション	6	Security HubとSteampipeが逆。Prowlerは公式定義に無い	4.2.1章
SSM.1	EC2インスタンスのSystems Manager管理	5	Security HubがFAIL、ProwlerがPASS、Steampipeが手動確認	4.2.2章
SecretsManager.1	シークレットの自動ローテーション	4	Security HubとProwlerがFAIL、SteampipeがPASS	4.2.1章
S3.12	S3のACLによるアクセス管理の禁止	2	Security HubがPASS、ProwlerがFAIL、SteampipeがPASS	4.2.1章

---

4.3 リソース種別ごとの検出数

表9に、リソース種別ごとに各製品が検出したARNの数をまとめます。
判定が異なる点とは別に、そもそも各製品が同じリソースを見ているかを確認するためです。

• 各製品の列
  • 比較マトリクスで、その製品が判定を出しているリソースのARNの、重複を除いた数
• 総数
  • 3製品が検出したARNの和集合の要素数。AWSへ問い合わせた値ではない

表9: リソース種別ごとの検出数(上位10)

リソース種別	総数	Security Hub	Prowler	Steampipe
IAMロール	209	209	61	116
IAMポリシー	183	94	162	94
Lambda関数	35	35	35	35
セキュリティグループ	26	26	17	26
ネットワークインターフェース	26	10	0	11
CloudFormationスタック	24	6	0	24
サブネット	24	24	14	24
S3バケット	12	12	12	12
VPC	9	9	6	9
ネットワークACL	9	9	9	9

---

4.4 3製品すべてがFAILの79通り

表10に、3製品すべてがFAILで一致した79通りの内訳をまとめます。
評価方式が違っても共通して検出された設定です。

表10: 全会一致FAILの内訳(合計79通り)

管理策	内容	通り
S3.9	S3のサーバーアクセスログ	12
S3.13	S3のライフサイクル設定	10
S3.5	S3のTLS必須化	9
ECR.2、ECR.3	ECRのタグ変更不可設定とライフサイクルポリシー	各6
EC2.10、EC2.6	VPCエンドポイントとVPCフローログ	各5
EC2.3、RDS.4	EBSの暗号化とRDSスナップショットの暗号化	各4
IAM.8、SecretsManager.1	未使用の認証情報とシークレットの自動ローテーション	各3
その他14の管理策	CloudTrail、EC2、IAM、Lambda、RDSの各設定	各1

---

5. 分析結果

5.1 管理策カバレッジからわかること

FSBPは411管理策と数が多く、カバレッジの読み方で結論が変わります。
判定を出した数だけを見ると実態を外す要因が3つありました。

AWS Configの停止でSecurity HubのPASSの多くが裏付けを持たない

表7で、Security Hubの評価済119に対して評価済(裏付けなし)が223あります。
裏付けなしのほうが多い状態です。

読み取れることを挙げます。

• この環境ではAWS Configのレコーダーが2026-01-22に停止している
• Security HubのコントロールはAWS Configのルールを使って評価するものが多く、記録が無いと評価結果が空になる
• 評価結果が空のままPASSが返るため、PASSの件数だけを見ると準拠している管理策が実態より多く見える
• CIS v1.4.0では裏付けなしが2つ、v3.0.0とv5.0.0では3つだった。FSBPは対象サービスが広いぶん、影響が大きく出る

Security HubのPASSを準拠の根拠として扱う場合は、AWS Configの稼働状態と、Findingの StatusReasons を併せて確認することになります。

---

CloudFront系の管理策はこの取得範囲に入らない

表7で、Security Hubの出力なし24のうち20が取得範囲外です。

該当する管理策は CloudFront.1 から CloudFront.17 までと EC2.173 です。

読み取れることを挙げます。

• CloudFrontはグローバルサービスで、Security Hubの評価はus-east-1で行われる
• 今回の判定はap-northeast-1で取得した分のみのため、これらの管理策には判定が存在しない
• 公式定義はap-northeast-1とus-east-1の和で取っているため、公式対応には載る
• 製品の機能不足ではなく、取得の仕方による欠落として区別している

---

Prowlerは411管理策のうち205にチェックを持たない

表7で、Prowlerの公式対応は206、機能なしは205です。
FSBPの管理策のほぼ半分にチェックがありません。

読み取れることを挙げます。

• FSBPはAWSが自社サービス向けに定義した基準で、対象サービスの数が多い
• Security Hubは自社基準のため366をカバーし、Steampipeは339をカバーしている
• Prowlerが206にとどまるのは、FSBPのマッピングに載せているチェックの数がそのまま出た結果
• 判定不一致が43通りと少なめなのは、Prowlerが判定を出さない管理策が多く、2製品以上が判定を出す組み合わせが少なくなることも一因

---

5.2 判定不一致からわかること

判定が割れた43通りは、基準の解釈の違いよりも、見ている属性そのものの違いから生まれていました。

同じリソースについてProwlerとSteampipeが逆の事実を報告する

FSBPで目立ったのは、同じリソースの同じ属性について、2つの製品が正反対の事実を述べているケースです。
表11にまとめます。

表11: ProwlerとSteampipeが逆の事実を報告した管理策

管理策	Prowlerが示した理由	Steampipeが示した理由
ECR.1	ECR repository awscli-install_ecr has scan on push disabled.	awscli-install_ecr scan on push enabled.
SecretsManager.1	SecretsManager secret karakama-secret has rotation disabled.	karakama-secret automatic rotation enabled.
S3.12	S3 Bucket cloudtrail-evaluationreq-awslog has bucket ACLs enabled.	cloudtrail-evaluationreq-awslog does not have ACLs for user access.

読み取れることを挙げます。

• 3件とも、同じ名前のリソースに対して有効と無効が異なっている
• ECR.1とS3.12では、Security HubがSteampipe側(PASS)に付いている
• SecretsManager.1では、Security HubがProwler側(FAIL)に付いている

どちらが事実に合うかを確かめるため、AWS CLIで該当リソースの設定を読みました。
結果を表12にまとめます。

表12: ライブ環境で確認した値と、事実に合う判定

管理策	確認したAPIと値	事実に合う判定
ECR.1	`describe-repositories` の `imageScanningConfiguration.scanOnPush` が false	ProwlerのFAIL
SecretsManager.1	`describe-secret` の `RotationEnabled` が false	Security HubとProwlerのFAIL
S3.12	`get-bucket-ownership-controls` は設定が見つからないという応答、`get-bucket-acl` のGrantsは所有者へのFULL_CONTROLのみ	どちらも事実として正しい

ECR.1とSecretsManager.1は、Prowlerの判定が事実に合っていました。

• ECR.1では、対象リポジトリの scanOnPush が false。SteampipeとSecurity HubのPASSは、この環境の設定と合わない
• SecretsManager.1では、RotationEnabled が false。ただし RotationLambdaARN と RotationRules(7日ごと)は設定されたまま残っており、LastRotatedDate も記録されている
• Steampipeの理由文が automatic rotation enabled だったのは、ローテーションの仕組みが設定されていることを見ているためと考えられる。実装は確認していないため推測である

S3.12は、両方の言い分が事実として成り立っていました。

• get-bucket-ownership-controls は設定が見つからないという応答で、ACLの仕組みは有効な状態
• get-bucket-acl のGrantsは所有者へのFULL_CONTROLだけで、他のユーザーへの付与は無い
• Prowlerは前者を見て「ACLが有効」としてFAIL、Steampipeは後者を見て「ACLでユーザーアクセスを管理していない」としてPASS
• S3.12の文面は「ACLをユーザーアクセスの管理に使わないこと」で、文面に近いのはSteampipeの読み方
• ACLそのものを無効にする(BucketOwnerEnforced)のがAWSの推奨で、そちらに沿うのがProwlerの読み方

SecretsManager.4は、同じ管理策の中でSecurity HubとSteampipeの判定が対象ごとに入れ替わる形でした。
あるシークレットではSecurity HubがPASSでSteampipeがFAIL、別のシークレットでは逆になります。
SecretsManager.1と同じく、ローテーションが有効かどうかと、ローテーションの仕組みが設定されているかどうかの違いによるものと考えられます。

---

停止中のEC2インスタンスで判定が割れる

SSM.1(EC2インスタンスのSystems Manager管理)で5通りで判定が異なりました。

text Security Hub: SSM.1 FAILED Prowler: ec2_instance_managed_by_ssm PASS EC2 Instance i-029007a9771d56fb4 is unmanaged by Systems Manager because ... Steampipe: 対象外(手動確認) yoshida-ec2-OL9 is in stopped state.

読み取れることを挙げます。

• Steampipeは停止中のインスタンスを自動評価の対象外として扱い、手動確認に回している
• Security Hubは停止中かどうかにかかわらずFAILとしている
• Prowlerの理由文は「Systems Managerに管理されていない」と述べながら判定はPASSで、理由と判定の向きが一致していない
• 停止中のリソースをどう扱うかが製品ごとに違い、それが不一致として現れる

---

5.3 検出数からわかること

表9で、同じリソース種別でも製品によって検出数が大きく違います。

読み取れることを挙げます。

• IAMロール209個をSecurity Hubは209個、Steampipeは116個、Prowlerは61個評価している。管理策ごとに対象の絞り方が違う
• ネットワークインターフェース26個とCloudFormationスタック24個は、Prowlerが0個。該当する管理策のチェックを持たない
• IAMポリシー183個は、Prowlerが162個で最も多い。Security HubとSteampipeは94個
• セキュリティグループとサブネットとVPCでProwlerが少ないのは、--scan-unused-services を付けていないため
• リソース種別ごとの検出数だけでは、検知漏れと管理策の担当違いを区別できない

---

5.4 全会一致FAILからわかること

3製品すべてがFAILで一致した79通りが、何個のリソースに対応するかを数えました。

• 79通りは44個のリソースに分かれている
• 1つのリソースに紐づく管理策は最も多いもので3つ
• 23の管理策のうち12は1通りだけ

評価対象のサービス別ではS3が31通り、EC2が15通り、ECRが12通り、RDSが9通りです。
S3の3管理策(S3.9、S3.13、S3.5)だけで31通りを占めます。
対象は12個のバケットで、うち9個は3つの管理策すべてに該当しています。

FSBPでは、件数がほぼそのまま対処すべき数になります。
1つの設定が多数の管理策へ広がる構造にはなっていないためです。

この点はFSBPの管理策の書かれ方によります。
FSBPはAWSが自社サービスの設定項目として定義した基準で、1つの管理策が1つの設定に対応します。
抽象的な統制を記述する基準では、同じ対象が管理策の数だけ数え直されるため、件数を問題の数として読めません。

---

6. おわりに

AWS Foundational Security Best Practicesを3製品で突き合わせた結果をまとめます。

• 判定が異なったのは1,936通りのうち43通り、25の管理策
• 同じリソースの同じ属性について、ProwlerとSteampipeが逆の事実を報告した管理策が3つあった。ライブ環境を読むと、ECR.1とSecretsManager.1はProwlerの判定が事実に合い、S3.12は両方の言い分が成り立っていた
• 停止中のEC2インスタンスの扱いが製品ごとに違い、それが不一致として現れる
• AWS Configが停止しているため、Security Hubが判定を出した342の管理策のうち223で、PASSが判定の裏付けを持たない
• CloudFront系の20管理策は、us-east-1でしか評価されないためこの取得範囲に判定が無い
• Prowlerは411管理策のうち205にチェックを持たない。基準によって製品のカバー範囲は大きく変わる
• 3製品すべてがFAILで一致したのは79通りで、44個のリソースに分かれている。件数がほぼ対処すべき数になる

同じように複数のセキュリティツールの結果を突き合わせている方の参考になれば幸いです。
今回の内容は弊社の検証環境における分析結果であり、環境によって結果は変わり得ることをご了承ください。
最後までご覧いただきありがとうございました！