Rego Policy Libraries

500+ production-ready Rego policies for OPA and Enterprise OPA (EOPA), covering CIS Benchmarks (with Level 2 hardening profiles), DISA STIGs, NIST, SOC 2, PCI-DSS, ISO 27001, NERC-CIP (with full data-source reference), IEC 62443, HIPAA, FedRAMP, 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.

_{Counts move with every merge, so this README says "500+" rather than a figure that goes stale. For 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

License OPA Rego CIS RHEL 9 GitHub Stars

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 22 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.

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.

Highlight: CIS RHEL 9 v2.0.0 — 224+ distinct CIS control IDs across 17 modules (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.

Pull the pre-built bundle directly from GitHub Container Registry — no clone needed:

# Pull the full 545-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

# 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.

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
│ │ ├── postgresql/ databases/
│ │ ├── saas/m365/ # SaaS (Microsoft 365)
│ │ ├── network_devices/ # VyOS, pfSense
│ │ ├── 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 — RHEL 8/9, Ubuntu, Windows
│
├── frameworks/ # Regulatory compliance
│ ├── federal/ # NIST 800-53/171/800-82, CSF 2.0, AI RMF, FISMA, FedRAMP, CMMC
│ ├── management/ # ISO 27001, SOC 2, Corporate, NCSC CAF 4.0
│ ├── financial/ # PCI-DSS, SOX, SWIFT CSP, NY DFS, SEC Cyber
│ ├── privacy/ # GDPR, HIPAA, HITRUST, CFR Part 11, TISAX
│ ├── regulatory/ # DORA, NIS2
│ ├── 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

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.

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": ["..."] }
 }
}

Both currently-effective TSA pipeline cybersecurity directives, in frameworks/critical_infrastructure/tsa_pipeline/ — 12 section modules plus an orchestrator, covering 112 directive subparagraphs.

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:

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.

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.

curl -X PUT --data-binary @benchmarks/cis/rhel_9/pam_validation.rego \
 http://localhost:8181/v1/policies/cis_rhel9_pam

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

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.

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.

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:

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.

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,
 ...
 }
}

# 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"

• 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 v0.68 in CI and OPA v1.x locally
• 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).

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.

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.

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.

1. Place new .rego files in the appropriate taxonomy path
2. Add import rego.v1 at the top
3. Expose a compliance_assessment rule with the standard output structure
4. Open a PR

Apache 2.0