/prowler-compliance

name: prowler-compliance
description: >
  Creates, syncs, audits and manages Prowler compliance frameworks end-to-end.
  Covers the two supported JSON schemas (universal multi-provider and legacy
  per-provider), the SDK model tree (legacy attribute classes, universal
  ComplianceFramework, ConfigRequirements guardrails), output formatters
  (legacy per-framework + universal data-driven), API/UI consumption, upstream
  sync workflows, and cloud-auditor check-mapping reviews.
  Trigger: When working with compliance frameworks (CIS, CIS Controls, NIST,
  PCI-DSS, SOC2, GDPR, ISO27001, ENS, MITRE ATT&CK, CCC, C5, CSA CCM, DORA,
  KISA ISMS-P, ASD Essential Eight, DISA STIG, CISA SCuBA, SecNumCloud,
  FedRAMP, HIPAA, NIS2, Prowler ThreatScore), creating a universal
  multi-provider framework, adding ConfigRequirements guardrails, syncing with
  upstream catalogs, auditing check-to-requirement mappings, adding output
  formatters, or fixing compliance JSON bugs (duplicate IDs, empty Version,
  wrong Section, stale check refs).
license: Apache-2.0
metadata:
  author: prowler-cloud
  version: "2.0"
  scope: [root, sdk]
  auto_invoke:
    - "Creating/updating compliance frameworks"
    - "Creating a universal (multi-provider) compliance framework"
    - "Mapping checks to compliance controls"
    - "Adding ConfigRequirements guardrails to compliance requirements"
    - "Syncing compliance framework with upstream catalog"
    - "Auditing check-to-requirement mappings as a cloud auditor"
    - "Adding a compliance output formatter (per-provider class + table dispatcher)"
    - "Fixing compliance JSON bugs (duplicate IDs, empty Section, stale refs)"
allowed-tools: Read, Edit, Write, Glob, Grep, Bash, WebFetch, WebSearch, Task

When to Use

Use this skill when:

• Creating a new compliance framework for any provider — **decide universal vs legacy first** (see below)
• **Syncing an existing framework with an upstream source of truth** (CIS, FINOS CCC, CSA CCM, NIST, ENS, etc.)
• Adding requirements to existing frameworks, or extending a universal framework to a new provider
• Mapping checks to compliance controls
• **Adding `ConfigRequirements` guardrails** so configurable checks can't silently satisfy a requirement with a loosened config
• **Auditing existing check mappings as a cloud auditor** ("are these mappings correct?", "which checks apply?", "review the mappings")
• **Adding a new legacy output formatter** (table dispatcher + per-provider classes + CSV models)
• **Fixing JSON bugs**: duplicate IDs, empty Version, wrong Section, stale check refs, inconsistent FamilyName, padded tangential check mappings
• Investigating why a finding/check isn't showing under the expected compliance framework in the UI
• Understanding compliance framework structures and attributes

The authoritative contributor doc is `docs/developer-guide/security-compliance-framework.mdx` — keep this skill and that doc consistent when either changes. For **reviewing** a compliance PR, use the sister skill [prowler-compliance-review](../prowler-compliance-review/SKILL.md) instead.

Universal vs Legacy: The First Decision

Prowler supports **two JSON schemas**. Choosing wrong means unnecessary Python code, so decide this before anything else. At load time both converge: legacy files are adapted into the universal `ComplianceFramework` model (`adapt_legacy_to_universal()`), so the difference is about **authoring cost and capabilities**, not about what the rest of Prowler sees.

Side-by-side comparison

| | Universal (recommended for new frameworks) | Legacy provider-specific | |---|---|---| | File location | `prowler/compliance/<framework>.json` (top level) | `prowler/compliance/<provider>/<framework>_<version>_<provider>.json` | | Providers | Any number, one file (`checks` dict keyed by provider) | Exactly one provider per file (one file per provider to multi-cover) | | Key style | lowercase (`framework`, `requirements`, `checks`) | Capitalized (`Framework`, `Requirements`, `Checks`) | | Attribute schema | Declared **in the JSON itself** via `attributes_metadata`, validated at load | Pydantic class per framework family in `compliance_models.py` (code change for new shapes) | | Attributes per requirement | One flat dict (`attributes: {...}`) | List of objects (`Attributes: [{...}]`) — only `Attributes[0]` is used downstream | | Table/CSV/OCSF output | Data-driven from `outputs.table_config` — **zero Python changes** | Formatter package + registrations in `compliance.py`, `__main__.py`, `export.py` | | Guardrails field | `config_requirements` (+ mandatory `Provider` per constraint) | `ConfigRequirements` (`Provider` omitted) | | Loader behavior on error | Lenient: logs + skips file (`load_compliance_framework_universal`) | Fail-fast: `sys.exit(1)` (`load_compliance_framework`) | | Loaded by | Only `get_bulk_compliance_frameworks_universal()` | Both loaders (`Compliance.get_bulk()` + universal, via adapter) | | Shipped examples | `cis_controls_8.1.json`, `csa_ccm_4.0.json`, `dora_2022_2554.json` | Everything else (~105 files across 11 providers) |

When to use which

**Use universal when** (any of these):

• The framework is **new to Prowler** — no existing attribute class, no

existing formatter. This is the default: zero Python changes needed.

• The framework spans (or will span) **more than one provider** — DORA, CSA

CCM, CIS Controls. One file covers all providers; extending to a new provider is a one-line `checks` edit.

• The attribute shape is **unique to this framework** — declare it in

`attributes_metadata` instead of adding a Pydantic class to the Union.

**Use legacy only when extending an existing legacy family**:

• A new **version** of a shipped legacy framework (CIS 8.0 for AWS → new

`cis_8.0_aws.json`, same `CIS_Requirement_Attribute`, same `cis/` formatter).

• An existing legacy framework for a **new provider** (ENS for m365 → new

`ens_rd2022_m365.json` + `ens_m365.py` transformer).