Rego Policy Libraries
867 production-ready Rego policies (2123 including tests; 22,654 control-level checks by make count, from OPA's parser; counted 2026-10-29, SAP ABAP baseline) for OPA and Enterprise OPA (EOPA), covering CIS Benchmarks (with Level 2 hardening profiles, Oracle Cloud Infrastructure and Oracle Database 26ai among them), CIS Controls v8.1, DISA STIGs, CISA SCuBA M365, NSA/CISA Kubernetes Hardening, NIST, Zero Trust (CISA ZTMM v2.0), SOC 2, PCI-DSS, ISO 27001, NERC-CIP (with full data-source reference), IEC 62443, HIPAA, FedRAMP, FBI CJIS, IRS Pub 1075, ACSC Essential Eight, APRA CPS 234, HKMA TM-G-1/TM-C-1 (Hong Kong), MAS TRM (Singapore), BNM RMiT (Malaysia), CERT-In Directions and DPDP Act (India), METI Cybersecurity Management Guidelines (Japan), UK Cyber Essentials, BSI C5, CSA CCM, CCPA/CPRA, EU AI Act, GEISA, and more — all in Rego v1 syntax, ready to load into any OPA or EOPA instance.
Standalone and dependency-free: no orchestrator, no agent, no vendor runtime. Clone it, load it, query it.
The largest open library of executable compliance policy anyone can verify — 22,654 control-level checks across 183 framework catalogs — and the broadest regulatory coverage of any machine-readable policy library, open or closed. The first half is a number CI recomputes on every merge (make count) and fails if this line drifts; the second half is the framework list below, which no other library matches. How we measured both, against every public library we could find: docs/COMPARISON.md. Where we still trail the Secure Controls Framework on documents mapped, and the plan to close it: docs/SCF_GAP.md. Every entrypoint fails closed: a framework given no facts reports non-compliant with the reason, because we treat a lack of facts as non-compliance.
Compared with: Kubescape regolibrary (304 Rego rules, Kubernetes only), Kyverno policies (180), Gatekeeper library (49), trivy-checks (563), Checkov (~1,000, IaC), KICS (1,813, IaC), Prowler (1,625 cloud checks), Steampipe AWS mod (1,361), ComplianceAsCode (2,574 OS rules), Azure Policy built-ins (5,130, Azure), Secure Controls Framework (1,534 catalogue controls, not executable). Runs unchanged in: OPA, Enterprise OPA, Styra DAS, Conftest, Gatekeeper, Kubewarden, Trivy, KICS, Regula, Snyk IaC, Terraform Cloud, Spacelift, env0, Envoy/Istio. Exports to: WASM for every language SDK, signed bundles, OSCAL, SARIF, OCSF, Ansible, SCAP, InSpec, Wazuh, CEL/Kyverno, Azure Policy, AWS Config, Steampipe, Sentinel, Sigma, Prowler (see converters/).
Use it in CI in sixty seconds: docs/INTEGRATIONS.md — pull the GHCR bundle, evaluate your facts, fail the job on non-compliance; Conftest for the IaC gates.
The count above is restamped by the docs pass that accompanies each merge batch;
between batches it can drift slightly low. The exact number at any commit:
git ls-files | grep '\.rego$' | grep -vcE '(^|/)(test_|.*_test\.rego$)' # policy files
git ls-files | grep -c '\.rego$' # including tests
Why this repo?
Writing compliance policies from scratch is expensive and error-prone. A typical enterprise deploying OPA for CIS RHEL 9 alone needs 338 individual control checks — and that's one framework for one OS.
This library gives you a complete, working policy set on day one, covering 30+ platforms, 55+ regulatory frameworks, and every major compliance standard from CIS and DISA STIGs to NERC-CIP and IEC 62443. All policies:
- Use Rego v1 syntax (
import rego.v1) — no deprecation warnings, forward-compatible
- Return structured JSON reports (compliant, score, violations list) — wire directly to dashboards or CI
- Are independently loadable — use one framework or the whole library; no coupling
- Expose a uniform entrypoint —
data.<package>.main.compliance_report for every framework, so you can evaluate one by name without learning its internal layout
- Fail closed — a framework given no facts reports non-compliant with an explicit reason, never a silent pass (see below)
- Are vendor-neutral — no orchestrator, deployment topology, or caller vocabulary baked in
- Are Apache 2.0 licensed — use commercially without restriction
Why not build your own? You can — but CIS RHEL 9 alone has 338 controls across 14 sections. NERC-CIP covers 14 standards (CIP-002 through CIP-015) with 200+ requirements. IEC 62443 adds 51 System Requirements across 7 Foundational Requirements. Starting from scratch takes months. This library is that months-of-work already done.
Coverage at a glance
| Standard / Framework | Path | Controls / Requirements |
|---|
| CIS RHEL 9 v2.0.0 | benchmarks/cis/rhel_9/ | 17 modules · 224+ control IDs ✅ |
| CIS RHEL 8 | benchmarks/cis/rhel_8/ | Full |
| CIS RHEL 10 | benchmarks/cis/rhel_10/ | Full |
| CIS Ubuntu 22.04/24.04/20.04 | benchmarks/cis/ubuntu_*/ | Full |
| CIS Rocky Linux 8/9 | benchmarks/cis/rocky_linux_*/ | Full |
| CIS Debian 11 | benchmarks/cis/debian_11/ | Full |
| CIS Amazon Linux 2023 | benchmarks/cis/amazon_linux_2023/ | Full |
| CIS Windows Server 2022 v5.1.0 | benchmarks/cis/windows_server_2022_modular/ | Full: all 408 recommendations (406 evaluated, 2 Manual by attestation), member server and domain controller, Level 1/2 and Next Generation profiles |
| CIS Windows Server 2019 | benchmarks/cis/windows_server_2019_modular/ | IDs unverified: a copy of the old 2022 module's numbering, not checked against the CIS Windows Server 2019 benchmark |
| CIS Windows 10/11 | benchmarks/cis/windows_10/ | Full |
| CIS Microsoft 365 Foundations v7 (SaaS) | benchmarks/cis/saas/m365_v7/ | 9 sections: Entra, Exchange, Defender, Purview, SharePoint, Teams, Intune, Fabric, Admin Center |
| CIS PostgreSQL | benchmarks/cis/postgresql/ | Full |
| Network devices — Cisco, Juniper, Palo Alto, Fortinet, Arista, VyOS, pfSense | benchmarks/cis/network_devices/ | Full |
| CIS AWS / Azure / GCP | benchmarks/cis/cloud/ | Foundations |
| CIS Docker / Kubernetes / OpenShift | benchmarks/cis/containers/ | Full |
| DISA STIGs — 24 platforms (RHEL 8/9, Oracle Linux 8/9, Windows Server 2016/2019/2022/2025, Windows 10/11, Ubuntu 20.04/22.04, Amazon Linux 2023, SLES 15, , , OpenShift 4, Crunchy Postgres 16, SQL 2016, , , Apache 2.4, Cisco IOS-XE, vSphere 8 ESXi) |
Every implemented standard is tracked in STANDARDS_UPDATE_REGISTRY.md — pinned version, upstream revision cadence, and watch URL — so modules regenerate when standards change instead of drifting silently.
What's in the box
| Domain | Policies | Coverage |
|---|
| CIS Benchmarks + DISA STIGs | 424 | 30+ platforms: Linux, Windows, cloud, containers, managed Kubernetes (EKS/AKS/GKE), databases, web servers, network devices, VMware, mobile, and SaaS (M365) — plus DISA STIGs for 24 platforms. CIS benchmark versions updated to May 2026 releases; Level 2 hardening profiles for high-value targets (RHEL 9, Ubuntu 22.04, Windows Server 2022) |
| Federal & K8s hardening baselines | 19 | CISA SCuBA M365 (104 policies, 7 products, BOD 25-01), NSA/CISA Kubernetes Hardening v1.2 (43 controls), Kubernetes Pod Security Standards (baseline + restricted, evaluated against actual Pod manifests) |
| Application suite baselines | 7 | SAP Security Baseline Template v2.6 (ABAP) — registry of all 355 checks SAP publishes (SAP-samples, Apache-2.0), 138 decided from host facts, projections onto the Baseline requirements, the DSAG S/4HANA audit guide and NIST CSF 2.0 |
| Regulatory Frameworks | 371 | ISO 27001, SOC 2, PCI-DSS, SOX, FISMA, FedRAMP, CMMC, GDPR, HIPAA, NERC-CIP, IEC 62443, DORA, NIS2, NY DFS, SEC Cyber, SWIFT CSP, HITRUST, TISAX, CFR Part 11, NCSC CAF, Digital Sovereignty, CSA CCM v4.0, ISO 27701, NIST SP 800-171 r3, CCPA/CPRA, TSA Pipeline SDs, GLBA, CISA CPG 2.0, ITAR, COBIT 2019, FERPA, COPPA (2025 amendments), CIS Controls v8.1, Zero Trust (CISA ZTMM v2.0), NIST SSDF, FBI CJIS, ACSC Essential Eight, IRS Pub 1075, UK Cyber Essentials, BSI C5:2020 |
| Enforcement | 18 | Ansible, Terraform, Dockerfile, Kubernetes admission, Git approval/playbook docs, AAP job gating, CI/CD pipeline gating, SLSA supply-chain governance, Terraform-provider change gate (aac.tfprovider) |
| Governance | 25 | AI agent authorization, MCP tool-call enforcement, GEISA (API/ADM/LEE/VEE), EU AI Act (Regulation 2024/1689) suite, ISO/IEC 42001 (AIMS), OIDC token validation, FinOps tagging, estate continuity (retired vs disappeared vs not responding) |
Highlight: CIS RHEL 9 v3.0.0 — 352 CIS recommendations with Level 1/2 server and workstation profiles
(14 core CIS sections plus 3 extended-hardening modules for STIG/NIST drift detection).
On coverage numbers. The control IDs above are counted from the violation messages
the modules actually emit, so the figure is reproducible from a clone:
grep -rhoE 'CIS (L2 )?[0-9]+(\.[0-9]+)*' benchmarks/cis/rhel_9 --include='*.rego' \
| sed -E 's/CIS L2 /CIS /' | sort -u | wc -l
It is a floor, not a ceiling — a single rule often satisfies more than one CIS control,
so true coverage is higher. We publish the number we can prove rather than a headline
percentage we cannot.
Continuous ATO, in machine-readable form
Everything an authorization package needs from the policy side is generated from the Rego parse tree and the
evaluation output, validated against the OSCAL 1.2.3 schemas in CI, and committed under
converters/exports/oscal/dist/:
| OSCAL object | What it holds | Where |
|---|
| catalog | one per framework, 183 catalogs, 18,254 controls with the Rego file that evaluates each | dist/catalogs/ |
| profile | NIST SP 800-53 Rev 5 Low / Moderate / High / Privacy and FedRAMP Rev 5 Low / Moderate / High / LI-SaaS, imported from NIST's and FedRAMP's own files at pinned commits | dist/profiles/ |
| component-definition | the library as one component: an implemented-requirement per catalog control, plus one per baseline control the library evaluates | dist/component-definition.json |
| assessment-results | built from any compliance_report run, one finding per violation targeting the catalog statement | build_assessment_results.py |
| baseline coverage | per baseline, which 800-53 controls at least one check evaluates: about 60 % of base controls in every baseline, few enhancements, with the mapping source for each | dist/profiles/coverage.csv |
Mappings to 800-53 come only from authoritative tables (DISA's CCI map for every STIG rule, NIST's baselines, and
modules whose control ids are 800-53 ids); nothing is mapped by hand. Not yet generated: a system security plan, a
POA&M, and signed results. SARIF 2.1.0 and OCSF 1.9.0 exports sit beside the OSCAL ones. How it works:
converters/exports/oscal/README.md.
Quick Start
Option A — OCI bundle (recommended for production)
Pull the pre-built bundle directly from GitHub Container Registry — no clone needed:
# Pull the full policy bundle
oras pull ghcr.io/ynotbhatc/rego_policy_libraries:latest
# Start OPA with the bundle
podman run -d --name opa -p 8181:8181 \
-v "$(pwd)/bundle.tar.gz:/bundle.tar.gz:ro" \
openpolicyagent/opa:1.10.0 run --server --addr :8181 --bundle /bundle.tar.gz
Versioned tags are available: ghcr.io/ynotbhatc/rego_policy_libraries:v1.0.0
Install oras: https://oras.land/docs/installation
Option B — Git clone
# Clone
git clone https://github.com/ynotbhatc/rego_policy_libraries.git
cd rego_policy_libraries
# Start OPA
podman run -d --name opa -p 8181:8181 openpolicyagent/opa run --server --addr :8181
# Load all CIS RHEL 9 policies
for f in benchmarks/cis/rhel_9/*.rego; do
curl -s -X PUT --data-binary @"$f" \
"http://localhost:8181/v1/policies/$(basename $f .rego)"
done
# Evaluate against your system facts — uniform entrypoint, same for every framework
curl -s -X POST http://localhost:8181/v1/data/cis_rhel9/main/compliance_report \
-H 'Content-Type: application/json' \
-d '{"input": {"os_family": "RedHat", ...}}'
Query with no input and you get compliant: false with an explicit
FAIL-CLOSED violation — not a 100% pass. That is deliberate; see
Framework entrypoints.
Policy Taxonomy
rego_policy_libraries/
├── benchmarks/ # Technical security baselines
│ ├── cis/
│ │ ├── rhel_8/ rhel_9/ rhel_10/
│ │ ├── ubuntu_20_04/ ubuntu_22_04/ ubuntu_24_04/
│ │ ├── debian_11/ rocky_linux_8/ rocky_linux_9/ amazon_linux_2023/
│ │ ├── windows_server_2016/ windows_server_2019_modular/
│ │ ├── windows_server_2022/ windows_server_2022_modular/
│ │ ├── windows_10/ windows_11/
│ │ ├── aws/ azure/ gcp/ # Cloud Foundations
│ │ ├── docker/ kubernetes/ # Containers
│ │ ├── eks/ aks/ gke/ # Managed Kubernetes (EKS v1.8.0, AKS v1.8.0, GKE v1.9.0)
│ │ ├── postgresql/ databases/
│ │ ├── saas/m365_v7/ # SaaS — CIS Microsoft 365 Foundations v7 (m365/ = v6 legacy)
│ │ ├── network_devices/ # Cisco, Juniper, Palo Alto, Fortinet, Arista, VyOS, pfSense
│ │ ├── vmware/ # ESXi 8, vCenter
│ │ ├── mobile_devices/ # Android, iOS
│ │ ├── os/linux/ # legacy/simple RHEL 9 variants — superseded
│ │ ├── cloud/ # AWS, Azure, GCP Foundations
│ │ ├── containers/ # Docker, Kubernetes, OpenShift
│ │ ├── databases/ # MySQL 8, Oracle 19c, PostgreSQL 13/14/15
│ │ ├── web_servers/ # Apache 2.4, Nginx 1.20
│ │ └── network/ # Cisco IOS, Juniper Junos, Palo Alto, Fortinet, Arista
│ ├── stig/ # DISA STIGs — 24 platforms (Linux, Windows, K8s/RKE2/OpenShift,
│ │ # databases, Apache, Cisco IOS-XE, vSphere)
│ ├── scuba/m365/ # CISA SCuBA M365 baselines — 104 policies, 7 products (BOD 25-01)
│ ├── nsa_cisa/kubernetes/ # NSA/CISA Kubernetes Hardening Guidance v1.2 — 43 controls
│ ├── pss/kubernetes/ # K8s Pod Security Standards — baseline + restricted, manifest-evaluated
│ └── sap/abap/ # SAP Security Baseline Template v2.6 (ABAP) — 355-check registry, 138 host-decided
│
├── frameworks/ # Regulatory compliance
│ ├── federal/ # NIST 800-53/171/800-82, CSF 2.0, AI RMF, SSDF, FISMA, FedRAMP,
│ │ # CMMC, Zero Trust (ZTMM v2.0 + 800-207), CJIS, IRS Pub 1075
│ ├── management/ # ISO 27001, SOC 2, CSA CCM, COBIT 2019, CIS Controls v8.1,
│ │ # Corporate, NCSC CAF 4.0
│ ├── financial/ # PCI-DSS, SOX, SWIFT CSP, NY DFS, SEC Cyber, GLBA
│ ├── privacy/ # GDPR, HIPAA, ISO 27701, CCPA/CPRA, FERPA, COPPA
│ ├── regulatory/ # DORA, NIS2, ITAR
│ ├── regional/ # ACSC Essential Eight, UK Cyber Essentials, BSI C5, UK MoD DCC, CERT-In (India), METI CSM (Japan)
│ ├── critical_infrastructure/ # NERC-CIP (CIP-002–CIP-015), IEC 62443, NIST IR 7628,
│ │ # NIST 800-82, TSA Pipeline Security Directives
│ └── sovereignty/ # Digital Sovereignty (7 domains)
│
├── enforcement/ # Gate-style policy enforcement
│ ├── ansible/ # Block non-compliant playbooks at check-in and runtime
│ ├── terraform/ # Validate plans before apply
│ ├── dockerfile/ # Lint Dockerfiles at build time
│ ├── kubernetes/ # Admission control for K8s manifests
│ ├── git/ # Approval and playbook-documentation policies
│ ├── cicd/ # CI/CD pipeline gating
│ └── supply_chain/ # SLSA-style supply-chain governance
│
├── governance/ # AI and operational governance
│ ├── ai/ # AI agent action classification and authorization
│ ├── mcp/ # MCP server tool-call enforcement
│ ├── eu_ai_act/ # EU AI Act (Regulation 2024/1689) — prohibited, high-risk, GPAI, transparency
│ ├── geisa/ # GEISA runtime compliance (API, ADM, LEE, VEE)
│ ├── oidc/ # OIDC token validation for portal/MCP access control
│ └── finops/ # Resource tagging policies
│
└── threat_detection/
└── crypto_mining/ # Detect unauthorized cryptocurrency miners
CIS Benchmark Coverage
| Platform | Path | Controls |
|---|
| RHEL 9 | benchmarks/cis/rhel_9/ | 17 modules · 224+ control IDs ✅ |
| RHEL 8 | benchmarks/cis/rhel_8/ | Full |
| Ubuntu 22.04 | benchmarks/cis/ubuntu_22_04/ | Full |
| Ubuntu 20.04 / 24.04 | benchmarks/cis/ubuntu_20_04/ | Full |
| Debian 11 | benchmarks/cis/debian_11/ | Full |
| Rocky Linux 8 / 9 | benchmarks/cis/rocky_linux_8/ | Full |
| Amazon Linux 2023 | benchmarks/cis/amazon_linux_2023/ | Full |
| Windows Server 2022 | benchmarks/cis/windows_server_2022_modular/ | Full (v5.1.0, 408 recommendations) |
| Windows Server 2019 | benchmarks/cis/windows_server_2019_modular/ | IDs unverified |
| AWS / Azure / GCP | benchmarks/cis/cloud/ | Foundations |
| Docker / Kubernetes / OpenShift | benchmarks/cis/containers/ | Full |
| MySQL / Oracle / PostgreSQL | benchmarks/cis/databases/ | Full |
| Cisco / Juniper / Palo Alto / Fortinet / Arista | benchmarks/cis/network/ | Full |
IEC 62443 Coverage
Full library for IEC 62443 Industrial Automation and Control Systems (IACS) Security — all 51 System Requirements (SRs) from Part 3-3 plus Part 2 management requirements.
| File | Part | Title | SRs |
|---|
fr1_identification_authentication.rego | 3-3 FR 1 | Identification & Authentication Control (IAC) | SR 1.1–1.13 (13) |
fr2_use_control.rego | 3-3 FR 2 | Use Control (UC) | SR 2.1–2.12 (12) |
fr3_system_integrity.rego | 3-3 FR 3 | System Integrity (SI) | SR 3.1–3.9 (9) |
fr4_data_confidentiality.rego | 3-3 FR 4 | Data Confidentiality (DC) | SR 4.1–4.3 (3) |
fr5_restricted_data_flow.rego | 3-3 FR 5 | Restricted Data Flow / Zone & Conduit (RDF) | SR 5.1–5.4 (4) |
fr6_timely_response.rego | 3-3 FR 6 | Timely Response to Events (TRE) | SR 6.1–6.2 (2) |
fr7_resource_availability.rego | 3-3 FR 7 | Resource Availability (RA) | SR 7.1–7.8 (8) |
part2_security_management.rego | 2-1 | Security Management System (CSMS) | — |
part2_patch_management.rego | 2-3 | Patch Management in IACS Environments | — |
part2_service_provider.rego | 2-4 | Security Program for IACS Service Providers (SP.01–SP.10) | — |
part3_risk_assessment.rego | 3-2 | Security Risk Assessment (ZCR 1–5) | — |
iec_62443_main.rego | All | Main orchestrator — aggregates all parts | 51 total |
Security Level (SL) tiering: All FR modules enforce SL-differentiated requirements — violations are tagged with the SL at which they apply (SL 1 baseline through SL 4 state-sponsored threat protection).
OPA endpoint: POST /v1/data/iec_62443_main/iec_62443_compliance_report
{
"standard": "IEC 62443",
"target_sl": 2,
"compliant": false,
"fr_compliance_score": 71,
"sr_compliance_score": 84,
"passing_frs": 5,
"total_frs": 7,
"passing_srs": 43,
"total_srs": 51,
"part3_3_foundational_requirements": {
"FR1_identification_authentication": { "compliant": true, "passing_srs": 13 },
"FR5_restricted_data_flow": { "compliant": false, "violations": ["..."] }
}
}
TSA Pipeline Security Directives Coverage
Both currently-effective TSA pipeline cybersecurity directives, in
frameworks/critical_infrastructure/tsa_pipeline/ — 12 section modules plus an
orchestrator, covering 112 directive subparagraphs.
| Directive | Effective | Sections covered |
|---|
| SD Pipeline-2021-01G — Enhancing Pipeline Cybersecurity | 2026-01-16 → 2027-01-15 | II.B Cybersecurity Coordinator · II.C Incident reporting to CISA · II.D Vulnerability assessment |
| SD Pipeline-2021-02G — Pipeline Cybersecurity Mitigation Actions, Contingency Planning, and Testing | 2026-05-03 → 2027-05-02 | II.A/III.A Critical Cyber Systems · II.B/VI Implementation Plan + amendments · III.B Network segmentation · III.C Access control · III.D Continuous monitoring · III.E Patch management · III.F Incident Response Plan · III.G Assessment Plan · IV/V Records + SSI |
OPA endpoint: POST /v1/data/tsa_pipeline/main/compliance_report
The directives are largely deadline-driven, and the deadlines are what these
policies assert — each is pinned by a test in
tests/test_tsa_pipeline_deadlines.rego:
| Clock | Directive |
|---|
| 72 hours — report incident to CISA | SD-01G II.C.3 |
| 24 hours — supplemental information | SD-01G II.C.5.f |
| 7 days — Coordinator info change | SD-01G II.B.1.e |
| 60 days — "no Critical Cyber Systems" notice | SD-02G II.A.5 |
| 45 / 50 / 30 days — permanent change · amendment filing · reconsideration petition | SD-02G VI.C / VI.D / VI.F |
| 12 months, ≥ 2 objectives — Incident Response Plan exercise | SD-02G III.F.1.e |
| 24 months — cybersecurity architecture design review | SD-02G III.G.2.b |
| ⅓ per year, 100% over 3 years — assessment coverage | SD-02G III.G.2.d |
| 12 months — Assessment Plan and report submission | SD-02G III.G.3–4 |
| 24 hours — maximum packet capture period | SD-02G IV.C.2.e.ii |
No fact source exists yet. Both directives are overwhelmingly plan-,
attestation-, and recordkeeping-driven ("is there a TSA-approved Cybersecurity
Implementation Plan", "was the Assessment Plan submitted within 12 months").
None of that comes from host fact-gathering, and nothing currently emits the
input documented in each module header. On absent input this framework
reports fully non-compliant across all 12 sections — correct fail-closed
behavior for an audit framework, but not a working assessment until an
attestation intake or GRC export is wired up. Don't demo it as one.
NERC-CIP Coverage
Full library covering all active CIP standards (CIP-002 through CIP-015) in frameworks/critical_infrastructure/nerc_cip/.
OPA endpoint: POST /v1/data/nerc_cip_main
Data sources: Every input.* field used by the 14 CIP policies is documented in frameworks/critical_infrastructure/nerc_cip/DATA_SOURCES.md — each entry lists the real-world source system (GRC, CMDB, LMS, PACS, SIEM, INSM platform, vulnerability scanner, etc.), the collection method (Ansible module or REST endpoint), and whether the integration is currently live or stubbed.
Loading Policies into OPA
Single policy
curl -X PUT --data-binary @benchmarks/cis/rhel_9/pam_validation.rego \
http://localhost:8181/v1/policies/cis_rhel9_pam
All policies in a directory
for f in benchmarks/cis/rhel_9/*.rego; do
curl -s -X PUT --data-binary @"$f" \
"http://localhost:8181/v1/policies/$(basename $f .rego)"
done
Optional: splitting by domain
A single OPA instance serves this entire library comfortably — start there. If you later want
blast-radius or access isolation between domains, you can run several instances and load a
subtree into each:
# e.g. one instance per domain, each on its own port
podman run -d --name opa-benchmarks -p 8181:8181 openpolicyagent/opa run --server --addr :8181
podman run -d --name opa-frameworks -p 8182:8181 openpolicyagent/opa run --server --addr :8181
podman run -d --name opa-governance -p 8183:8181 openpolicyagent/opa run --server --addr :8181
Then load benchmarks/ into the first, frameworks/ into the second, and
governance/ + enforcement/ into the third.
The split is entirely your choice — the policies neither know nor care which instance they
are loaded into, and no policy references another instance. Pick whatever grouping matches
how you want to control access; there is nothing special about the one above.
Framework entrypoints
Every framework exposes a uniform entrypoint:
data.<package>.main.compliance_report
so you can evaluate any framework by name without learning how its modules are organised
internally. Some frameworks are a single module, others aggregate a dozen; the entrypoint
looks the same either way.
Entrypoints are named after the package that holds the policy — never after a caller's
own vocabulary. If your system spells a framework differently (cis_ubuntu_2204 where this
library says cis_ubuntu_22_04), write a thin alias on your side:
package cis_ubuntu_2204.main
import rego.v1
compliance_report := data.cis_ubuntu_22_04.main.compliance_report
Keeping that translation in your repo is what lets this one stay generic.
Fail closed
Most controls are phrased "violate if the fact says X". Given no facts, nothing
iterates, nothing violates — and a naive report would announce near-total compliance for an
assessment that measured nothing. That result is indistinguishable from a genuinely clean
system, and it is exactly the kind of thing that quietly lands in an audit record.
Every entrypoint therefore gates on whether facts were supplied at all:
| input | result |
|---|
| no facts | compliant: false, 0%, all controls counted failed, explicit FAIL-CLOSED violation |
| real facts | normal assessment; the gate is transparent |
opa eval -d . -f pretty 'data.cis_rhel9.main.compliance_report'
# compliant: false, compliance_percentage: 0, violations: ["FAIL-CLOSED: no facts supplied ..."]
An empty report is never a passing report. Limitation: the gate detects a completely
empty input, not a partial one — sparse or wrong-shaped facts still evaluate normally and can
under-report violations.
Input / Output Contract
Each framework's entrypoint accepts system facts as input and returns a structured report.
Individual modules additionally expose their own compliance_assessment / compliance_report
rules if you want a single section rather than the whole framework:
{
"compliant": false,
"summary": {
"total_controls": 338,
"passing_controls": 301,
"failing_controls": 37,
"compliance_percentage": 89.05,
"overall_compliance": "FAIL"
},
"violations": [
"1.1.1 Ensure mounting of cramfs filesystems is disabled",
"5.2.4 Ensure SSH X11 forwarding is disabled"
],
"section_compliance": {
"1_filesystem": true,
"2_services": false,
...
}
}
Use as a Git Submodule
# Add to your project
git submodule add https://github.com/ynotbhatc/rego_policy_libraries.git policies
git submodule update --init --recursive
# Update to latest
git submodule update --remote policies
git add policies && git commit -m "Update policy library"
Requirements
- Open Policy Agent v0.60+, or
Enterprise OPA (EOPA) — the policies use only
standard Rego and built-ins, so either runtime works
- All policies use
import rego.v1 (Rego v1 syntax)
- Continuously tested against OPA v1.10.0 in CI (pinned in
.github/workflows/opa-test.yml)
- Other Rego engines are not supported: rego-cpp / regopy 1.5.2 fails to load some policies and reaches different decisions on others — see docs/ENGINE_COMPATIBILITY.md
- No other dependencies — no sidecar, no data documents, no external services. Policies are
pure functions of their input and perform no I/O (no
http.send).
Consumers
This library is standalone. It has no opinion about who calls it, how facts are gathered, or
where results are stored — it is a tree of .rego files and their tests, and nothing else.
Anything specific to a particular caller — framework-key naming, routing tables, result
schemas, fact collection — belongs in that caller, not here. If you find something in this
repo that only makes sense for one consumer, that is a bug worth reporting.
Known consumers:
- AAC (Ansible Automated Compliance) — a compliance automation platform on Ansible
Automation Platform + OPA + PostgreSQL. It consumes this library as a git submodule and
keeps its own key-translation aliases and routing config on its side. (The orchestration
repo is private; this policy library is the open component.)
Using it somewhere else? Open an issue — the goal is that nothing in here requires knowing
about any of the above.
More Rego Policies on GitHub
Pointers to other great policy-as-code work in the community — full credit to the owners and authors of each project below. These are references, not vendored copies: we link to them so you can find them; the policies stay in their home repositories under their own maintainers and licenses.
Policy libraries
| Repository | Owner / Author | What it covers |
|---|
| redhat-cop/rego-policies | Red Hat Community of Practice | Kubernetes/OpenShift + general config-compliance policies for OPA, Gatekeeper, and Conftest |
| kubewarden/rego-policies-library | Kubewarden project (SUSE) | Kubernetes security & compliance admission policies (Gatekeeper/Kubewarden-compatible, compiled to Wasm) |
| conforma/policy | Conforma / Konflux-CI (Enterprise Contract) | Software supply-chain verification — image attestations, build provenance, pipeline-definition validation |
| raedrizk/ansible-policy-as-code | Raed Rizk (@raedrizk) | AAP governance / pipeline enforcement — job-template naming, EE security, fork limits, time-based access, SCM branch enforcement, superuser restrictions |
Style, linting & tooling
Credit to each project's maintainers and authors. Adding a repository? Link to it (don't copy the policies), name the owner/author, and give a one-line description.
Converters — using the library from other engines
Rego is the native language of OPA, Enterprise OPA, Conftest, Gatekeeper, Kubewarden, Trivy, KICS, Regula,
Snyk IaC, Styra, Terraform Cloud and Spacelift, so most platforms run these policies as they are. For
everything else, converters/ is the library's second product: packaging (WASM for every
language SDK, signed bundles), interchange exports (OSCAL, SARIF, OCSF, crosswalk CSV) and per-engine generators
(Ansible, SCAP, InSpec, Wazuh, CEL/Kyverno, Azure Policy, AWS Config, Steampipe, Sentinel, Sigma, Prowler).
Each target has its own directory, status and round-trip test; the roadmap and the order of work are in
converters/README.md.
Contributing
- Place new
.rego files in the appropriate taxonomy path
- Add
import rego.v1 at the top
- Expose a
compliance_assessment rule with the standard output structure
- Open a PR
License
Apache 2.0
