prowler-compliance

Name: prowler-compliance
Author: prowler-cloud

github.com/prowler-cloudセキュリティ15.1k68 回インストール今日更新

リポジトリ

prowler-compliance について

prowler-complianceは、Prowlerのコンプライアンスフレームワークとチェックのマッピングを構築・保守する貢献者向けスキルです。スキーマの選択、読み込み、ガードレール、出力経路を説明します。

主な機能

01ユニバーサルとレガシーのスキーマ指針
02フレームワークと要件のモデル化
03チェックと統制のマッピング指針
04ConfigRequirementsのガードレール
05出力とフォーマッターの構成

活用シーン

01コンプライアンスフレームワークの追加
02プロバイダーへのフレームワーク拡張
03チェックマッピングの監査
04フレームワークの検出結果の調査

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/prowler-cloud/prowler --skill prowler-compliance

インストール後、Claude Code で/prowler-complianceを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

assets/

audit_framework_template.py

build_inventory.py

cis_framework.json

dump_section.py

ens_framework.json

generic_framework.json

iso27001_framework.json

mitre_attack_framework.json

prowler_threatscore_framework.json

query_checks.py

sync_framework.py

assets/configs/

ccc.yaml

assets/parsers/

__init__.py

finos_ccc.py

references/

check-mapping-reference.md

compliance-docs.md

詳細

使用するタイミング

次の場合にこのスキルを使用します。

任意のプロバイダー向けに新しいコンプライアンスフレームワークを作成するとき — まずユニバーサル方式かレガシー方式かを決めます（以下を参照）
既存のフレームワークを上流の信頼できる情報源と同期するとき（CIS、FINOS CCC、CSA CCM、NIST、ENS など）
既存のフレームワークに要件を追加するとき、またはユニバーサルフレームワークを新しいプロバイダーに拡張するとき
チェックをコンプライアンス管理策にマッピングするとき
ConfigRequirements ガードレールを追加して、設定可能なチェックが緩和された設定で要件を満たしたと誤認されないようにするとき
クラウド監査人として既存のチェックマッピングを監査するとき（「このマッピングは正しいか？」「どのチェックが適用されるか？」「マッピングをレビューする」）
新しいレガシー出力フォーマッターを追加するとき（テーブルディスパッチャー＋プロバイダーごとのクラス＋CSV モデル）
JSON の不具合を修正するとき：ID の重複、Version が空、Section の誤り、古いチェック参照、FamilyName の不整合、関連性の薄いチェックマッピングの過剰な追加
検出結果／チェックが UI 上で想定したコンプライアンスフレームワークに表示されない理由を調査するとき
コンプライアンスフレームワークの構造と属性を理解するとき

信頼できるコントリビューター向けドキュメントは docs/developer-guide/security-compliance-framework.mdx です。どちらかを変更するときは、このスキルとドキュメントの内容を一致させてください。コンプライアンス関連の PR をレビューする場合は、代わりに姉妹スキル prowler-compliance-review を使用してください。

ユニバーサル方式かレガシー方式か：最初に決めること

Prowler は2 つの JSON スキーマをサポートしています。選択を誤ると不要な Python コードが必要になるため、何よりも先に決めてください。読み込み時にはどちらも同じ形に統合されます。レガシーファイルはユニバーサルな ComplianceFramework モデルに変換されるため（adapt_legacy_to_universal()）、違いは Prowler の残りの部分から見える内容ではなく、作成コストと機能にあります。

比較

	ユニバーサル方式（新規フレームワークに推奨）	レガシー方式（プロバイダー固有）
ファイルの場所	`prowler/compliance/<framework>.json`（トップレベル）	`prowler/compliance/<provider>/<framework>_<version>_<provider>.json`
プロバイダー	任意の数に対応、1 ファイル（プロバイダーをキーとする `checks` 辞書）	1 ファイルにつきプロバイダーは 1 つ（複数のプロバイダーに対応するにはプロバイダーごとに 1 ファイル）
キーの形式	小文字（`framework`、`requirements`、`checks`）	先頭大文字（`Framework`、`Requirements`、`Checks`）
属性スキーマ	`attributes_metadata` を使ってJSON 自体に宣言し、読み込み時に検証	フレームワークファミリーごとの Pydantic クラスを `compliance_models.py` に定義（新しい形式にはコード変更が必要）
要件ごとの属性	1 つのフラットな辞書（`attributes: {...}`）	オブジェクトのリスト（`Attributes: [{...}]`）— 下流で使用されるのは `Attributes[0]` のみ
テーブル／CSV／OCSF 出力	`outputs.table_config` に基づくデータ駆動方式 — Python の変更は不要	フォーマッターパッケージと、`compliance.py`、`__main__.py`、`export.py` での登録
ガードレールのフィールド	`config_requirements`（各制約に `Provider` が必須）	`ConfigRequirements`（`Provider` は省略）
エラー時のローダー動作	寛容：ログを記録してファイルをスキップ（`load_compliance_framework_universal`）	失敗時に即終了：`sys.exit(1)`（`load_compliance_framework`）
読み込み元	`get_bulk_compliance_frameworks_universal()` のみ	両方のローダー（`Compliance.get_bulk()` およびユニバーサル方式、アダプター経由）
同梱例	`cis_controls_8.1.json`、`csa_ccm_4.0.json`、`dora_2022_2554.json`	その他すべて（11 プロバイダーにまたがる約 105 ファイル）

どちらを使うべきか

次のいずれかに該当する場合は、ユニバーサル形式を使用してください。

そのフレームワークがProwler では新しい場合 — 既存の属性クラスも、既存のフォーマッターもありません。これがデフォルトです。Python の変更は不要です。
そのフレームワークが複数のプロバイダーにまたがる、または今後またがる予定の場合 — DORA、CSA CCM、CIS Controls。すべてのプロバイダーを1つのファイルでカバーでき、新しいプロバイダーへの拡張は checks の1行編集で済みます。
属性の形式がこのフレームワーク固有の場合 — Union に Pydantic クラスを追加するのではなく、attributes_metadata で宣言してください。

既存のレガシー形式のファミリーを拡張する場合に限り、レガシー形式を使用してください。

リリース済みのレガシーフレームワークの新しいバージョン（AWS 向け CIS 8.0 では、新しい cis_8.0_aws.json、同じ CIS_Requirement_Attribute、同じ cis/ フォーマッターを使用します）。
新しいプロバイダー向けの既存のレガシーフレームワーク（m365 向け ENS では、新しい ens_rd2022_m365.json と ens_m365.py トランスフォーマーを使用します）。
ユニバーサル形式のメリットよりも、ファミリーとの一貫性が重要な場合 — cis_8.0_aws だけをユニバーサル形式にし、20個を超える CIS ファイルをレガシー形式のままにすると、ファミリーが分断されます。

次のことは避けてください：現時点で AWS だけだからという理由で、単一プロバイダー向けの新しいフレームワークをレガシー形式で始めないでください。ユニバーサル形式は単一プロバイダーでも問題なく扱えます（checks 辞書にキーが1つだけ含まれるだけです）。そのうえ、出力ファイル3つと登録3件を省略できます。

両方のスキーマでの同じ要件

ユニバーサル形式（prowler/compliance/my_framework_1.0.json）：

{
  "framework": "My-Framework",
  "name": "My Framework 1.0",
  "version": "1.0",
  "description": "...",
  "attributes_metadata": [
    {"key": "Section", "type": "str", "required": true},
    {"key": "Service", "type": "str"}
  ],
  "outputs": {"table_config": {"group_by": "Section"}},
  "requirements": [
    {
      "id": "MF-1.1",
      "name": "Root MFA",
      "description": "Root account must have MFA enabled.",
      "attributes": {"Section": "IAM", "Service": "iam"},
      "checks": {
        "aws": ["iam_root_mfa_enabled"],
        "azure": []
      }
    }
  ]
}

レガシー形式（prowler/compliance/aws/my_framework_1.0_aws.json — 追加のプロバイダーごとに別ファイルが必要で、さらにフォーマッターと登録も必要です）：

{
  "Framework": "My-Framework",
  "Name": "My Framework 1.0 for AWS",
  "Version": "1.0",
  "Provider": "AWS",
  "Description": "...",
  "Requirements": [
    {
      "Id": "MF-1.1",
      "Name": "Root MFA",
      "Description": "Root account must have MFA enabled.",
      "Attributes": [
        {"ItemId": "MF-1.1", "Section": "IAM", "Service": "iam"}
      ],
      "Checks": ["iam_root_mfa_enabled"]
    }
  ]
}

同じコントロールでも、ユニバーサル形式のファイルはすでに Azure をカバーし、独自の属性スキーマを検証し、コードなしでテーブル、CSV、OCSF をレンダリングします。各スキーマのフィールドごとの参照情報は以下のとおりです。

アーキテクチャ（概念モデル）

Prowler のコンプライアンスは4層のシステムです。通常、バグはある層が別の層と一致しないときに発生するため、何かに手を加える前に4層すべてを把握してください。

レイヤー 1: SDK / コアモデル — `prowler/lib/check/`

すべて Pydantic v1 (from pydantic.v1 import ...) です。3 つのモデルグループが compliance_models.py に存在します:

レガシーツリー — Compliance → Compliance_Requirement / Mitre_Requirement:

フレームワークファミリーごとに 1 つの *_Requirement_Attribute クラスがあります。現在登録されているもの (Union の順序が重要): ASDEssentialEight、CIS、ENS、ISO27001_2013、AWS_Well_Architected、 KISA_ISMSP、Prowler_ThreatScore、CCC、C5Germany、CSA_CCM、STIG (Okta IDaaS)、およびフォールバックとして Generic_Compliance_Requirement_Attribute。
Generic は Compliance_Requirement.Attributes: list[Union[...]] の中で必ず最後に置く必要があります — Pydantic v1 は Union のメンバーを順番に試すため、Generic を先頭にするとフレームワーク固有のすべての属性を飲み込んでしまいます。NIST 800-53/CSF、PCI DSS、GDPR、HIPAA、SOC2、 FedRAMP、SecNumCloud などは意図的に Generic を使用します。
root_validator は空の Framework、Provider、Name を拒否します。
MITRE は別個の Mitre_Requirement モデルを使用します (要件トップレベルに Tactics、SubTechniques、 Platforms、TechniqueURL、プロバイダーごとに Mitre_Requirement_Attribute_{AWS,Azure,GCP})。

ユニバーサルツリー — ComplianceFramework → UniversalComplianceRequirement:

要件ごとにフラットな attributes: dict を持ち、スキーマは attributes_metadata (key、label、type、enum、required、enum_display、 enum_order、output_formats) で宣言されます。root_validator は必須キーの欠落、不明なキー (ドリフトガード)、enum 違反、int/float/bool の型不一致を拒否します。 attributes_metadata を省略した場合は、検証が一切実行されません。
checks: dict[provider, list[check_id]] — フレームワークのプロバイダーリストはこれらのキーから導出されます (get_providers() / supports_provider())。トップレベルの provider フィールドはフォールバックにすぎません。
outputs.table_config (group_by、split_by、scoring、labels) が CLI テーブルを制御します。outputs.pdf_config はモデルに存在しますが、まだ API PDF パイプラインでは使用されていません (レイヤー 4 を参照)。

ガードレール — Compliance_Requirement_ConfigConstraint:

フィールドは Check、ConfigKey、Operator (lte|gte|eq|in|subset|superset)、 Value、オプションの Provider (ユニバーサルなマルチプロバイダーファイルでは必須)。
root_validator はロード時に Value/Operator の型不一致を拒否します。
評価は prowler/lib/check/compliance_config_eval.py に集約されています (evaluate_config_constraints、apply_config_status、get_effective_status、 CONFIG_NOT_VALID_PREFIX = "Configuration not valid for this requirement.")。 CSV/OCSF/テーブル出力および API バックエンドで共有されます。違反した制約は要件を FAIL に強制し、理由を status_extended の先頭に付加します。 ConfigKey が audit_config に存在しない制約はスキップされます (デフォルトでは準拠とみなされます)。

ローダー:

Compliance.get_bulk(provider) — レガシー: prowler/compliance/{provider}/ のみをスキャンします (+ prowler.compliance エントリーポイントグループ経由の外部 JSON)。トップレベルのユニバーサルファイルは認識しません。
get_bulk_compliance_frameworks_universal(provider) — トップレベルの prowler/compliance/ とすべてのプロバイダーサブディレクトリの両方をスキャンし、レガシーファイルを adapt_legacy_to_universal() を介して適応させます (Attributes[0] を dict にフラット化し、Checks を {provider: [...]} としてラップし、attributes_metadata を推論します)。また、prowler.compliance.universal エントリーポイントグループ経由で外部のユニバーサルフレームワークもロードします (組み込みが衝突時に優先されます)。
get_check_compliance(finding, provider_type, bulk_checks_metadata) は prowler/lib/outputs/compliance/compliance_check.py にあります (lib/check/compliance.py ではありません)。これは f"{Framework}-{Version}" をキーとする finding ごとの dict を Version が空でない場合にのみ 構築します — 空の Version はサイレントにキー "{Framework}" を生成し、下流のフィルターやテストを壊します。
prowler/lib/check/compliance.py には現在 update_checks_metadata_with_compliance() のみが含まれています。

Layer 2: JSON カタログ — `prowler/compliance/`

下記の「コンプライアンスカタログのカバレッジ」を参照してください。

Layer 3: 出力フォーマッター — `prowler/lib/outputs/compliance/`

ユニバーサルパス（フレームワークごとに Python は不要です）：

universal/universal_table.py — get_universal_table() は、outputs.table_config と attributes_metadata から CLI テーブルをレンダリングします。
universal/universal_output.py — UniversalComplianceOutput は、attributes_metadata から CSV の Pydantic モデルを動的に構築します。
universal/ocsf_compliance.py — OCSFComplianceOutput。ユニバーサルフレームワークでは、--output-formats に関係なく、OCSF 出力が常に生成されます。
compliance.py の process_universal_compliance_frameworks() がオーケストレーションを行います。この関数は、レガシーのディスパッチが始まる前に実行され、処理済みのフレームワークをセットから削除します。

レガシーパス — 通常はフレームワークごとのディレクトリです。

{framework}/
├── __init__.py
├── {framework}.py            # get_{framework}_table() summary-table function
├── {framework}_{provider}.py # One ComplianceOutput subclass per provider
└── models.py                 # One Pydantic CSV row model per provider

現在のディレクトリ：asd_essential_eight、aws_well_architected、c5、ccc、cis、cisa_scuba、ens、generic、iso27001、kisa_ismsp、mitre_attack、okta_idaas_stig、prowler_threatscore、universal。既知の例外（理由がない限り「修正」しないでください）：iso27001/ にはテーブルファイルがなく、汎用テーブルにフォールバックします。aws_well_architected/ にはプロバイダーごとのファイルがありません。cisa_scuba/ が提供するのは googleworkspace のみです。

CSV ライターは、大文字のヘッダーを使用した ; 区切りファイルを出力します（ComplianceOutput.batch_write_data_to_file）。models.py のフィールド名はパブリック APIであり、名前を変更すると後続のコンシューマーが動作しなくなります。
循環インポートのルール：テーブルファイル（{framework}.py）は、Finding を直接または間接的にインポートしてはいけません（compliance.compliance → テーブルモジュール → ComplianceOutput → Finding → get_check_compliance → 循環）。テーブルファイルには colorama、tabulate、prowler.config.config のみを含めてください。モジュールが両方を本当に必要とする場合は、if TYPE_CHECKING: または関数内インポートを使用してください（universal_output.py／process_universal_compliance_frameworks を参照）。
レガシーのテーブル関数には docstring がなく、ユニバーサル版にはあります。編集するファイル群のスタイルに合わせてください。
compliance.py のディスパッチャー display_compliance_table() の順序：ユニバーサル（table_config）が最初 → cis_ → ens_ → mitre_attack → kisa → prowler_threatscore_ → c5_ → ccc_ → asd_essential_eight（部分一致）→ okta_idaas_stig → それ以外はプロバイダーのフック（provider.display_compliance_table()。NotImplementedError が発生することがあります）→ get_generic_compliance_table()。iso27001、aws_well_architected、cisa_scuba は意図的にフォールバックを使用します。

レイヤー 4：API／UI

API の遅延ローダー：api/src/backend/api/compliance.py — LazyComplianceTemplate／LazyChecksMapping（get_bulk_compliance_frameworks_universal を使用したプロバイダーごとの遅延キャッシュ。Gunicorn のバックグラウンドでウォームアップします）。
API の CSV エクスポート振り分け：api/src/backend/tasks/jobs/export.py の COMPLIANCE_CLASS_MAP。tasks/tasks.py から利用されます。これは provider → [(predicate, exporter_class)] 形式の dict で、フォールバックには GenericCompliance を使用します。述語には、複数バージョンのファミリーには startswith （cis_、ens_、iso27001_、ccc_、cisa_scuba_ など）、真の単一フレームワークには 完全一致の name == ...（mitre_attack_aws、 prowler_threatscore_*、asd_essential_eight_aws — c5_azure／c5_gcp は一貫していませんが、aws では startswith("c5_") を使用します）が使われています。目安：フレームワークにバージョンやバリエーションが追加される可能性がある場合は、startswith を使用してください。
API の概要取り込み：api/src/backend/tasks/jobs/scan.py の create_compliance_requirements() は、遅延テンプレートからリージョンごとの行を作成し、ComplianceRequirementOverview（COPY。失敗時は bulk-create にフォールバック）と ComplianceOverviewSummary を永続化します。
API の PDF レポート：api/src/backend/tasks/jobs/reports/ — 独自の FrameworkConfig データクラスを使うハードコードされた FRAMEWORK_REGISTRY（SDK の PDFConfig ではありません）と、フレームワークごとのジェネレータークラスがあります。現在 PDF を提供しているのは prowler_threatscore、ens、nis2、csa_ccm、cis のみです。追加するには、ジェネレータークラス、レジストリーエントリー、および report.py での接続が必要です。
UI マッパーのルーティング：ui/lib/compliance/compliance-mapper.ts — JSON の framework 値（例："CIS"、"CIS-Controls"、"DORA"、"Okta-IDaaS-STIG"）をキーとする getComplianceMappers()。未登録のフレームワークは 自動的に汎用マッパーと GenericCustomDetails にフォールバックします — 専用マッパー／詳細パネルは、表示するための必須条件ではなく、正式な拡張機能です。
UI のグループ化はマッパーによって異なります：generic／cis は Section／SubSection、iso は Category、ccc は FamilyName でグループ化します。すべて attributes[0] を読み取ります。同一 JSON 内に一貫しない値があると別々のツリーブランチになるため、リリース前に正規化してください。
UI の型：ui/types/compliance.ts — フレームワークごとに *AttributesMetadata インターフェースを 1 つ用意し、AttributesItemData のメタデータユニオンに追加します。
UI アイコン：ui/components/icons/compliance/ + IconCompliance.tsx。登録は順序付きの部分文字列マッチング（COMPLIANCE_LOGOS）です。フレームワーク固有のキーワードは、汎用のものより先に配置してください（nist は nis2 より前、cisa は cis より前。aws は意図的に最後です）。

CLI パイプライン（エンドツーエンド）

prowler aws --compliance cis_7.0_aws          # framework key = JSON basename
    ↓
Compliance.get_bulk("aws")                      # legacy frameworks
get_bulk_compliance_frameworks_universal("aws") # legacy (adapted) + universal
    ↓
update_checks_metadata_with_compliance()        # attaches compliance to CheckMetadata
    ↓
execute_checks() → Finding objects
    ↓
get_check_compliance(finding, "aws", bulk)      # dict "{Framework}-{Version}" → [req_ids]
    ↓
process_universal_compliance_frameworks()       # universal: CSV + OCSF, then removed from set
per-provider elif branches in __main__.py       # legacy: AWSCIS(...).batch_write_data_to_file()
    ↓
display_compliance_table()                      # universal table first, then legacy elifs,
                                                # then generic fallback

コンプライアンスカタログの対応状況

2026-07 時点の件数（JSON ファイル 109 件）です。これらを信頼する前に再生成してください。

for d in prowler/compliance/*/; do printf "%s: %s\n" "$(basename $d)" "$(ls $d*.json 2>/dev/null | wc -l)"; done
ls prowler/compliance/*.json   # universal, top-level

ユニバーサル（トップレベル、複数プロバイダー対応）：cis_controls_8.1.json（18 プロバイダー）、csa_ccm_4.0.json（aws/azure/gcp/alibabacloud/oraclecloud）、 dora_2022_2554.json（aws/azure/gcp/alibabacloud/cloudflare）。

プロバイダー別のレガシー形式（ファミリー。全バージョンを網羅しているわけではありません）：

プロバイダー	件数	フレームワークファミリー
aws	45	CIS 1.4–7.0、NIST 800-53 r4/r5、NIST 800-171 r2、NIST CSF 1.1/2.0、PCI 3.2.1/4.0、ISO 27001 2013/2022、HIPAA、GDPR、SOC2、FedRAMP low/moderate r4 + 20x KSI low、ENS RD2022、MITRE ATT&CK、C5、CCC、CISA、FFIEC、RBI、Well-Architected（security/reliability）、FTR、FSBP、AWS AI Security Framework、AWS Account Security Onboarding、Audit Manager Control Tower、GxP 21 CFR 11 / EU Annex 11、KISA ISMS-P 2023（en+ko）、NIS2、ASD Essential Eight、SecNumCloud 3.2、Prowler ThreatScore
azure	19	CIS 2.0–6.0、ISO 27001 2022、ENS RD2022、MITRE ATT&CK、PCI 4.0、HIPAA、SOC2、NIS2、RBI、C5、CCC、FedRAMP 20x KSI low、SecNumCloud 3.2、Prowler ThreatScore
gcp	17	CIS 2.0–5.0、ISO 27001 2022、ENS RD2022、MITRE ATT&CK、PCI 4.0、HIPAA、SOC2、NIS2、RBI、C5、CCC、FedRAMP 20x KSI low、SecNumCloud 3.2、Prowler ThreatScore
kubernetes	8	CIS 1.8–2.0.1、ISO 27001 2022、PCI 4.0、Prowler ThreatScore
m365	5	CIS 4.0/6.0/7.0、ISO 27001 2022、Prowler ThreatScore
alibabacloud	3	CIS 2.0、SecNumCloud 3.2、Prowler ThreatScore
oraclecloud	3	CIS 3.0/3.1、SecNumCloud 3.2
github	2	CIS 1.0/1.2.0
googleworkspace	2	CIS 1.3、CISA SCuBA 0.6
okta	1	Okta IDaaS STIG V1R2
nhn	1	ISO 27001 2022

コンプライアンスディレクトリはありますが、フレームワークがまだないプロバイダー：cloudflare、iac、 linode、llm、mongodbatlas、openstack、stackit。ユニバーサルな checks ディクショナリ内のプロバイダーキーは、prowler/providers/ 配下のディレクトリ名（小文字）と一致している必要があります。

ユニバーサルスキーマのリファレンス

完全な仕様は docs/developer-guide/security-compliance-framework.mdx にあります。骨組み：

{
  "framework": "DORA",
  "name": "Digital Operational Resilience Act (DORA) 2022/2554",
  "version": "2022/2554",
  "description": "Shown in --list-compliance and PDF reports.",
  "icon": "dora",
  "attributes_metadata": [
    {"key": "Pillar", "label": "Pillar", "type": "str", "required": true,
     "enum": ["ICT Risk Management", "..."],
     "output_formats": {"csv": true, "ocsf": true}},
    {"key": "Article", "type": "str", "required": true}
  ],
  "outputs": {
    "table_config": {"group_by": "Pillar"},
    "pdf_config": {"group_by_field": "Pillar", "charts": ["..."]}
  },
  "requirements": [
    {
      "id": "DORA-Art5",
      "name": "Governance and organisation",
      "description": "Requirement text verbatim from the source.",
      "attributes": {"Pillar": "ICT Risk Management", "Article": "Article 5"},
      "checks": {
        "aws": ["iam_no_root_access_key"],
        "azure": [],
        "gcp": []
      },
      "config_requirements": [
        {"Check": "iam_user_accesskey_unused", "Provider": "aws",
         "ConfigKey": "max_unused_access_keys_days", "Operator": "lte", "Value": 45}
      ]
    }
  ]
}

ユニバーサルフィールド、トップレベル（`ComplianceFramework`）

フィールド	型	必須	備考
`framework`	string	はい	短い識別子（`DORA`、`CSA-CCM`、`CIS-Controls`）。UI マッパーがルーティングに使用するキーです。
`name`	string	はい	人が読める正式名称です。
`version`	string	いいえ（空欄は不可）	フレームワークのバージョン／エディション（`8.1`、`2022/2554`）。
`description`	string	はい	`--list-compliance` および PDF レポートに表示されます。
`provider`	string	いいえ	フォールバック専用です。有効なプロバイダー一覧は、要件全体の `checks` キーから導出されます（`get_providers()`）。
`icon`	string	いいえ	短いアイコンスラッグです。
`attributes_metadata`	array	いいえ（強く推奨）	すべての `attributes` キーのスキーマを宣言します。省略すると、属性の検証は一切実行されません。
`outputs`	object	いいえ	`table_config`（CLI テーブル）+ `pdf_config`（モデル化されていますが、API ではまだ使用されていません）。
`requirements`	array	はい	要件オブジェクトの一覧（以下を参照）。

ユニバーサルフィールド、要件ごと（`UniversalComplianceRequirement`）

フィールド	型	必須	備考
`id`	string	はい	フレームワーク内で一意です。
`description`	string	はい	原典の要件文をそのまま記載します。
`name`	string	いいえ	短いタイトルです。
`attributes`	dict	いいえ（デフォルト `{}`）	フラットなディクショナリです。すべてのキーを `attributes_metadata` で宣言する必要があります（メタデータがある場合、未知のキーは読み込み時に拒否されます）。
`checks`	dict	いいえ（デフォルト `{}`）	`{provider: [check_ids]}`。キーは小文字で、`prowler/providers/` のディレクトリ名と一致させます。空のリストは、そのプロバイダーに対する手動要件を意味します。
`config_requirements`	array	いいえ	ガードレールです。各制約には必ず `Provider` を含める必要があります。
`tactics`、`sub_techniques`、`platforms`、`technique_url`	—	いいえ	MITRE 形式の追加フィールドです（レガシー MITRE ファイルを変換する際に自動入力されます）。

`attributes_metadata` エントリのフィールド（`AttributeMetadata`）

フィールド	型	備考
`key`	string（必須）	`requirement.attributes` で使用される属性名です。
`label`	string	CSV ヘッダー／PDF 用の人間が読みやすいラベルです。
`type`	string	`str`（デフォルト）、`int`、`float`、`bool`、`list_str`、`list_dict` です。読み込み時に型が強制されるのは int/float/bool のみで、その他はドキュメント用です。
`enum`	list	許可される値です。読み込み時に強制されます。値の集合が固定されている場合は必ず使用してください。
`required`	bool	読み込み時に強制されます。すべての要件で、このキーに null 以外の値を指定する必要があります。
`enum_display` / `enum_order`	dict / list	PDF レンダリング用の列挙値ごとの表示メタデータ（ラベル、略称、色、アイコン）と並び順です。
`chart_label`	string	属性をチャートで使用する場合の軸ラベルです。
`output_formats`	object	`{"csv": bool, "ocsf": bool}` です。どちらもデフォルトは `true` で、各出力への含有を切り替えます。

主なルール：

--compliance のキーは、.json を除いた JSON ファイル名です（dora_2022_2554）。
自動検出されます。__init__.py、フォーマッター、ディスパッチャーへの登録は不要です。
table_config.group_by、pdf_config.group_by_field、すべての charts[].group_by は、attributes_metadata で宣言されたキーを参照する必要があります。
実行時の型検証は int／float／bool のみを対象とします。str／list_str／ list_dict はドキュメント用です。
新しいプロバイダーへの拡張は、requirement.checks にキーを追加するだけです。それ以外は不要です。
読み込み時にチェックの存在は自動検証されません。チェック ID に誤字があると、検出結果のない要件が黙って生成されます。必ずチェック存在の相互確認を実行してください（「検証」を参照）。
ユニバーサルファイルでは、すべての設定制約に必ず Provider を設定してください。これにより、AWS チェック用に作成されたガードレールが、同じ要件に対する Azure／GCP のスキャンに影響しなくなります。

レガシースキーマのリファレンス

レガシーファイルの基本構造：

{
  "Framework": "FRAMEWORK_NAME",
  "Name": "Full Framework Name with Version",
  "Version": "X.X",
  "Provider": "AWS",
  "Description": "Framework description...",
  "Requirements": [
    {
      "Id": "requirement_id",
      "Name": "Optional requirement name",
      "Description": "Requirement description",
      "Attributes": [ ... ],
      "Checks": ["check_name_1"],
      "ConfigRequirements": [ ... ]
    }
  ]
}

レガシーフィールド、トップレベル（`Compliance`）

フィールド	型	必須	備考
`Framework`	string	はい（空でないことを検証）	正式な識別子（`CIS`、`ENS`、`NIST-800-53-Revision-5`）。
`Name`	string	はい（空でないことを検証）	バージョンを含む、人間が読みやすい名前です。
`Version`	string	モデル上は任意 — 実際には空にしないでください	Version が空だと、`get_check_compliance()` のキーが `"{Framework}"` にひそかに劣化します（注意点 #4）。ファイル名に含まれるバージョン文字列と一致する必要があります。
`Provider`	string	はい（空でないことを検証）	大文字表記の単一プロバイダー（`AWS`、`AZURE`、`GCP`、`M365`、...）。1 ファイルにつき 1 プロバイダーです。
`Description`	string	はい	フレームワークの対象範囲と目的です。
`Requirements`	array	はい	要件オブジェクト（下記）、または MITRE ファイルの場合は `Mitre_Requirement` オブジェクトです。

レガシーフィールド、要件ごと（`Compliance_Requirement`）

フィールド	型	必須	備考
`Id`	string	はい	フレームワーク内で一意です。ソースの番号付けに正確に従ってください（`1.1`、`A.5.1`、`CCC.Core.CN01.AR01`）。
`Description`	string	はい	ソースカタログの記述をそのまま使用します。
`Name`	string	いいえ	任意の短いタイトルです（NIST スタイルのカタログで使用されます）。
`Attributes`	オブジェクトの配列	はい	下記の属性クラスの Union に基づいて解析されます。ユニバーサル形式への適応後に残るのは `Attributes[0]` のみで、UI のグループ化に使用されます。
`Checks`	文字列の配列	はい	要件を自動化するチェック ID です。`[]` は手動を意味します。
`ConfigRequirements`	配列	いいえ	ガードレールです。ファイルが単一プロバイダー用のため、`Provider` は省略されます。

MITRE ファイルでは、代わりに Mitre_Requirement を使用します。これは要件のトップレベルに Tactics、 SubTechniques、Platforms、TechniqueURL を追加します。

フレームワークファミリーごとの属性の形状

ユニバーサル形式（ファイル内スキーマ）とは異なり、レガシー要件の Attributes は Compliance_Requirement.Attributes に登録された Pydantic クラスのいずれかに一致する必要があります。一致するクラスがない形状は警告なく Generic にフォールバックし、固有のフィールドが失われます。最も一般的な形状は次のとおりです（全フィールドセットは compliance_models.py を参照してください）。

CIS — `cis_{version}_{provider}`

{
  "Section": "1 Identity and Access Management",
  "SubSection": "Optional subsection",
  "Profile": "Level 1",
  "AssessmentStatus": "Automated",
  "Description": "...", "RationaleStatement": "...", "ImpactStatement": "...",
  "RemediationProcedure": "...", "AuditProcedure": "...",
  "AdditionalInformation": "...", "DefaultValue": "...", "References": "https://..."
}

ENS — `ens_rd2022_{provider}`

{
  "IdGrupoControl": "op.acc.1", "Marco": "operacional",
  "Categoria": "control de acceso", "DescripcionControl": "...",
  "Nivel": "alto", "Tipo": "requisito",
  "Dimensiones": ["trazabilidad", "autenticidad"],
  "ModoEjecucion": "automatico", "Dependencias": []
}

ISO 27001 — `iso27001_{year}_{provider}`

{
  "Category": "A.5 Organizational controls",
  "Objetive_ID": "A.5.1", "Objetive_Name": "Policies for information security",
  "Check_Summary": "Summary of what is being checked"
}

注：Objetive_ID / Objetive_Name は、正確にこの（誤った）スペルを使用します。

MITRE ATT&CK — `mitre_attack_{provider}`（別の要件モデル）

{
  "Name": "Exploit Public-Facing Application", "Id": "T1190",
  "Tactics": ["Initial Access"], "SubTechniques": [],
  "Platforms": ["IaaS"], "Description": "...",
  "TechniqueURL": "https://attack.mitre.org/techniques/T1190/",
  "Checks": ["guardduty_is_enabled"],
  "Attributes": [
    {"AWSService": "Amazon GuardDuty", "Category": "Detect",
     "Value": "Minimal", "Comment": "..."}
  ]
}

他のプロバイダーでは AzureService/GCPService を使用します。Category： Detect|Protect|Respond。Value：Minimal|Partial|Significant。

CCC — `ccc_{provider}`

{
  "FamilyName": "Data", "FamilyDescription": "...",
  "Section": "CCC.Core.CN01 Encrypt Data for Transmission", "SubSection": "",
  "SubSectionObjective": "...",
  "Applicability": ["tlp-green", "tlp-amber", "tlp-red"],
  "Recommendation": "...",
  "SectionThreatMappings": [{"ReferenceId": "CCC", "Identifiers": ["CCC.Core.TH02"]}],
  "SectionGuidelineMappings": [{"ReferenceId": "NIST-CSF", "Identifiers": ["PR.DS-02"]}]
}

Applicability には TLP タグ（tlp-clear|tlp-green|tlp-amber|tlp-red）が格納されます。

ASD Essential Eight — `asd_essential_eight_aws`

{
  "Section": "Patch applications", "MaturityLevel": "ML1",
  "AssessmentStatus": "Automated", "CloudApplicability": "partial",
  "MitigatedThreats": ["..."], "Description": "...",
  "RationaleStatement": "...", "ImpactStatement": "...",
  "RemediationProcedure": "...", "AuditProcedure": "...",
  "AdditionalInformation": "...", "References": "..."
}

DISA STIG — `okta_idaas_stig_v1r2_okta`

{
  "Section": "...", "Severity": "high", "RuleID": "...", "StigID": "...",
  "CCI": ["CCI-000015"], "CheckText": "...", "FixText": "..."
}

Severity：high|medium|low（CAT I/II/III に対応）。

その他の登録済み形状

AWS Well-Architected（aws_well_architected_framework_{pillar}_pillar_aws）： Name、WellArchitectedQuestionId、WellArchitectedPracticeId、Section、 SubSection、LevelOfRisk、AssessmentMethod、Description、 ImplementationGuidanceUrl。
KISA ISMS-P（kisa_isms_p_2023_{provider}）：Domain、Subdomain、 Section、AuditChecklist、RelatedRegulations、AuditEvidence、 NonComplianceCases。
C5（c5_{provider}）：Section、SubSection、Type、AboutCriteria、 ComplementaryCriteria。
CSA CCM（レガシー形式。提供される CSA CCM 4.0 はユニバーサル形式です）：Section、 CCMLite、IaaS、PaaS、SaaS、ScopeApplicability。
Prowler ThreatScore（prowler_threatscore_{provider}）：Title、 Section、SubSection、AttributeDescription、AdditionalInformation、 LevelOfRisk（1–5）、Weight（1/8/10/100/1000）。ピラー：1 IAM、2 攻撃対象領域、 3 ロギングとモニタリング、4 暗号化。aws、azure、gcp、kubernetes、m365、alibabacloud で利用できます。
Generic（フォールバック）：ItemId、Section、SubSection、SubGroup、 Service、Type、Comment — すべて任意です。NIST、PCI、GDPR、 HIPAA、SOC2、FedRAMP、CISA、FFIEC、RBI、NIS2、GxP、SecNumCloud などで使用されます。

設定ガードレール（`ConfigRequirements`）

設定可能なチェックに基づく要件は、緩和された audit_config によって警告なく「満たされた」と判定されることがあります（例：CIS は未使用の認証情報が45日経過したら検出するよう求めていますが、スキャンは max_unused_access_keys_days: 120 で実行されました）。ガードレールにより、このような要件は FAIL になります。

"ConfigRequirements": [
  {"Check": "iam_user_accesskey_unused",
   "ConfigKey": "max_unused_access_keys_days", "Operator": "lte", "Value": 45}
]

演算子：lte/gte（数値のしきい値）、eq（トグル／完全一致 — 0/1 ではなく JSON のブール値を使用）、in（許可された集合内のスカラー値）、subset（許可リスト — 範囲を広げると不合格）、superset（拒否リスト — エントリを削除すると不合格）。
Value は、制御文が許容する最も厳しい設定である必要があります。
ConfigKey は、チェックで読み取られるとおりに正確に記述する必要があります。不明なキーは警告なくスキップされます（デフォルトは問題なしとみなされます）。
ガードレールは要件を厳しくするのみ（PASS→FAIL）で、緩和することはありません。
ユニバーサル形式のファイル：小文字の config_requirements と、各制約で必須の Provider。
テスト：tests/lib/check/compliance_config_eval_test.py、 compliance_config_constraint_model_test.py、 compliance_config_requirements_data_test.py、および tests/lib/outputs/compliance/ 以下の出力ごとのテスト。

ワークフロー A：上流カタログとフレームワークを同期する

フレームワークが上流で管理されており（CIS Benchmarks、FINOS CCC、CSA CCM、NIST、ENS など）、Prowler を最新の状態にする必要がある場合に使用します。

ステップ 1 — 上流ソースをキャッシュする

反復処理でネットワークにアクセスしないよう、上流のすべてのファイルをローカルキャッシュにダウンロードします。FINOS CCC の場合：

mkdir -p /tmp/ccc_upstream
catalogs="core/ccc storage/object management/auditlog management/logging ..."
for p in $catalogs; do
  safe=$(echo "$p" | tr '/' '_')
  gh api "repos/finos/common-cloud-controls/contents/catalogs/$p/controls.yaml" \
    -H "Accept: application/vnd.github.raw" > "/tmp/ccc_upstream/${safe}.yaml"
done

ステップ 2 — フレームワーク設定に対して汎用同期ランナーを実行する

同期ツールは 3 つのレイヤーで構成されるため、フレームワークの追加に必要なのは YAML 設定（および上流形式が未知の場合はパーサーモジュール）だけです。

skills/prowler-compliance/assets/
├── sync_framework.py          # generic runner — works for any framework
├── configs/ccc.yaml           # per-framework config (canonical example)
└── parsers/finos_ccc.py       # parser module for FINOS CCC YAML

python skills/prowler-compliance/assets/sync_framework.py \
       skills/prowler-compliance/assets/configs/ccc.yaml

ランナーは設定を読み込み、parser.module を動的にインポートし、 parse_upstream(config) -> list[dict] を呼び出した後、汎用の後処理（ID の一意性を保証する安全策、 FamilyName の正規化、設定に基づくフォールバックキーを用いた従来のチェックマッピングの保持）を適用し、Pydantic による事後検証を行ってプロバイダー JSON を書き出します。

新しいフレームワーク同期を追加するには：

assets/configs/{framework}.yaml を作成します（ccc.yaml を参照）。必須セクション：
- framework — name、display_name、version（空にしないでください — Version が空だと get_check_compliance() のキーが壊れるため、ランナーは起動を拒否します）、description_template。
- providers — {key, display} のペアのリスト。
- output.path_template — 例： "prowler/compliance/{provider}/cis_{version}_{provider}.json"。
- upstream.dir — ローカルキャッシュ（ステップ 1）。
- parser.module — parsers/ 配下のモジュール。parser. の残りの設定は不透明な値として渡されます。
- post_processing.check_preservation.primary_key（ほとんどの場合は Id）と fallback_keys — ID が変更された場合にマッピングを復元するため、Attributes[0] のフィールド名をタプルにまとめたリスト。CCC： - [Section, Applicability]；CIS：- [Section, Profile]；NIST： - [ItemId]。リスト値のフィールドは自動的に frozenset に変換されます。
- post_processing.family_name_normalization（任意）— 生の値から正規値へのマップ。UI は属性値と完全一致するものでグループ化するため、これがないと上流の表記揺れが個別のツリーブランチになります。
既存のパーサーを再利用するか、parsers/{name}.py を作成して、 Prowler 形式の要件を返す parse_upstream(config) -> list[dict] を実装します。ID は 必ず一意でなければなりません。ランナーは重複時にエラーを発生させます — 黙って番号を振り直すことはありません。正規の上流 ID（CIS 1.1.1、NIST AC-2(1)）を変更すると致命的だからです。上流固有の処理（外部プレフィックスの書き換え、実際の ID 衝突の振り直し、複数形式への対応）はすべてパーサーが担います。

ランナーがすでに処理する注意点（FINOS CCC v2025.10 の同期に基づく）：

上流 YAML の複数の形式。 FINOS CCC カタログの大半は control-families: [...] を使用しますが、storage/object は最上位の controls: [...] を使用します。単一形式のみを扱うパーサーではカタログ全体が黙って欠落します — この特定のバグにより、反復処理 1 回分で ObjStor が完全に欠落しました。各形式のファイルを 1 つずつ使ってテストしてください。
空白の折りたたみ。 上流の | ブロックスカラーは改行を保持しますが、Prowler では 1 行で保存します。" ".join(value.split()) で折りたたみます。
外部プレフィックスを含む ID の書き換え。 上流ではカタログ間で要件のエイリアスを作成し、元のプレフィックスを保持します（CCC.Logging.CN03 の下にネストされた CCC.AuditLog.CN08.AR01 など）— 親に合うよう書き換えます（CCC.Logging.CN03.AR01）。
上流で実際に発生する ID 衝突。 異なる 2 つの要件が同じ ID を共有している場合（上流の誤記）、2 つ目には次の空き番号を割り当てます。チェックマッピングの保持処理ではフォールバックキーを使って復元します。
Version を設定する — キーが壊れても気づかないバグより、即座に失敗する方が適切です。

ステップ 3 — コミット前に検証する

以下の「検証」セクション全体（ユニバーサルローダー + チェックの存在確認 + CLI スモークテスト + pytest）を実行します。

ステップ 4 — 必要に応じて属性モデルを追加する

フレームワークにGeneric_Compliance_Requirement_Attribute以外のフィールドがあり、レガシー形式を維持する必要がある場合に限ります。クラスを compliance_models.pyに追加し、 Compliance_Requirement.AttributesのUnionにGenericより前に登録します（Genericは最後のままにします）。新しいフレームワークでは、代わりに汎用の attributes_metadataを使用してください。

ワークフロー B：クラウド監査担当者として監査チェックのマッピングを監査する

既存のマッピングのレビューをユーザーから依頼された場合に使用します。これはコンプライアンス関連タスクの中で最も価値が高く、実際のカバレッジがゼロの水増しされたマッピングと、正当なカバレッジに対するマッピングの不足を明らかにします。

基本原則

Prowlerチェックのタイトル／リスクは、要件のテキストに書かれている内容を文字どおり説明していなければなりません。「関連している」だけでは不十分です。要件に実際に対応するチェックがない場合は、チェックのリストを空のままにしてください（MANUAL）。正直なMANUALは、水増しされたカバレッジより価値があります。

監査プロセス

プロバイダーごとのチェック一覧を作成します — assets/build_inventory.py （prowler/providers/以下で検出されたすべてのプロバイダーについて、/tmp/checks_{provider}.jsonを書き出します）。

一覧を検索します — assets/query_checks.py（リポジトリのルートから実行します）：

python skills/prowler-compliance/assets/query_checks.py aws encryption transit  # keyword AND-search
python skills/prowler-compliance/assets/query_checks.py aws --service iam       # all iam checks
python skills/prowler-compliance/assets/query_checks.py aws --id kms_cmk_rotation_enabled

現在のマッピングを含むフレームワークのセクションをダンプします — assets/dump_section.py：

python skills/prowler-compliance/assets/dump_section.py ccc "CCC.Core."
python skills/prowler-compliance/assets/dump_section.py cis_5.0_aws "1."

明示的なREPLACEの決定を記述します — assets/audit_framework_template.py：

DECISIONS = {}
DECISIONS["CCC.Core.CN01.AR01"] = {
    "aws": ["cloudfront_distributions_https_enabled", ...],
    "azure": ["storage_secure_transfer_required_is_enabled", ...],
    "gcp": ["cloudsql_instance_ssl_connections"],
    # Missing provider key = leave the legacy mapping untouched
}
# Empty list = EXPLICITLY MANUAL (overwrites legacy)
DECISIONS["CCC.Core.CN01.AR07"] = {"aws": [], "azure": [], "gcp": []}

PATCHではなくREPLACEを使用してください。 リスト全体を指定すると、監査を再現可能にし、レガシーデータに隠れた前提を明らかにできます。

すべてのチェックIDを一覧と照合して事前検証します。スクリプトは、タイプミスを標準エラー出力に一覧表示して必ず中止しなければなりません（実際の監査では、 storage_secure_transfer_required_enabled → storage_secure_transfer_required_is_enabled、 sqlserver_minimum_tls_version_12 → sqlserver_recommended_minimal_tls_versionへの誤りや、そもそも存在しない複数のチェックが見つかりました）。

適用＋検証＋テストを実行します：

python /path/to/audit_script.py
uv run pytest -n auto tests/lib/outputs/compliance/ tests/lib/check/ -q

要件テキストからAWS／Azure／GCPのチェックへの対応を示す整理済みマッピング表と、Prowlerでは実際に検証できないコントロールの一覧については、 references/check-mapping-reference.mdを参照してください。

ワークフロー C：新しい汎用フレームワークを追加する

上記のユニバーサルスキーマリファレンスに従って、prowler/compliance/{framework}_{version}.jsonを作成します（テンプレートとしてdora_2022_2554.jsonまたは csa_ccm_4.0.jsonを使用します）。
attributes_metadataで各属性を宣言し、可能な場合はrequired／enumを指定します（これが読み込み時の検証になります）。また、 outputs.table_config.group_byも宣言します。
プロバイダーごとにチェックをマッピングします。設定可能なチェックにはconfig_requirements（Providerを含む）を追加し、手動対応が必要な要件のリストは空のままにします。ソースカタログのすべての要件を含めてください（カバレッジ率は母数全体に基づきます）。
検証します（下記のセクションを参照）。CLIのテーブル／CSV／OCSFでは、Pythonでの登録は一切不要です。
UIでのファーストクラス対応は任意です。ui/lib/compliance/{framework}.tsxにマッパーを作成し、JSONのframework値を使ってgetComplianceMappers()に登録し、詳細パネル、*AttributesMetadata型、アイコン（順序付けされたキーワード！）を追加します。それまでは汎用マッパーで表示されます。
APIの追加対応は任意です。COMPLIANCE_CLASS_MAPにCSVエクスポーターを追加します。PDFが必要な場合は、PDFジェネレーターとFRAMEWORK_REGISTRYのエントリーを追加します。
テスト：新しいJSONを読み込むケースをtests/lib/check/universal_compliance_models_test.pyに追加します。パラメーター化されたtest_loads_as_universalは、ファイルをすでに自動検出します。
変更履歴の断片prowler/changelog.d/<slug>.added.mdを追加し、注目度の高いフレームワークの場合は、ユーザーガイドのチュートリアルをdocs/user-guide/compliance/tutorials/に追加します。

ワークフロー D：新しいレガシー出力フォーマッターの追加

既存のレガシーファミリーに新しいメンバーを追加する場合のみ適用されます。c5/ または ccc/ のレイアウトに厳密に従ってください。

mkdir prowler/lib/outputs/compliance/{framework} を実行し、__init__.py を追加します。
{framework}.py — c5/c5.py をコピーし、関数名とフレームワーク文字列を変更します。差分はその行だけにしてください。docstring は不要です（レガシー形式）。
models.py — プロバイダーごとに Pydantic の CSV 行モデルを 1 つ作成します。列のセットはプロバイダーごとに異なります（AccountId/Region、SubscriptionId/Location、ProjectId/Location）。プロバイダーごとにファイルを分けるのが慣例です。パラメーター化クラスにまとめないでください。レビューで却下されます。
{framework}_{provider}.py — transform() を持つ {Framework}_{Provider}(ComplianceOutput) を作成します。このファイルでは Finding をインポートできます。
登録します。
- compliance.py → display_compliance_table() の elif 分岐（および先頭の import）。
- prowler/__main__.py → writer クラスをインスタンス化する、プロバイダーごとの elif compliance_name.startswith(...) 分岐。
- api/src/backend/tasks/jobs/export.py → COMPLIANCE_CLASS_MAP のエントリー（ファミリーには startswith を使用し、真の単独フレームワークにのみ完全一致を使用します）。
tests/lib/outputs/compliance/{framework}/ にテストを配置し、tests/lib/outputs/compliance/fixtures.py にフィクスチャを追加します（transform() の両方の経路を実行するため、評価済み要件を 1 つ、手動要件を 1 つ用意します）。

循環インポートに関する警告：テーブルファイルから Finding を直接または間接的にインポートしてはいけません（循環：compliance.compliance → table → ComplianceOutput → Finding → get_check_compliance → compliance.compliance）。依存関係を最小限に保ち、両方が本当に必要な場合は TYPE_CHECKING または関数内インポートを使用してください。

検証（コミットの前に毎回実行）

スキーマの読み込み（両方の形式）：

from prowler.lib.check.compliance_models import (
    load_compliance_framework_universal,
    get_bulk_compliance_frameworks_universal,
)
fw = load_compliance_framework_universal("prowler/compliance/<file>.json")
assert fw is not None, "check logs for the ValidationError"
print(fw.framework, len(fw.requirements), fw.get_providers())
assert "<file_basename>" in get_bulk_compliance_frameworks_universal("aws")

ユニバーサルローダーは寛容で、壊れたファイルをログに記録してスキップします。assert fw is not None は必須です。スキャンが成功しても、正しいことの証明にはなりません。

存在確認 — これを検証するローダーはありません。古い ID は気付かれないまま無駄になります。

import json
from pathlib import Path
for prov in ["aws", "azure", "gcp"]:
    real = {p.stem.replace(".metadata", "")
            for p in Path(f"prowler/providers/{prov}/services").rglob("*.metadata.json")}
    data = json.load(open(f"prowler/compliance/{prov}/<file>.json"))
    refs = {c for r in data["Requirements"] for c in r["Checks"]}
    missing = refs - real
    assert not missing, f"{prov} missing: {missing}"

（ユニバーサルファイルの場合は、代わりに r.get("checks", {}).get(prov, []) を使用します。要件でプロバイダーキーが省略されるのは正当な場合があります。）

CLI スモークテスト：

uv run python prowler-cli.py <provider> --list-compliance          # appears?
uv run python prowler-cli.py <provider> --compliance <key> --log-level ERROR

output/compliance/ 内の CSV、サマリーテーブルの各セクション、検出結果の集計を確認します。

テスト：
```
uv run pytest -n auto tests/lib/check/universal_compliance_models_test.py \
  tests/lib/outputs/compliance/
```
test_loads_as_universal は prowler/compliance/ 内のすべての JSON（トップレベルとサブディレクトリ）を対象にパラメーター化されています。専用のテストを書いていなくても、不正なファイルがあればここで CI が失敗します。
CI／pre-commit でカバーされること、されないこと：pre-commit で保証されるのは、JSON の形式と整形が正しいこと（check-json、pretty-format-json）だけです。意味的な検証は行われません。ワークフロー .github/workflows/pr-check-compliance-mapping.yml は、新しいチェックを追加した PR で、どのフレームワークにもマッピングされていない場合に警告します（ラベル needs-compliance-review。ラベル no-compliance-check でスキップできます）。意味的な検証は、上記の pytest スイートと、skills/prowler-compliance-review/assets/validate_compliance.py による手動検証で行われます（注：このバリデーターはレガシースキーマを前提としています）。
Prowler Local Server：docker compose up を実行し、コンプライアンスページに要件、セクション、ウィジェットが表示されることを確認します。

規約と苦労して学んだ注意点

ユニバーサルを最優先。 レガシーとして始まる新しいフレームワークには 3 つの出力ファイル + 3 つの登録が必要ですが、同じフレームワークをユニバーサルにすればゼロで済みます。レガシーファミリーのみを拡張してください。
Generic_Compliance_Requirement_Attribute はレガシーの Attributes Union 内で最後に置きます — Pydantic v1 はメンバーを順番に試すため、Generic を先頭にするとあらゆる具体的な形状を黙って飲み込んでしまいます。
compliance_models.py ではどこでも Pydantic v1 を使用します（from pydantic.v1 import ...）。v2 を混在させないでください。
get_check_compliance() は prowler/lib/outputs/compliance/compliance_check.py にあり、Version が空でない場合にのみ dict を f"{Framework}-{Version}" でキー付けします。Version: "" を出荷しないでください — キーは黙って "{Framework}" に劣化し、フィルター、テスト、--compliance を壊します。レガシーファイルでは、ファイル名のバージョン部分文字列が Version と一致する必要があります（CLI は compliance_framework.split("_")[1] を読み取ります）。
Compliance.get_bulk() はトップレベルのユニバーサルファイルを認識しません — 認識するのは get_bulk_compliance_frameworks_universal() だけです。新しいコードパスはユニバーサルローダーに接続してください。
ローダーの寛容さは異なります: レガシーローダーは壊れた JSON でプロセスを終了しますが、ユニバーサルローダーはログに記録してスキップします。編集後にフレームワークが見つからない場合は、通常ユニバーサルローダーがそれを破棄したことを意味します — ログを確認してください。
循環インポートの保護: レガシーのテーブルディスパッチャーファイルは Finding を（直接的または推移的に）インポートしてはなりません。モジュールが両側を必要とする場合は TYPE_CHECKING または関数ローカルインポートを使用してください（ユニバーサルフォーマッターはそうしています）。
プロバイダーごとのフォーマッターファイルはレガシーの慣習です — ただし指摘する前に例外を把握してください（iso27001 にはテーブルファイルがなく、aws_well_architected にはプロバイダーごとのファイルがなく、cisa_scuba は googleworkspace 専用です）。CSV モデルのフィールド名は公開 API です。
CSV 出力: ; 区切り、大文字のヘッダー。OCSF コンプライアンス出力は、--output-formats に関係なく、ユニバーサルフレームワークに対して常に生成されます。
COMPLIANCE_CLASS_MAP は述語スタイルを混在させています: 複数バージョンのファミリーには startswith、単一バージョンには完全一致の ==。迷ったら startswith を使用してください — 完全一致は 2026 年までバージョン付き CCC バリアントをブロックしていました。
UI のグループ化はマッパーごとで、常に attributes[0] に対して行われます: generic/cis → Section/SubSection、iso → Category、ccc → FamilyName。一貫性のない値（または空の Section）は孤立/重複したツリーブランチを生みます — 出荷前に正規化してください。
UI には汎用フォールバックがあります — 未登録のフレームワークでもレンダリングされます。専用のマッパー/パネル/アイコンはアップグレードであり、前提条件ではありません。
アイコン登録は IconCompliance.tsx での順序付き部分文字列マッチングです — 具体的なキーワードを汎用的なものより先に（nist を nis2 より先に、cisa を cis より先に、aws を最後に）。
API の PDF パイプラインはまだ PDFConfig 駆動ではありません — 独自の FRAMEWORK_REGISTRY（5 つのフレームワーク）を持っています。JSON に pdf_config を追加すると Prowler App で PDF が生成されると仮定しないでください。
JSON を書く前に、すべてのチェック ID をプロバイダーごとのインベントリに対して事前検証してください。 タイプミスをキャッチするローダーはありません。要件がファインディングと一致することは決してありません。
監査の決定には PATCH よりも REPLACE が優れています — 完全で明示的なリストは再現可能で、レガシーの前提を明らかにします。
適用できるチェックがない場合、MANUAL が正しいです。 無関係なチェックでマッピングを埋めないでください。コンプライアンスレポートは実行可能であり続ける必要があります。
ソースカタログのすべての要件を含めてください、自動化されているかどうかに関わらず — コンプライアンスのパーセンテージは要件の総数を分母として使用します。
プロバイダーのカバレッジは非対称です（AWS は密、Azure/GCP はより薄く、新しいプロバイダーは最小限）。それを受け入れてください — Prowler が検証できない同等性を強制しないでください。
ガードレールの作成: 許容される最も厳格な Value、正確な ConfigKey の綴り、ユニバーサルファイルでは Provider が必須、ブール値は JSON ブール値。不正な制約は満たされているものとして扱われます — 構成テストで検証し、沈黙を信用しないでください。

便利なワンライナー

# Find duplicate requirement IDs (legacy | universal)
jq -r '.Requirements[].Id' file.json | sort | uniq -d
jq -r '.requirements[].id' file.json | sort | uniq -d

# Count manual requirements (legacy | universal, per provider)
jq '[.Requirements[] | select((.Checks | length) == 0)] | length' file.json
jq '[.requirements[] | select((.checks.aws // [] | length) == 0)] | length' file.json

# List unique check references (legacy | universal)
jq -r '.Requirements[].Checks[]' file.json | sort -u
jq -r '.requirements[].checks[]? | .[]' file.json | sort -u

# Providers covered by a universal framework
jq '[.requirements[].checks | keys[]] | unique' file.json

# Spot inconsistent grouping values (UI tree branches)
jq '[.Requirements[].Attributes[0].Section] | unique' file.json
jq '[.Requirements[].Attributes[0].FamilyName] | unique' file.json

# Requirements with config guardrails (empty arrays are truthy in jq — check length)
jq '[.Requirements[] | select((.ConfigRequirements // []) | length > 0)] | length' file.json

# Diff requirement ids between two versions
diff <(jq -r '.Requirements[].Id' a.json | sort) <(jq -r '.Requirements[].Id' b.json | sort)

# Where is a check mapped across all frameworks?
grep -rl "my_check_name" prowler/compliance/

# Does a check exist?
find prowler/providers/aws/services -name "{check_id}.metadata.json"

# Validate one file with the universal loader
python -c "from prowler.lib.check.compliance_models import load_compliance_framework_universal as l; fw=l('prowler/compliance/aws/cis_7.0_aws.json'); print(fw.framework, len(fw.requirements))"

コマンド

prowler {provider} --list-compliance
prowler {provider} --compliance cis_7.0_aws
prowler aws --compliance cis_7.0_aws pci_4.0_aws
prowler aws --compliance dora_2022_2554            # universal key = file basename
prowler aws --list-compliance-requirements cis_7.0_aws
prowler aws --compliance cis_7.0_aws -M csv json html

コード参照

レイヤー 1 — SDK / コア

prowler/lib/check/compliance_models.py — レガシーとユニバーサルのモデルツリー、 Compliance_Requirement_ConfigConstraint、すべてのローダー、レガシーからユニバーサルへのアダプター
prowler/lib/check/compliance.py — update_checks_metadata_with_compliance
prowler/lib/check/compliance_config_eval.py — ガードレール評価（API と共有）
prowler/lib/outputs/compliance/compliance_check.py — get_check_compliance
prowler/lib/check/utils.py — list_compliance_modules

レイヤー 2 — JSON カタログ

prowler/compliance/*.json — ユニバーサル、マルチプロバイダー（自動検出）
prowler/compliance/{provider}/ — レガシー、プロバイダーごと（自動検出）

レイヤー 3 — 出力フォーマッター

prowler/lib/outputs/compliance/universal/ — universal_table.py、 universal_output.py、ocsf_compliance.py
prowler/lib/outputs/compliance/{framework}/ — フレームワークごとのレガシーパッケージ
prowler/lib/outputs/compliance/compliance.py — process_universal_compliance_frameworks、display_compliance_table
prowler/lib/outputs/compliance/compliance_output.py — ComplianceOutput 基底クラスと CSV ライター
prowler/__main__.py — ユニバーサル処理と、プロバイダーごとのレガシーライター分岐

レイヤー 4 — API / UI

api/src/backend/api/compliance.py — LazyComplianceTemplate、 LazyChecksMapping、キャッシュのウォームアップ
api/src/backend/tasks/jobs/export.py — COMPLIANCE_CLASS_MAP
api/src/backend/tasks/jobs/scan.py — create_compliance_requirements （概要の取り込み）
api/src/backend/tasks/jobs/reports/ — PDF 生成器と FRAMEWORK_REGISTRY
ui/lib/compliance/compliance-mapper.ts — マッパーのルーティングと汎用フォールバック
ui/lib/compliance/{framework}.tsx — フレームワークごとのマッパー
ui/components/compliance/compliance-custom-details/ — 詳細パネル
ui/types/compliance.ts — 属性メタデータの型
ui/components/icons/compliance/ + IconCompliance.tsx — アイコン（順序あり）

テスト

tests/lib/check/universal_compliance_models_test.py — 提供されているすべての JSON を対象とした、パラメーター化された test_loads_as_universal を含みます
tests/lib/check/compliance_check_test.py、 compliance_config_eval_test.py、compliance_config_constraint_model_test.py、 compliance_config_requirements_data_test.py、mitre_config_requirements_test.py
tests/lib/outputs/compliance/ — フレームワークごとのテスト、ユニバーサルテスト、ディスパッチャーテスト、設定ステータスのカバレッジテスト、共通の fixtures.py

リソース

ドキュメント（コントリビューター向けの信頼できる情報源）： docs/developer-guide/security-compliance-framework.mdx（両方のスキーマ、ガードレール、検証、PR プロセス）、 docs/user-guide/compliance/tutorials/compliance.mdx、 docs/user-guide/compliance/tutorials/cross-provider-compliance.mdx
リポジトリのツール（util/compliance/）：CSV→JSON ジェネレーター（generate_json_from_csv/）、ccc/from_yaml_to_json.py、 compliance_mapper/、threatscore/
スキルのアセット（assets/）：
- sync_framework.py + configs/ccc.yaml + parsers/finos_ccc.py — 設定駆動型のアップストリーム同期（ワークフロー A）
- build_inventory.py、query_checks.py、dump_section.py、 audit_framework_template.py — 監査ツール（ワークフロー B）
- レガシー JSON テンプレート：cis_framework.json、ens_framework.json、 iso27001_framework.json、mitre_attack_framework.json、 prowler_threatscore_framework.json、generic_framework.json
参照資料： references/compliance-docs.md — モデル／ローダーのクイックリファレンス； references/check-mapping-reference.md — 要件テキストからチェックへのマッピング表（精選済み）+ MANUAL にする項目の一覧
姉妹スキル： prowler-compliance-review — PR レビューチェックリスト + validate_compliance.py（レガシースキーマバリデーター）
このスキルのフロントマターを編集した後、 ./skills/skill-sync/assets/sync.sh を実行して、AGENTS.md の自動呼び出しテーブルを再生成してください。

Markdown 対応

ログインしてコメント

基本情報

作者: prowler-cloud
リポジトリ: prowler-cloud/prowler
カテゴリ: セキュリティ
インストール数: 68
GitHub スター: 15,121

問題を報告