grc-lake 0.3.10

Turn security evidence into traceable control assessments and reviewable audit workpapers. GRC Lake is open-source and self-hosted, running in infrastructure you control. Read evidence from existing systems and security lakes, evaluate versioned rules, and preserve the evidence and review decisions behind each result.

Quick start · Product tour · Self-host · Engineering review · Coverage · Documentation

Quick start

The tour and catalog counts describe current source; see release status for changes since the published package.

Install published v0.3.9 with Python 3.11+ on macOS or Linux:

python -m venv .venv
source .venv/bin/activate
pip install "grc-lake[server]==0.3.9"
grc-lake fixtures load --company golden --out ./lake --rebase-times
grc-lake serve --server --allow-insecure-no-auth --lake ./lake --host 127.0.0.1 --port 8787

Open localhost:8787/console/dashboard/. This loopback demo uses synthetic data and disables authentication. First task: find a failing control, inspect its evidence and mapping, then export the frozen result. Follow the sample-data tutorial; continue with the synthetic workpaper example to inspect a scoped test plan, population gaps, and a verified export. The source walkthrough also shows how to verify a workpaper handoff against a separately retained content digest, including detection of a self-consistent replacement. Installation time depends on your machine and connection.

git clone --branch v0.3.9 --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[mcp]==0.3.9"
GRC_LAKE_LAKE=./lake grc-lake-mcp

Already have an Agent-Bom JSON scan report? The current-source report importer brings findings into scoped GRC evidence with explicit control bindings and retained scan provenance.

Product tour

Collect → Evaluate → Resolve → Export. Read source evidence, run version-pinned control tests, investigate findings, and export a scoped assessment.

Start with the assessment overview

See assessed coverage, open findings, evidence freshness, and priority actions together. Framework posture distinguishes assessed results from requirements that still need evidence.

Explore framework coverage

Browse framework packs and their requirements, compare mapped and reviewed coverage, and open the controls or mappings that need attention. Catalogued, mapped, reviewed, and assessed requirements remain separate measures.

Inspect control results and evidence

Filter the control worklist by result, owner, or framework. Open a control to inspect its evidence, findings, freshness, and test confidence.

Navigate control families and the CCF

The Common Control Framework (CCF) organizes reusable safeguards into categories and control families. Explore their links to framework requirements and see reviewed and proposed mappings separately. 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. Select a node to inspect it; drill into its connections or roll up to the previous view. Depth and layer controls keep the investigation focused.

Review AI assets and their next actions

The model and agent worklist brings owners, environments, governance signals, and next actions together. Open an asset's linked controls or filtered evidence; recorded lineage remains distinct from freshly evaluated controls.

A model card documents a model's intended use, limitations, and evaluation. Model card not observed means no card signal was collected for that asset; the document may exist elsewhere. The synthetic demo includes inventory and lineage observations without model-card signals. Recorded means evidence presence, not verified content, freshness, or a passing control. See AI inventory semantics.

Screens use the bundled synthetic company, captured for v0.3.9 from source 0823048b on 2026-10-19 (America/New_York). They show recorded relationships and demo workflows, not a customer deployment or an audit opinion.

Try the five-minute console tour · How evidence investigation works

Architecture

Read-only collection feeds deterministic evaluation. Each published assessment retains verified artifact hashes; snapshots form a hash-chained ledger. Console, REST API, CLI, and MCP expose the same 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"]

For an offline standards handoff, export a portable CCF/OSCAL bundle with resolvable framework catalogs, reviewed mappings, and document checksums.

For a review across SOC 2, ISO, and NIST, the current-source framework coverage report exports frozen catalog counts, mapping-review gaps, and evidence results as an offline HTML/JSON bundle.

Use direct connectors or read an existing lake. Both materialize assessment evidence into storage you operate. Reader compatibility, schema mapping, and live qualification vary; check the connector catalog.

Queued assessments retain tenant-scoped result receipts. Pagination, queue admission, response storage, and retries have explicit bounds. See the assessment contract and architecture guide for recovery behavior and API limits.

Engineering review

Start with one control and follow its source evidence through a retained assessment into a verified workpaper. The synthetic access/change workflow runs passing, failing, missing, stale, conflicting, and incomplete-population cases with explicit expectations and retained inputs.

Run checks from the revision being reviewed; the CI badge above tracks main. Benchmark receipts identify their own revisions and workloads. A local synthetic pass does not establish provider completeness, production capacity, or an audit opinion. Current qualification records those boundaries.

Self-host

Deploy with Docker or Helm on your infrastructure:

• Local: one writable replica with a filesystem lake.
• Distributed: API replicas and tenant workers share PostgreSQL and S3-compatible storage. CLI assessments use a filesystem lake; MCP uses the authenticated API for distributed deployments.
• Production: configure SSO and scoped credentials, retention, and backup/restore.

See deployment compatibility and the distributed guide. Production capacity and provider failover require deployment-specific qualification.

Release packages include signed provenance and an SBOM. Follow artifact verification. Upgrading from TrustOps? Read the migration guide.

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.
• 25 read-only source adapters (7 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.

Explainable audit readiness: the API and audit room show score, evaluated-framework, and blocking-gap gates. A high index cannot hide an unresolved framework assessment. See the decision contract and reproducible regression.

Catalog counts above are generated from source. Reviewed counts record maintainer mapping decisions; see the review method and limits. Mapping-review decisions do not change access at a provider.

Framework coverage · Common safeguards · Qualification and test coverage

Fixture tests and screenshots do not establish live-provider accuracy, production capacity, or certification. See audit readiness for qualification boundaries and the roadmap for remaining gaps.

Documentation

All documentation. Regenerate the header and counts with make readme-header; capture demo screens with make demo-screenshots-full. License: Apache 2.0.