grc-lake 0.3.11

Turn security evidence into traceable control assessments and reviewable audit workpapers. Open-source and self-hosted: read evidence from the systems and security lakes you already run, evaluate versioned control tests, and keep the evidence and review decisions behind every result.

• Traceable: each result links to its source records, rule version, and review decision; snapshots form a hash-chained ledger you can re-verify.
• Works with what you have: connect cloud, identity, endpoint, and code systems directly, or query OCSF tables already in your lake.
• One control, many frameworks: reusable safeguards map to SOC 2, ISO 27001, NIST, and more, with reviewed and proposed mappings kept apart.

Open the live demo → Click through the console on synthetic data. Nothing to install.

Quick start · Product tour · Connect evidence · Already on OCSF? · Frameworks · Self-host · Docs

Quick start

Python 3.11+ and uv:

uvx --from "grc-lake[server]" grc-lake demo

This loads a synthetic company into a temporary lake, serves the console on localhost:8787 without authentication, and opens your browser. Ctrl+C stops it and deletes the lake. With pip: pip install "grc-lake[server]", then grc-lake demo.

First task: find a failing control, inspect its evidence and mapping, and export the frozen result: follow the sample-data tutorial, then the auditor workpaper example.

grc-lake fixtures load --company golden --out ./lake --rebase-times
grc-lake serve --server --allow-insecure-no-auth --lake ./lake

git clone --branch v0.3.11 --depth 1 https://github.com/koda-ai-studio/grc-lake.git
cd grc-lake && docker compose up

git clone https://github.com/koda-ai-studio/grc-lake.git
cd grc-lake && uv sync --frozen --extra dev --extra server && make demo-local

pip install "grc-lake[server,mcp]"
GRC_LAKE_LAKE=./lake grc-lake-mcp

Product tour

Collect → Evaluate → Resolve → Export. Screens use the bundled synthetic company.

Start with the assessment overview

Assessed coverage, open findings, evidence freshness, and priority actions in one view.

Explore framework coverage

Catalogued, mapped, reviewed, and assessed requirements stay separate measures per framework.

Inspect control results and evidence

Filter by result, owner, or framework; open a control for its evidence, findings, freshness, and confidence.

Navigate control families and the CCF

The Common Control Framework (CCF) groups reusable safeguards into families linked to framework requirements. Proposed mappings are not attestable. How common safeguards work.

Trace a finding through the evidence graph

Follow exact records between controls, safeguards, evidence, repositories, and assets; drill in or roll up.

Review AI assets and their next actions

Models and agents with owners, environments, governance signals, and next actions. Recorded lineage is evidence presence, not a passing control (AI inventory semantics).

Five-minute console tour · How evidence investigation works

Architecture

Read-only collection feeds deterministic evaluation; console, REST API, CLI, and MCP share one evidence and assessment model.

flowchart LR
  Sources["Cloud · identity · code · existing lakes"] --> Collect["Read-only collection"]
  Collect --> Evaluate["Version-pinned control tests"]
  Evaluate --> Assessments["Assessment generations"]
  Assessments --> Review["Console · API · CLI · MCP"]
  Assessments --> Export["Snapshots · workpapers · OSCAL"]

Exports: portable CCF/OSCAL bundles, framework coverage reports, and verifiable auditor workpapers. Recovery behavior and API limits: architecture guide and assessment contract.

Connect evidence

Use direct connectors or read an existing lake. Both are read-only and keep assessment evidence in storage you operate.

Already on OCSF?

If your telemetry is already normalized to OCSF, for example in Amazon Security Lake or OCSF tables on Databricks or Snowflake, point GRC Lake at those tables. No new pipeline: the reader runs read-only queries and keeps a mapped copy of the rows it assesses. Built-in presets bind events to CCF safeguards, and framework requirements follow each safeguard's reviewed crosswalk:

flowchart LR
  A["OCSF Authentication 3002<br/>successful Logon, is_mfa"] --> S1["SG-IDENTITY-001<br/>Logical access and MFA"]
  B["OCSF Account Change 3001<br/>Attach Policy"] --> S2["SG-IDENTITY-002<br/>Access review"]
  G["OCSF Group Management 3006<br/>Add User, Assign Privileges"] --> S2
  V["OCSF Vulnerability Finding 2002<br/>EC2 instance, ECR image"] --> S3["SG-VULNERABILITYMANAGEMENT-001<br/>Vulnerability management"]
  C["OCSF Compliance Finding 2003<br/>EC2 instance"] --> S4["SG-CONFIGBASELINE-001<br/>Hardened configuration baselines"]
  S1 --> R1["SOC 2 CC6.1 · NIST 800-53 IA-2<br/>CIS AWS 1.10 · …"]
  S2 --> R2["SOC 2 CC6.2 · ISO 27001 A.8.2 · …"]
  S3 --> R3["SOC 2 CC7.1 · ISO 27001 A.8.8<br/>NIST 800-53 RA-5 · …"]
  S4 --> R4["NIST CSF PR.PS-01 · …"]

CREDS='{"host":"dbc-example.cloud.databricks.com","warehouse_id":"abc123","catalog":"security",
        "schema":"ocsf","client_id":"<sp-client-id>","client_secret_ref":"DATABRICKS_CLIENT_SECRET"}'
OPTS='{"mappings":[{"preset":"ocsf/authentication","source":{"table":"ocsf_events"}},
                   {"preset":"ocsf/account_change","source":{"table":"ocsf_events"}}]}'
grc-lake connectors probe --lake ./lake --connector-id databricks-evidence-lake \
  --credentials-json "$CREDS" --options-json "$OPTS"
grc-lake connectors configure --lake ./lake --connector-id databricks-evidence-lake \
  --state enabled --credentials-json "$CREDS" --options-json "$OPTS"
grc-lake connectors sync --lake ./lake --connector-id databricks-evidence-lake
grc-lake frameworks assessment --lake ./lake

Frameworks

• Reviewed requirements by framework: SOC 2 33/61 (10 with no recorded reviewer), ISO 27001 17/93 (10 with no recorded reviewer), HIPAA 4/24 (4 with no recorded reviewer), PCI DSS 0/12 (top-level), NIST CSF 2.0 72/106, NIST SP 800-53 495/1,014 (381 source-native self-maps; 96 with no recorded reviewer). Every pack is in the coverage matrix.
• 21 framework packs, 2,282 catalogued requirements (1,995 distinct; FedRAMP Moderate's 287 rows restate NIST SP 800-53 controls), linked through 1195 safeguards, including source-native assessment contracts. 2,196 requirements have safeguard mappings; 1,163 have reviewed mappings and the other 1,033 are proposed. Of the reviewed, 381 are source-native self-maps (written from that requirement's own pinned source) and 782 rest on reviewed crosswalk mappings; 339 rest only on legacy reviews with no recorded reviewer. The blended total is not a per-framework readiness figure.
• 28 read-only source adapters (10 in preview), plus OCSF presets for existing security lakes.
• Evidence stays scoped: missing or stale evidence leaves gaps; a passing sample does not prove complete population coverage. Proposed mappings are not attestable.
• One engine, four surfaces: console, REST API, CLI, and MCP server. Agents propose; humans approve.

Framework coverage · Common safeguards · Audit readiness · Qualification

Self-host

Deploy with Docker or Helm on infrastructure you control:

• Local: one writable replica with a filesystem lake.
• Distributed: API replicas and tenant workers share PostgreSQL and S3-compatible storage (distributed guide).
• Production: SSO and scoped credentials, retention, and backup/restore.

Releases ship signed provenance and an SBOM (verify artifacts). Upgrading from TrustOps? Read the migration guide.

Engineering review

Start with one control and follow its evidence into a verified workpaper: the synthetic access/change workflow runs passing, failing, missing, stale, conflicting, and incomplete-population cases.

Documentation

All documentation · License: Apache 2.0