Rego Policy Libraries：面向 OPA 的合规与加固策略库

Rego 策略库

740 条生产就绪的 Rego 策略（含测试共 996 条；按 make count 统计有 7,867 项控制级检查；统计于 main 分支 2026-10-12），适用于 OPA 和 Enterprise OPA（EOPA），覆盖 CIS Benchmarks（含 Level 2 加固配置文件）、CIS Controls v8.1、DISA STIG、CISA SCuBA M365、NSA/CISA Kubernetes 加固、NIST、零信任（CISA ZTMM v2.0）、SOC 2、PCI-DSS、ISO 27001、NERC-CIP（含完整数据源引用）、IEC 62443、HIPAA、FedRAMP、FBI CJIS、IRS Pub 1075、ACSC Essential Eight、APRA CPS 234、HKMA TM-G-1/TM-C-1（香港）、MAS TRM（新加坡）、BNM RMiT（马来西亚）、CERT-In 指令与 DPDP 法案（印度）、METI 网络安全经营指南（日本）、UK Cyber Essentials、BSI C5、CSA CCM、CCPA/CPRA、EU AI Act、GEISA 等——全部采用 Rego v1 语法，可直接加载到任何 OPA 或 EOPA 实例中。

独立且无依赖：无需编排器、无需代理、无需厂商运行时。克隆、加载、查询即可。

任何人都可以验证的最大可执行合规策略开源库——跨 54 项受跟踪标准共 7,867 项控制级检查——并且是任何机器可读策略库（无论开源还是闭源）中监管覆盖范围最广的。前半部分是一个数字，CI 在每次合并时都会重新计算（make count），如果这一行发生偏移就会失败；后半部分是下面的框架列表，没有其他库能与之匹敌。我们如何针对我们能找到的每一个公共库来衡量这两者：docs/COMPARISON.md。 对比对象：Kubescape regolibrary（304 条 Rego 规则，仅 Kubernetes）、Kyverno policies（180）、Gatekeeper library（49）、trivy-checks（563）、Checkov（约 1,000，IaC）、KICS（1,813，IaC）、Prowler（1,625 项云检查）、Steampipe AWS mod（1,361）、ComplianceAsCode（2,574 条 OS 规则）、Azure Policy 内置策略（5,130，Azure）、Secure Controls Framework（1,534 项目录控制，不可执行）。无需修改即可运行于：OPA、Enterprise OPA、Styra DAS、Conftest、Gatekeeper、Kubewarden、Trivy、KICS、Regula、Snyk IaC、Terraform Cloud、Spacelift、env0、Envoy/Istio。导出为：适用于所有语言 SDK 的 WASM、签名捆绑包、OSCAL、SARIF、OCSF、Ansible、SCAP、InSpec、Wazuh、CEL/Kyverno、Azure Policy、AWS Config、Steampipe、Sentinel、Sigma、Prowler（见 converters/）。

六十秒内在 CI 中使用它：docs/INTEGRATIONS.md——拉取 GHCR 捆绑包，评估你的事实，在不符合合规要求时让作业失败；用 Conftest 做 IaC 门禁。

_{上面的计数由伴随每个合并批次的文档处理重新标记； 在批次之间它可能会略微偏低。任意提交处的确切数字：}

git ls-files | grep '\.rego$' | grep -vcE '(^|/)(test_|.*_test\.rego$)'   # policy files
git ls-files | grep -c '\.rego$'                                          # including tests

为什么选择这个仓库？

从零编写合规策略既昂贵又容易出错。一个典型企业仅为 CIS RHEL 9 部署 OPA 就需要 338 项单独的控制检查——而这还只是一个操作系统的一个框架。

这个库让你在第一天就获得一套完整、可用的策略集，覆盖 30 多个平台、55 多个监管框架，以及从 CIS 和 DISA STIG 到 NERC-CIP 和 IEC 62443 的每一项主要合规标准。所有策略：

• 使用 Rego v1 语法（import rego.v1）——无弃用警告，向前兼容
• 返回结构化 JSON 报告（合规、评分、违规列表）——可直接接入仪表板或 CI
• 可独立加载——可单独使用一个框架或整个库；无耦合
• 暴露一个统一入口点——每个框架都用 data.<package>.main.compliance_report，这样你只需按名称评估，无需了解其内部结构
• 故障关闭——未提供任何事实的框架会报告不合规并给出明确原因，绝不会静默通过（见下文）
• 供应商中立——不内置任何编排器、部署拓扑或调用方术语
• 采用 Apache 2.0 许可——可无限制地商业使用

为什么不自己构建？你可以——但仅 CIS RHEL 9 就有 14 个章节中的 338 项控制。NERC-CIP 涵盖 14 项标准（CIP-002 至 CIP-015），包含 200 多项要求。IEC 62443 在 7 项基础要求之上增加了 51 项系统要求。从零开始需要数月。这个库就是那数月的工作，已经完成。

覆盖范围一览

每个已实施的标准都在 STANDARDS_UPDATE_REGISTRY.md 中跟踪 — 固定版本、上游修订节奏和监视 URL — 因此模块会在标准变化时重新生成，而不是悄然漂移。

包含内容

亮点：CIS RHEL 9 v2.0.0 — 跨 17 个模块的 224+ 个不同 CIS 控制 ID （14 个核心 CIS 章节，外加 3 个用于 STIG/NIST 漂移检测的扩展加固模块）。

关于覆盖数字。上述控制 ID 是从模块实际发出的违规消息中统计的， 因此该数字可从一次克隆中复现：

grep -rhoE 'CIS (L2 )?[0-9]+(\.[0-9]+)*' benchmarks/cis/rhel_9 --include='*.rego' \
  | sed -E 's/CIS L2 /CIS /' | sort -u | wc -l

这是下限，而非上限 — 单条规则往往满足不止一个 CIS 控制项， 因此真实覆盖率更高。我们发布能够证明的数字，而不是无法证明的 头条百分比。

快速开始

选项 A — OCI bundle（生产环境推荐）

直接从 GitHub Container Registry 拉取预构建的 bundle — 无需克隆：

# 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

提供带版本号的标签：ghcr.io/ynotbhatc/rego_policy_libraries:v1.0.0

安装 oras：https://oras.land/docs/installation

选项 B — Git 克隆

# 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", ...}}'

以无输入进行查询，你会得到 compliant: false，并伴随一个明确的 FAIL-CLOSED 违规 — 而不是 100% 通过。这是有意为之；参见 框架入口点。

策略分类体系

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 — 19 platforms (Linux, Windows, K8s/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
│
├── 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 覆盖

IEC 62443 覆盖

面向 IEC 62443 工业自动化与控制系统（IACS）安全的完整库 — 涵盖 Part 3-3 的全部 51 项系统要求（SR）以及 Part 2 管理要求。

安全等级（SL）分层：所有 FR 模块均强制执行按 SL 区分的要求 — 违规项会标注其适用的 SL（从 SL 1 基线到 SL 4 国家支持型威胁防护）。

OPA 端点：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 管道安全指令覆盖

两项当前生效的 TSA 管道网络安全指令，位于 frameworks/critical_infrastructure/tsa_pipeline/ — 12 个章节模块外加一个 编排器，涵盖 112 个指令子段落。

OPA 端点： POST /v1/data/tsa_pipeline/main/compliance_report

这些指令在很大程度上由截止日期驱动，而这些截止日期正是这些策略所主张的——每一个都由 tests/test_tsa_pipeline_deadlines.rego 中的测试固定：

尚不存在事实来源。 这两项指令绝大多数由计划、证明和记录保存驱动（“是否存在 TSA 批准的网络安全实施计划”、“评估计划是否在 12 个月内提交”）。这些都不来自主机事实收集，目前也没有任何东西发出各模块头部所记录的 input。在输入缺失的情况下，此框架报告 全部 12 个部分均完全不合规——对于审计框架而言这是正确的故障关闭行为，但在接入证明录入或 GRC 导出之前，它并不是一个可用的评估。不要把它当作可用的来演示。

NERC-CIP 覆盖

完整库覆盖 frameworks/critical_infrastructure/nerc_cip/ 中所有现行 CIP 标准（CIP-002 至 CIP-015）。

OPA 端点： POST /v1/data/nerc_cip_main

数据源： 14 项 CIP 策略使用的每个 input.* 字段都记录在 frameworks/critical_infrastructure/nerc_cip/DATA_SOURCES.md 中——每个条目列出真实世界的来源系统（GRC、CMDB、LMS、PACS、SIEM、INSM 平台、漏洞扫描器等）、收集方法（Ansible 模块或 REST 端点），以及该集成当前是已上线还是存根。

将策略加载到 OPA

单个策略

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

可选：按域拆分

单个 OPA 实例即可轻松服务整个库——从那里开始。如果之后你希望在域之间实现爆炸半径或访问隔离，可以运行多个实例，并向每个实例加载一个子树：

# 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

然后将 benchmarks/ 加载到第一个，frameworks/ 加载到第二个，将 governance/ + enforcement/ 加载到第三个。

如何拆分完全由你决定——策略既不知道也不关心自己被加载到哪个实例，且没有任何策略引用另一个实例。选择任何符合你希望如何控制访问的分组方式；上面这个并无特别之处。

框架入口点

每个框架都暴露统一的入口点：

data.<package>.main.compliance_report

这样你就可以按名称评估任何框架，而无需了解其模块内部如何组织。有些框架是单个模块，另一些则聚合了十几个；无论哪种方式，入口点看起来都一样。

入口点以持有策略的包命名——绝不使用调用方自己的词汇。如果你的系统对某个框架的拼写不同（本库称为 cis_ubuntu_22_04 的地方你称为 cis_ubuntu_2204），请在你这边写一个薄别名：

package cis_ubuntu_2204.main

import rego.v1

compliance_report := data.cis_ubuntu_22_04.main.compliance_report

将这种转换保留在你的仓库中，才能让这个库保持通用。

故障关闭

大多数控制项的表述是 “如果事实表明 X，则违规”。在没有事实的情况下，没有任何迭代，也没有任何违规——而一份天真的报告会宣布，对于一次什么都没衡量的评估，几乎完全合规。这一结果与一个真正干净的系统无法区分，而这正是那种会悄悄进入审计记录的东西。

因此，每个入口点都会根据是否提供了事实来进行门控：

opa eval -d . -f pretty 'data.cis_rhel9.main.compliance_report'
# compliant: false, compliance_percentage: 0, violations: ["FAIL-CLOSED: no facts supplied ..."]

空报告永远不是通过的报告。限制：该门控检测的是完全为空的输入，而不是部分为空的输入——稀疏或形状错误的事实仍会正常评估，并可能少报违规。

输入 / 输出契约

每个框架的入口点接受系统事实作为输入，并返回结构化报告。各个模块还额外暴露自己的 compliance_assessment / compliance_report 规则，如果你只想要单个部分而不是整个框架：

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

作为 Git 子模块使用

# 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+，或 Enterprise OPA (EOPA)——这些策略仅使用标准 Rego 和内置函数，因此任一运行时均可
• 所有策略均使用 import rego.v1（Rego v1 语法）
• 在 CI 中针对 OPA v0.68 持续测试，并在本地针对 OPA v1.x 测试
• 没有其他依赖——没有 sidecar、没有数据文档、没有外部服务。策略是其输入的纯函数，不执行任何 I/O（没有 http.send）。

使用者

该库是独立的。它不关心谁调用它、如何收集事实或结果存储在哪里——它是一棵由 .rego 文件及其测试组成的树，仅此而已。

任何特定于某个调用者的内容——框架键命名、路由表、结果模式、事实收集——都属于该调用者，而不是这里。如果你在本仓库中发现某些内容只对某一个使用者有意义，那就是一个值得报告的 bug。

已知使用者：

• AAC（Ansible Automated Compliance）——一个基于 Ansible Automation Platform + OPA + PostgreSQL 的合规自动化平台。它将该库作为 git 子模块使用，并在自己一侧保留自己的键转换别名和路由配置。（编排仓库是私有的；该策略库是开放组件。）

在其他地方使用它？请开一个 issue——目标是这里没有任何内容需要了解上述任何一项。

GitHub 上更多 Rego 策略

指向社区中其他优秀策略即代码工作的链接——完全归功于以下每个项目的所有者和作者。这些是参考，不是内置副本：我们链接到它们以便你能找到它们；这些策略仍留在其原仓库中，由其各自的维护者和许可证管理。

策略库

样式、代码检查与工具

感谢每个项目的维护者和作者。要添加仓库？请链接到它（不要复制策略），注明所有者/作者，并给出一行描述。

转换器 — 从其他引擎使用该库

Rego 是 OPA、Enterprise OPA、Conftest、Gatekeeper、Kubewarden、Trivy、KICS、Regula、 Snyk IaC、Styra、Terraform Cloud 和 Spacelift 的原生语言，因此大多数平台按原样运行这些策略。对于 其他所有情况，converters/ 是该库的第二款产品：打包（适用于每种 语言 SDK 的 WASM、签名捆绑包）、交换导出（OSCAL、SARIF、OCSF、crosswalk CSV）以及按引擎的生成器 （Ansible、SCAP、InSpec、Wazuh、CEL/Kyverno、Azure Policy、AWS Config、Steampipe、Sentinel、Sigma、Prowler）。 每个目标都有自己的目录、状态和往返测试；路线图和工作顺序见 converters/README.md。

贡献

1. 将新的 .rego 文件放在适当的分类路径中
2. 在顶部添加 import rego.v1
3. 使用标准输出结构暴露 compliance_assessment 规则
4. 提交 PR

许可证

Apache 2.0