Policy-as-Code Demo

Compliance and security policy expressed as versioned, testable code instead of a PDF checklist — with automated scanning that turns each control into a pass/fail signal and ships violations to a SIEM.

Two complementary engines, one scan runner, mapped to public frameworks (NIST CSF 2.0, CIS Controls v8, CIS Ubuntu 24.04 / Docker benchmarks).

The two engines

Engine	Question it answers	Here
InSpec / Cinc Auditor	"Is this host actually configured the way policy says?" — runtime state of a real system	7 system-hardening profiles
Open Policy Agent (OPA / Rego)	"Does this request / config decision comply with policy?" — declarative allow/deny over structured input	4 policy domains + unit tests

The split mirrors how the two tools are actually used: InSpec inspects a machine that already exists; OPA evaluates a proposed decision before it takes effect. A real compliance posture needs both.

Architecture

 ┌────────────────┐ ┌──────────────┐ ┌────────────────────┐
│ Cinc Auditor │ │ OPA │ │ Scan Runner │
│ 7 host profiles│ │ 4 Rego domains│ │ (run-scan.sh, │
│ │ │ + tests │ │ cron-scheduled) │
└───────┬────────┘ └──────┬───────┘ └─────────┬──────────┘
│ │ │
└───────────────────┴─────────────────────┘
│ pass/fail + violations
▼
┌───────────┐ ┌───────────────┐
│ syslog ├─────►│ SIEM (alerts, │
│ (local0) │ │ dashboards) │
└───────────┘ └───────────────┘

The scan runner executes every InSpec profile and evaluates the OPA policies against the running OPA server, computes an InSpec compliance score (OPA results are logged pass/fail), and logs each violation to syslog with a profile tag (inspec / opa / compliance-scan) so a SIEM can alert and trend on them.

Layout

policies/
opa-policies/ # OPA / Rego — declarative policy decisions
access-control/ # authn/authz, MFA, session, privilege
network-security/ # segmentation, port policy, encryption
data-protection/ # classification, encryption-at-rest/in-transit
logging-monitoring/ # audit logging requirements
tests/ # `opa test` unit tests for the above
system-hardening/ # InSpec / Cinc — host configuration validation
ssh-hardening/ ufw-validation/ auditd-config/
docker-hardening/ file-permissions/ logging-validation/ user-accounts/
ci/
run-scan.sh # execute all profiles + OPA, score, log to syslog
setup-cron.sh # install the scan as a scheduled job
POLICY_METADATA.yaml # policy domain → framework control mappings

Framework mappings

Every policy domain is mapped to the controls it satisfies in POLICY_METADATA.yaml, so a scan result traces back to a framework requirement:

Domain	NIST CSF 2.0	CIS Controls v8
access-control	PR.AA	5, 6
network-security	PR.DS, PR.IR	12, 13
data-protection	PR.DS	3
logging-monitoring	DE.CM	8
system-hardening	PR.PS	4 (+ CIS Ubuntu 24.04 / Docker, subset)

Running it

# OPA policy unit tests
opa test policies/opa-policies/ -v
# A single InSpec/Cinc profile against the local host
cinc-auditor exec policies/system-hardening/ssh-hardening
# Full scan (all profiles + OPA eval + syslog), as the runner does
./ci/run-scan.sh

Design notes

• Policy is code, so it's tested. The OPA domains ship with opa test unit tests — the policies themselves have a pass/fail suite, the same as any other code.
• Default-deny. The network policy starts from default allow := false and allows explicitly; nothing is permitted by omission.
• Framework-traceable. A failing control maps to a named NIST/CIS control via the metadata, so a scan result is auditable, not just a number.
• SIEM-native output. Violations go to syslog with stable tags, so detection/alerting lives in the SIEM rather than in bespoke scripting.

Stack

Open Policy Agent (Rego) · Cinc Auditor / InSpec · Bash · syslog → SIEM (Wazuh/OpenSearch-style) · framework mappings to NIST CSF 2.0 & CIS Controls v8.

Example/demo content — network ranges and host specifics are illustrative.