安全审计

我们的 关于页面 表示我们的安全审计过程已有文档记录。以下是该文档：审计了什么、发现了什么、以及每个发现是如何关闭的。

范围

2026 年 2 月，Odysseus 接受了一次正式的内部多租户安全审计，覆盖了 268 个 Go 源文件和 383 个 TypeScript 文件，涵盖 14 个组件 — 控制平面、节点代理程序、仪表板以及每个触及租户边界的子系统。

发现的问题

来源：docs/core/07-security.md:11 以及 audit/EXECUTION_PLAN.md:4,6,15。

如何修复

全部 184 个发现通过一个单一的主执行计划关闭，该计划组织为 六个门控波次 — 从波次 0（紧急）到波次 5（验证）— 每个波次只有在其自身门控通过后才能解锁下一个波次。一个波次内的工作跨组件并行进行；跨波次的工作是顺序的，因此波次 3 的修复不能在波次 2 的门控关闭前开始。该计划明确指出，即使有空闲时间，也不能提前处理后续波次的发现：“不要提前阅读… 并开始处理属于未来波次的后期阶段项目”（audit/EXECUTION_PLAN.md:78）。

如何验证

九个专门的安全测试套件检验了修复后的状态，每个都以其防范的故障类别命名：

套件	文件
身份验证绕过	pkg/api/auth_bypass_test.go
合规验证	pkg/api/compliance_verification_test.go
容器隔离	pkg/api/container_isolation_test.go
跨租户隔离	pkg/api/cross_tenant_isolation_test.go
基础设施隔离	pkg/api/infrastructure_isolation_test.go
租户隔离（通用）	pkg/api/isolation_test.go
性能回退	pkg/api/performance_regression_test.go
角色提权	pkg/api/role_escalation_test.go
租户隔离（API范围）	pkg/api/tenant_isolation_test.go

可追溯的发现，而非仅计数

每个发现都携带一个 ID — CRIT-01、HIGH-04 等等，按组件界定范围 — 并且该 ID 再次作为注释出现在修复它的那一行，因此 “这已被修复” 的说法是可验证的，而非断言。例如：

• pkg/vault/approle.go:2 — // SECURITY FIX (CRIT-02): Per-tenant AppRole management replaces the shared…
• pkg/vault/approle.go:25 — // SECURITY FIX (HIGH-04): Namespace enables per-tenant Vault namespace isolation.
• pkg/api/container_ops.go:227,304,341,390,436 — 五个独立的调用点，每个都承载着 // SECURITY FIX (HIGH-02): Mandatory tenant ownership verification

执行计划在组件间交叉引用这些相同的 ID，当一个修复依赖于另一个时 — 例如 Consul CRIT-01 (remove legacy) -> Vault CRIT-03 (tenant paths) -> Vault CRIT-01 (API scoping) -> Agent CRIT-02 (tenant ownership)（audit/EXECUTION_PLAN.md:143-144）— 因此驱动波次排序的依赖链本身就是公共记录的一部分，而非要求您凭信接受的断言。

状态

已完成。所有184项发现均已跨六个波次完成修复；所有门禁均已关闭（audit/EXECUTION_PLAN.md:6）。我们描述的并非乐观的持续修复工作 — 工作已经完成，您正在阅读的是其最终记录。

关于实际控制日常运作的具体内容，请参见 安全。关于审计追踪本身如何证明事后未被篡改，请参见 合规。