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 · Coverage · Documentation
Quick start
Published v0.3.3, with Python 3.11+ on macOS or Linux:
python -m venv .venv
source .venv/bin/activate
pip install "grc-lake[server]==0.3.3"
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. Installation time depends on your machine and connection.
Docker, source development, or MCP
The public Docker image needs no registry login. Use the published templates:
git clone --branch v0.3.3 --depth 1 https://github.com/koda-ai-studio/grc-lake.git
cd grc-lake
docker compose up
For current source, with uv and Node 22+:
git clone https://github.com/koda-ai-studio/grc-lake.git
cd grc-lake
uv sync --frozen --extra dev --extra server
make demo-local
For MCP over stdio:
pip install 'grc-lake[mcp]'
GRC_LAKE_LAKE=./lake grc-lake-mcp
See headless GRC for agent credentials and authority.
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.
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.
Screens use the bundled synthetic company, captured for v0.3.3 from source
27b21b16 on 2026-10-12. 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"]
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.
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
- 20 framework packs, 2,252 catalogued requirements (1,965 distinct; FedRAMP Moderate's 287 rows restate NIST SP 800-53 controls), linked through 96 common safeguards. 1,417 requirements have safeguard mappings; 339 have reviewed mappings and the other 1,078 are proposed.
- 25 read-only source adapters (7 in preview), plus OCSF presets for existing security lakes.
- Fails closed: missing, stale, or partial evidence never produces a pass, and proposed mappings are not attestable.
- One engine, four surfaces: console, REST API, CLI, and MCP server. Agents propose; humans approve.
Catalog counts above are generated from source. 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
| Task | Guide |
|---|---|
| Try the console | Product walkthrough |
| Connect evidence | Connector setup · Existing lakes |
| Integrate an agent | Headless GRC · Agent API |
| Operate a deployment | Deployment · Operations |
| Contribute | Contributing · Security |
All documentation. Regenerate the header and counts with
make readme-header; capture demo screens with make demo-screenshots-full.
License: Apache 2.0.
Metadata
Release files for grc-lake 0.3.4
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| grc_lake-0.3.4.tar.gz | 3.5 MB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| grc_lake-0.3.4-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 6.9 MB
Release files / grc_lake-0.3.4.tar.gz
| Download URL | grc_lake-0.3.4.tar.gz |
|---|---|
| Size | 3.5 MB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
a72aac434f2e014ca130cfb551a68d1154667563baf4c4ebcbb7ab3ea454975f
|
|
BLAKE2b-256 checksum How to use checksums |
4fafc70c3a391e1b7bf732cb11986a0523c9f7300d4e22f0d88598b9190515a4
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 13, 2026.
Transparency logRelease files / grc_lake-0.3.4-py3-none-any.whl
| Download URL | grc_lake-0.3.4-py3-none-any.whl |
|---|---|
| Size | 3.4 MB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
fc1db4fc4fca4f699df473300c368ff798002ea319b0b89d55f43a59f073c8f8
|
|
BLAKE2b-256 checksum How to use checksums |
00b6ad15d33201077b841f7b73ac5eccf0cd68b7cc7f1cdd2582158f3361e1c4
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 13, 2026.
Transparency log