transilienceai/denali 来源：https://github.com/transilienceai/denali

Denali

Denali 是一个独立、开源的 AI 安全平台，提供基于证据的资产清单、安全态势、攻击路径和运行时上下文。它将观察到的事实、推断的关系、安全结论和覆盖范围限制分离开来，以便评估者既能了解 Denali 所知信息，也能了解其无法验证的内容。优先级排序的产品方向和发布门控记录在智能体安全路线图中。 该仓库包含一个可运行的本地产品：一个基于 PostgreSQL 的 API、一个独立的 Web 应用程序、确定性问题和检测引擎、供应商接入、一方收集器以及有界导入器。它并非 CSPM 的扩展。Prowler 通过 OCSF 作为外部发现源受到支持。

当前状态

本 README 中的状态术语是刻意独立的：

• 已发布 意味着该功能已在 main 分支上实现，并由仓库测试和/或生产级 Web 或容器构建覆盖。
• 本地接受 意味着类似客户的工作流程也已在来自本地 Denali 部署的实时供应商资源上完成。
• 待上线接受 意味着实现和本地验证已存在，但文档记录的人工、浏览器或供应商端到端测试尚未完成。
• 计划中 意味着该功能尚未在此仓库中实现。

这些连接状态描述了接入和访问验证。它们并不表示供应商收集已运行，或存在清单、发现或安全判断。

已实现内容

Denali 在 Web 应用程序和 API 中呈现以下产品界面：

• 针对智能体、应用程序、模型、MCP 服务器和工具、护栏、框架、流水线、数据存储、工作负载、仓库、身份和软件组件的 AI 清单及基于证据的关系。
• 原子配置和导入的发现、扫描器无关的漏洞以及仅从充分独立证据组合而成的确定性问题。
• 依赖 GitHub 的、不可变修订版的源收集和代码到云视图，这些视图要求精确的部署标识符，保留未匹配和模糊的候选项，并将制品身份与未经验证的源修订版声明分开。
• 供应商无关的运行时活动，加上确定性的、证据关联的运行时检测、有序的 AWS AgentCore 和 Azure Foundry 会话调查，以及需要批准门控的手动响应请求。
• 保持完整、部分、失败、不支持和未知状态可见的源覆盖范围。
• 具有直接深度链接和浏览器前进/后退导航的稳定应用程序路由。
• 用于一个小型、可重现的双应用演示的清单约束黄金路径仪表板；参见运维人员和演示者指南。
• 用于 AWS、Azure、Google Cloud 和 GitHub 的连接生命周期和访问验证，包括显式范围选择和删除前禁用保护措施。

已实现的收集和导入路径包括：

供应商验证和收集仍然是独立的边界。一个健康的连接并不声称收集已运行。GitHub 验证不读取源代码 blob；一个显式的收集操作会单独将每个选定的仓库解析为一个不可变的修订版，应用硬性的树/文件/字节限制，分析临时快照，并丢弃其令牌和源文件。

证据边界

Denali 的实现遵循一些不可协商的规则：

• 连接健康仅证明在记录的时间，为记录的身份和范围，声明的只读入口点是可调用的。
• 收集覆盖范围与连接健康是分开的。失败或部分收集无法撤回先前观察到的清单或通过缺失来解决问题。
• 发现和运行时事件不会制造清单资产或图边。身份和关联需要精确的、独立观察到的标识符。
• 清单不是发现；发现不是问题；活动不是检测；这些都不是自动的风险判断或已确认的事件。
• 不支持、未选择、不可用和未知的范围保持可见，而不是变为空结果或安全结果。
• 当前的收集器保留有界的元数据和证据。客户云凭据和瞬时供应商访问令牌不会写入证据或连接记录；原始的一次性设置能力在使用后不会保留。原始提示或响应、机密值以及任意扫描器负载也会被排除在外。
• 演示记录被清晰地标记为固定装置证据。规范模型比 OCSF 更丰富，因为它必须保留持久的资产身份和关系。OCSF 仍然是发现和活动的交换边界，而不是发明的 Denali 图身份的来源。

本地评估 Denali

Docker 是通往产品的最短路径：

docker compose up -d --build
docker compose exec api denali-demo-seed

在 打开 Web 应用程序。API 位于 ，交互式文档位于 。PostgreSQL 暴露在 127.0.0.1:55450。 seed 命令创建清晰标记的固定装置清单、发现、漏洞、问题、运行时活动和检测，以便评估者无需供应商凭据即可检查证据和覆盖范围的用户体验。 一个有用的第一步是：

1. 检查 清单 并打开资源的断言和关系。
2. 比较 发现、漏洞 和 问题，以查看原子事实与组合攻击路径保持分离。
3. 比较 运行时活动 和 运行时检测。
4. 检查 源 以了解明确的覆盖状态。
5. 打开 连接 以检查已发布的接入流程。

依赖外部操作者身份或制品发布者的操作在配置前仍不可用。本地 Compose 运行时使用一个已配置的租户，并且没有最终用户认证或授权层。这是一个评估和开发堆栈，而非生产部署方案。数据持久化在 denali-postgres Docker 卷中。

对于 Clerk Organizations、Vercel、Modal 和 Neon 的试点部署，请从有序发布检查清单开始，然后使用托管多租户试点手册。托管模式将每个活动的 Clerk 组织映射到一个稳定的 Denali 租户 UUID，强制仅管理员可进行变更，并通过持久的 Modal 作业运行供应商验证。规范的服务边界、密钥所有权、租户隔离规则和持久工作标准记录在 ADR 0028 中。

运行收集器和导入器

对于 CLI 工作，安装所需的供应商 extras 并将命令指向本地数据库：

python3 -m venv .venv
source .venv/bin/activate
python -m pip install -e '.[api,aws,azure,gcp,github,dev]'
export DENALI_DSN=postgresql://denali:[email protected]:55450/denali

已安装的入口点包括 denali-repo-scan、denali-mcp-observe、denali-agentcore-scan、denali-aws-scan、denali-aws-stack-scan、denali-aws-stack-posture、denali-repository-posture、denali-code-to-cloud、denali-kubernetes-import、denali-ocsf-import、denali-syft-import、denali-grype-import、denali-activity-import、denali-aws-runtime、denali-gcp-vertex-runtime、denali-gcp-deployments-scan 和 denali-entra-scan。 使用每个命令的 --help 输出查看其确切范围和输入。

供应商接入

自助接入需要操作者拥有的集成身份，对于 AWS、Azure 和 GCP 设置制品，还需要一个私有的短期发布者。客户仅授予文档记录的读取范围，并保留对供应商侧 IAM 或 App 安装状态的控制。Denali 不接受客户的访问密钥、服务账户 JSON 密钥、个人访问令牌或云 CLI 会话。 已接受的合约、操作要求、验证平面、生命周期行为和证据限制在此文档中记录：

• ADR 0018 — AWS 角色接入
• ADR 0019 — Azure 多租户应用程序和选定订阅
• ADR 0020 — GCP 无密钥主体和选定项目
• ADR 0021 — GitHub App 和精确仓库边界
• ADR 0022 — GitHub 不可变源收集
• ADR 0029 — Microsoft Entra 管理员同意接入
• ADR 0033 — Google Workspace 全域委派
• ADR 0034 — Azure Repos 精确仓库接入
• GitHub App 注册和操作者配置

最新的接受记录是 AWS、Azure、GCP 和 GitHub 检查点。

架构指南

从产品和证据边界开始，然后仅遵循正在评估的部分：

• 代码库和系统地图 用于仓库布局、端到端数据流、本地和托管拓扑、持久化、前端、连接器、评估引擎、安全边界、测试和安全变更方案
• 独立产品 和 OCSF 边界
• 托管多租户运行时 用于 Vercel、Clerk、Modal 和 Neon 部署、租户授权、密钥和持久作业
• 承载证据的问题
• SBOM 优先的漏洞模型、制品关联 和 包出现身份
• 证据驱动的代码到云、工作负载身份 和 运行时检测