GRC Lake

io.github.koda-ai-studio由 GitHub 帳號 koda-ai-studio 發布v0.3.26更新於 Nov 3, 2026

唯讀連接器;本機寫入。為代理程式提供證據與評估。僅由人核准。

AI 翻譯由 AI 模型根據下方的原文描述翻譯,可能有誤。

原文描述

Read-only connectors; local writes. Evidence and assessments for agents. Only people approve.

已驗證STDIO僅桌面安全與監控資料與分析

概覽

GRC Lake 的本機 MCP 服務;無需登入;STDIO。

暫無 AI 概覽:以下資訊來自註冊中心條目和服務本身。

安裝

在 SourceWeft 中

  1. 開啟 儀表板中的 GRC Lake,將其新增到工作區。
  2. 為需要使用其工具的對話啟用該服務。

Desktop only,透過 STDIO。 STDIO 服務會啟動本機處理程序,因此需要 SourceWeft 桌面主機。

其他 MCP 客戶端

參照 儲存庫 中的啟動說明。

README

[GRC Lake — collect, evaluate, resolve, and export: read-only evidence from cloud, identity, code, and data sources, evaluated through a common control framework and framework packs.]

[PyPI version] [Python 3.11+] [CI status] [License: Apache 2.0] [OpenSSF Scorecard] [OpenSSF Best Practices]

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 retain evidence and recorded review decisions alongside the results.

  • Traceable: follow results to source records and rule versions, and inspect the recorded mapping decisions; 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 recorded synthetic data. The hosted demo is read-only; it does not connect to your systems or establish live-provider coverage. Nothing to install.

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

Quick start

Python 3.11+ and uv:

bash
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. Their CLI steps need the lake to outlive the demo, so start it with grc-lake demo --lake ./lake.

Exploring AI assets? The AI discovery walkthrough in 0.3.21 opens a synthetic model-and-agent inventory with one command, then follows recorded evidence into the graph and assessment.

For a real evaluation, follow the bounded pilot guide: one source, one independently checked result, then a repeat collection and review.

Use it in CI. From v0.3.24, one step posts a framework readiness table to the job summary and can gate the merge (CI gate).

yaml
- uses: koda-ai-studio/[email protected]  with:    grc-lake-url: ${{ secrets.GRC_LAKE_URL }}    api-token: ${{ secrets.GRC_LAKE_API_TOKEN }}
Keep a lake, Docker, source development, or MCP

Keep a lake between runs:

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

Docker (public image, no registry login):

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

Current source, with uv and Node 22+:

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

MCP over stdio (headless GRC covers agent credentials):

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

Release notes: changelog · verified release records.

Product tour

Collect → Evaluate → Resolve → Export. These console captures use the bundled synthetic company, refreshed for the 0.3.24 release candidate. They illustrate source behavior; see the release records for published-package verification.

Start with the assessment overview

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

[Overview showing assessment coverage, findings, stale evidence, framework posture, and priority actions]

Explore framework coverage

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

[Frameworks showing requirement coverage, mapping-review status, and the framework roster]

Inspect control results and evidence

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

[Controls worklist showing test results, evidence freshness, confidence, and owners]

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 through a bounded neighborhood. Inspect control-test results, evidence freshness, and linked findings with their owners and next actions. Recorded links and mapping review states stay distinct; a passing control test does not establish framework attestation.

[Evidence investigation graph with a SOC 2 control selected, showing recorded evidence relationships and an inspector that separates the control-test result, framework assessment, and mapping review state]

For node labels and inspector details, open the full-size graph: light theme · dark theme.

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).

[AI model and agent worklist showing owners, governance signals, and next actions]

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.

mermaid
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.

Supported sources
CategorySources
CloudAWS, Microsoft Azure, Google Cloud; Kubernetes (preview, including GPU clouds); Lambda (preview)
IdentityOkta (directory and System Log), Google Workspace, Microsoft Entra (preview), generic identity provider
EndpointMicrosoft Intune; Jamf, CrowdStrike Falcon (preview)
CodeGitHub, GitLab
Vulnerability scanningSnyk (preview)
People and trainingBambooHR, Rippling, Workday; training-completion exports from any LMS (preview)
Workflow and detectionsAtlassian Jira, ticketing, SIEM alerts, AI runtime gateway
Existing lakesSnowflake, ClickHouse, S3 object storage, OCSF presets; Databricks, BigQuery, Iceberg/Parquet (preview)
ImportsAgent-Bom scan reports, CycloneDX and SPDX AI bills of materials

Stages, permissions, and live receipts: connector catalog · qualification matrix. Missing a source? Request a connector or build one.

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. Keep your existing source-ingestion pipeline: GRC Lake runs read-only queries, retains a mapped copy and evaluates the rows it imports. Built-in presets bind events to CCF safeguards, and framework requirements follow each safeguard's reviewed crosswalk:

mermaid
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 · …"]
What the rules conclude, and a Databricks example

The rules state only what an event shows. A successful logon with MFA passes for that user; one without MFA is open. A privilege grant, including adding a user to a group, blocks an access-review pass until someone reviews it, but is not a failure. Vulnerability findings and configuration checks keep their own status and bind a safeguard only for resource types with a clear catalog equivalent. Failed sign-ins, API activity, and detection findings stay unbound. Proposed crosswalk mappings are never attested.

bash
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-lakegrc-lake frameworks assessment --lake ./lake

Preview a preset against sample rows with grc-lake lake map --dry-run. Rules, limits, and Snowflake, ClickHouse, BigQuery, and Iceberg setup: OCSF events in the CCF.

Frameworks

Coverage means several different things: a catalogued requirement, a reviewed mapping and an assessed result are separate. Start with the per-framework coverage matrix; proposed mappings cannot establish an attested pass.

Catalog and reviewed-mapping counts
  • Reviewed requirements by framework: SOC 2 49/61, ISO 27001 43/93, HIPAA 0/24, PCI DSS 0/12 (top-level), NIST CSF 2.0 72/106, NIST SP 800-53 399/1,014 (381 source-native self-maps). Every pack is in the coverage matrix.
  • 22 framework packs, 2,284 catalogued requirements (1,997 distinct; FedRAMP Moderate's 287 rows restate NIST SP 800-53 controls), linked through 1,200 safeguards, including source-native assessment contracts. 2,198 requirements have safeguard mappings; 886 have reviewed mappings and the other 1,312 are proposed. Of the reviewed, 381 are source-native self-maps (written from that requirement's own pinned source) and 505 rest on reviewed crosswalk mappings; 0 rest only on legacy reviews with no recorded reviewer. The blended total is not a per-framework readiness figure. Every reviewed mapping names one maintainer reviewer across 3 review receipts; no independent second review is recorded yet (review method).
  • 28 executable adapters (18 implemented, 10 preview) and 3 configuration boundaries. Read-only provider collection includes 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

What these numbers mean

Counts are generated from source. Reviewed counts record maintainer mapping decisions (review method and limits); mapping decisions do not change access at a provider. The audit-readiness index shows score, evaluated-framework, and blocking-gap gates, so a high score cannot hide an unresolved framework assessment. Fixture tests, screenshots, and the demo do not establish live-provider accuracy, production capacity, certification, or an audit opinion; see the roadmap for remaining gaps.

Performance and qualification

The accepted local graph profile exercises two tenants with up to 10k synthetic records each and four concurrent clients. Its limits are successful warm p95 ≤500 ms, first/expired reads ≤5 seconds and process RSS ≤1 GiB, with both tenants continuing to progress under overload. Three recorded runs passed. Admission and rate-limit rejections are reported separately; this is not a promise that every request under overload succeeds.

This profile covers authenticated depth-one graph reads on local SQLite. It does not qualify 100k interactive use, browser rendering, external storage or production sizing. Check provider qualification and verified release records separately.

Bounded live runs are recorded as receipts with every verdict checked against the provider: an AWS and GitHub pilot that moved from no framework results to 103 failing requirements and one attested pass, and a Databricks run on a populated audit log. Each covers one account or workspace, not provider-wide qualification.

Self-host

Deploy with Docker or Helm on infrastructure you control:

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.

Where to look for each review question
QuestionStart here
How do the layers fit together?Architecture and source map, data flow
What makes a result pass, fail, or remain unknown?Evaluation semantics, population reconciliation
What prevents cross-tenant access and unauthorized decisions?Trust boundaries, identity and scopes
What happens after partial writes, retries, or interrupted jobs?Generation publication, operation contracts
How are integrity and reproducibility checked?Workpaper qualification, backup and restore
What performance has actually been measured?Pipeline measurements, accepted local graph profile

Run checks from the revision under review; the CI badge tracks main, and benchmark receipts name their own revisions and workloads.

Documentation

TaskGuide
Try the consoleProduct walkthrough
Connect evidenceConnector setup · Existing lakes
Integrate an agentHeadless GRC · Agent API
Operate a deploymentDeployment · Operations
ContributeContributing · Security

All documentation · License: Apache 2.0

來源:README.md,提交 874db2c

工具

0
SourceWeft 尚未在沙箱中啟動過該軟體包,因此其工具未知。

版本歷史

5
  1. v0.3.26最新Nov 3, 2026
  2. v0.3.23Nov 1, 2026
  3. v0.3.22Nov 1, 2026
  4. v0.3.21Oct 31, 2026
  5. v0.3.20Oct 29, 2026

評分

已滿足適用檢查項的 50%

該評分衡量此收錄條目的完整程度,依據註冊中心條目、端點與公開來源計算得出。它不是對伺服器本身的評價,也不表示伺服器安全或目前可用:可連通性是帶日期的檢查結果,評分也不包含安裝量或使用者評價。

  • 近 30 天內可連通25 分

    請保持端點能夠回應 MCP 握手;SourceWeft 每 30 天探測一次。

  • 已宣告認證方式10 分

    請在註冊中心條目中宣告憑證請求標頭,或保持端點能夠回應探測,以便判定其認證方式。

  • 已列出工具15 分

    請讓伺服器在無憑證時回應 tools/list,或發布可在沙箱中無憑證啟動的軟體包。

  • 描述必需15 分
  • 圖示10 分
  • 文件15 分
  • 授權條款10 分