Signed compliance evidence (GRC)

Auditors don't want a PDF they have to trust — they want signed, machine-readable evidence of every control check, verifiable without re-running anything. In this session a GRC engineer asks Claude to prove a system meets its CIS Ubuntu 24.04 Level 1 baseline before release.

The default cilock already includes the compliance attestors (oscap, inspec, kube-bench, prowler, steampipe). This team went further and composed a trimmed cilock-grc with the rookery builder that carries the oscap attestor and the GRC family and little else. The stock binary runs every command below the same way.

What it does, step by step

1. Confirm the tool exists. cilock-grc attestors list shows oscap (and the rest of the GRC family) compiled into this binary — composed earlier with the builder.
2. Run the CIS scan under CI/lock. cilock-grc run --step compliance-scan -a environment,oscap --capture-mode walk -- oscap xccdf eval --profile cis_level1_server … wraps the OpenSCAP scan. (oscap exits 2 when rules fail — expected; the findings are in the results file.) The result is a signed oscap attestation.
3. Open the evidence. Claude pulls the scanSummary from the signed attestation — 220 pass / 113 fail on CIS L1 (≈66% of evaluated rules) — and the high-severity failures: the system permits empty passwords (no_empty_passwords_unix, sshd_disable_empty_passwords).
4. Visualize the flow from scan → signed attestation → policy → control frameworks.
5. Verify against the baseline. The signed policy's compliance-baseline Rego rule blocks any release with a high-severity failure, so cilock-grc verify returns Verification failed and exits non-zero. See policy verification.
6. Write the auditor report. The real posture, the high-severity failures, and the CIS L1 / NIST 800-53 (IA-5) / FedRAMP mapping are captured into a report the auditor reads instead of re-running the scan.

The rest of the GRC toolbox

The same pattern — wrap a compliance tool, sign the result, gate on a policy, map to controls — works across the GRC scanners. They're all rookery plugins you can compile into your binary:

Why GRC teams care

• The scan result is tamper-evident evidence, mapped to CIS L1 / NIST SP 800-53 / FedRAMP — an auditor verifies the signature and reads it.
• It uses the same evidence model as build, scan, and runtime — one pipeline, many control regimes.
• A signed policy turns the baseline into an automatic, continuous gate, and the generated report is the durable audit record of exactly what was checked.