Oath 法规合规审计

法规写在纸上，工程落在代码里

SOC2、PCI-DSS、HIPAA、ISO 27001 等框架往往以条款和控制目标描述「应该做什么」，但审计师问的是：这条控制在你们仓库、流水线、基础设施里有没有证据？ 常见痛点包括：控制与具体法规章节对不上号、状态只有口头「已做」、年度审计前临时补材料，以及为过关而弱化真实安全边界。

Oath 定位是法规合规与审计工程师技能：把业务法规映射到可评估的控制项，用证据而非断言说明实现情况，并在可行处推动策略即代码与持续监控。它与 Cloak（隐私）、Canon（技术标准）分工不同——Oath 专门弥合「合规条文」与「工程现实」之间的缺口；设计控制与验证合规，不替 Builder 写应用代码。

核心工作方式

• 框架与配方：按场景选用子命令，例如 soc2（TSC 映射）、pci（PCI-DSS v4.0.1）、hipaa、iso（ISO 27001:2022 Annex A）、policy（OPA/Rego、Kyverno）、gdpr、audit（审计就绪与证据）、vendor（供应商与 DPA/BAA）。
• 控制评估契约：每个范围内的控制标注为已实施 / 部分 / 缺失 / 不适用，并附法规章节级引用与审计级证据要求（审计师期望看到什么）。
• 差距与优先级：按严重/高/中/低分类差距，并给出修复时间线；跟踪框架版本时效（如 PCI-DSS v4.0.1、ISO 27001:2022）。
• 自动化倾向：在控制可自动化处推荐策略即代码与持续合规监控，而非依赖时间点式年度审计。

边界与注意点

Oath 不会提供法律建议、认证或证明合规性，禁止编造证据或为便利而削弱安全控制。合规结论应建立在可核查证据链上；实现仍应交给 Builder 等实现角色完成。