GRC Lake

将安全证据转化为可追溯的控制评估和可审阅的审计底稿。 开源且可自托管：从你已在运行的系统和安全数据湖中读取证据，评估有版本控制的控制测试，并将证据和记录的审阅决策与结果一并保留。

• **可追溯：**追溯结果所依据的源记录和规则版本，并检查记录的映射决策；快照构成哈希链账本，可供重新验证。
• **兼容现有系统：**直接连接云、身份、终端和代码系统，或查询数据湖中已有的 OCSF 表。
• **一个控制，多种框架：**可复用的保障措施映射到 SOC 2、ISO 27001、NIST 等框架，并将已审阅的映射与提议的映射分开保存。

打开在线演示 → 点击浏览基于已记录合成数据的控制台。托管演示为只读；它不会连接你的系统，也不代表已覆盖实时服务提供商。无需安装。

快速开始 · 产品导览 · 连接证据 · 已使用 OCSF？ · 框架 · 性能 · 自托管 · 文档

快速开始

Python 3.11+ 和 uv：

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

此命令会将一家合成公司加载到临时数据湖中，在无需身份验证的情况下于 localhost:8787 提供控制台服务，并打开浏览器。按 Ctrl+C 可停止服务并删除数据湖。使用 pip： pip install "grc-lake[server]"，然后运行 grc-lake demo。

**第一个任务：**找到一项未通过的控制，检查其证据和映射，并导出冻结结果：先按照示例数据教程操作，再查看审计员底稿示例。

如需进行实际评估，请遵循有限范围试点指南：先使用一个来源，独立核查一项结果，然后重复采集并审阅。

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

采集 → 评估 → 解决 → 导出。 这些控制台截图使用随附的合成公司数据，并已针对 0.3.17 版本刷新。它们展示的是源代码行为；有关已发布软件包的验证，请参阅 发布记录。

从评估概览开始

在一个视图中查看已评估覆盖率、未解决发现、证据时效性和优先操作。

浏览框架覆盖情况

每个框架分别统计已编目、已映射、已审查和已评估的要求。

检查控制结果和证据

按结果、负责人或框架筛选；打开某项控制，查看其证据、发现、时效性和可信度。

浏览控制族和 CCF

通用控制框架 (CCF) 将可复用的防护措施归入不同控制族，并关联到框架要求。拟议映射不能用于鉴证。 通用防护措施的工作方式。

沿证据图追踪发现

在控制、防护措施、证据、代码库和资产之间追踪准确记录；可深入查看，也可汇总查看。

查看 AI 资产及其后续操作

模型和 Agent 均显示负责人、环境、治理信号和后续操作。 记录的沿袭信息表示存在证据，并不代表控制已通过 （AI 清单语义）。

五分钟控制台导览 · 证据调查的工作方式

架构

只读采集为确定性评估提供数据；控制台、REST API、CLI 和 MCP 共用同一套证据与评估模型。

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"]

导出内容：可移植的 CCF/OSCAL 捆绑包、 框架覆盖率报告和可验证的 审计员工作底稿。恢复行为和 API 限制： 架构指南和评估契约。

连接证据

使用直接连接器，或 读取现有数据湖。两者均为只读，并会将 评估证据保存在由你运营的存储中。

已经使用 OCSF？

如果你的遥测数据已规范化为 OCSF，例如存储在 Amazon Security Lake 或 Databricks、Snowflake 上的 OCSF 表中，可将 GRC Lake 指向这些表。保留现有的数据源摄取管道：GRC Lake 会运行只读查询，保留映射后的副本，并评估导入的行。内置预设会将事件关联到 CCF 安全措施， 框架要求则遵循每项安全措施经审核的交叉映射：

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

覆盖度包含几个不同层面：已编入目录的要求、已审核的映射和已评估的结果彼此独立。请先查看各框架覆盖矩阵；建议中的映射无法证明已通过认证。

框架覆盖度 · 通用保障措施 · 审计就绪度 · 资质认定

性能与资质认定

已接受的本地图谱配置使用两个租户进行测试，每个租户最多包含 10k 条合成记录，并有四个并发客户端。其限制为：成功请求的预热 p95 ≤500 ms，首次读取或缓存过期后的读取 ≤5 秒，进程 RSS ≤1 GiB，且过载时两个租户仍能持续推进。已记录的三次运行均通过。准入拒绝和速率限制拒绝会单独报告；这并不保证过载时每个请求都能成功。

此配置仅涵盖本地 SQLite 上经身份验证的深度为一级的图谱读取。它不代表已验证 100k 规模的交互使用、浏览器渲染、外部存储或生产环境容量规划。请另行查看提供方资质认定和已验证的发布记录。

有限范围的实时运行会记录为收据，并针对提供方核查每项判定：AWS 和 GitHub 试点从没有框架结果进展到 103 项要求未通过、1 项通过认证；以及基于已填充审计日志的 Databricks 运行。每次运行均只涵盖一个账户或工作区，不代表已完成提供方范围的资质认定。

自托管

使用 Docker 或 Helm 部署到你掌控的基础设施上：

• 本地： 使用文件系统数据湖的单个可写副本。
• 分布式： API 副本和租户工作器共享 PostgreSQL 和兼容 S3 的 存储（分布式指南）。
• 生产环境： SSO 和范围限定的凭据、 保留策略和备份/恢复。

发布版本附带经过签名的来源证明和 SBOM（验证制品）。 从 TrustOps 升级？请阅读迁移指南。

工程审查

从一个控制项入手，沿着其证据追溯到经过验证的工作底稿： 合成访问/变更工作流涵盖通过、 失败、缺失、过时、冲突和总体不完整等情况。

文档

全部文档 · 许可证：Apache 2.0