用途
soc2-audit 用于对一个完整仓库或应用执行全面、框架无关的 SOC 2 就绪度审计。它通过顺序化、模块化的规则逐步收集证据，最终产出带有量化评分的就绪度报告。整个过程是只读的：不会修改被审计的仓库，也不会把密钥值写入任何产物或报告，遇到密钥值会脱敏。
主要能力
- 运行时项目检测：在分析前自动检测项目类型与技术栈，包括 Node/TypeScript（package.json）、Flutter/Dart（pubspec.yaml）、Go（go.mod）、Rust（Cargo.toml）、Python（pyproject.toml 或 requirements.txt）、Java/Kotlin（build.gradle/pom.xml）、Ruby（Gemfile）、PHP（composer.json）、.NET（.sln/.csproj）、Terraform/IaC（*.tf），以及无法匹配时的通用项目回退方案。支持多技术 monorepo，仓库级控制（治理、CI/CD、IaC）在仓库根目录评估一次。
- 控制族分类体系：以十一个控制族（A–K）为组织骨架，每一族映射到 AICPA 信托服务准则（TSC 2017，2022 修订）：
- A. 治理与项目（CC1.x、CC3.x、CC5.x）
- B. 人力资源安全（CC1.4）
- C. 身份与访问管理（CC6.1-CC6.3、CC6.6）
- D. 数据保护与机密性（CC6.1、CC6.7、C1.1-C1.2）
- E. 安全开发与变更管理（CC7.1、CC8.1）
- F. 基础设施与网络安全（CC6.6、CC7.2）
- G. 漏洞管理与保证（CC7.1）
- H. 事件管理、BCP/DR（CC7.3-CC7.5、CC9.1）
- I. 供应商/第三方管理（CC9.2）
- J. AI 治理（CC1.x、CC4.x）
- K. 证据产物/信任中心（以目标形式报告，不计分）
- 状态与责任通道记录：为每个控制记录状态（met 已满足、partial 部分满足、gap 缺口、organizational 组织级）与责任通道（PLATFORM-AUDITABLE 平台可审计、ORGANIZATIONAL 组织级、CLIENT/CUEC 客户补充控制）。每个状态都附带具体证据（文件路径、配置键、工作流或 IaC 资源）。
- 量化就绪度评分：按控制族 0–100 分加权评分，计算加权总分并映射到就绪度等级。评分侧重平台可审计控制；组织级控制仅依据产物是否存在给予有限部分分；CUEC 单独列出且不计入评分。
- 证据驱动报告：输出包含按族评分卡、映射到准则引用与责任通道的缺口表、CUEC 列表、需编撰的交付物、按优先级排列的整改路线图、总分与等级的报告。
使用方式
该技能以顺序步骤执行，共包含 9 个证据/评分规则、1 个报告生成器和 1 个格式校验器：
- 项目与工具链检测：检测项目类型、技术栈、包管理器、CI/CD 系统、IaC 及相关合规工具链，建立证据面。（必选）
- 治理、人员与 AI 项目（族 A、B、J）：检查仓库中是否存在策略产物，如安全策略集、行为准则、意识培训材料、NDA/保密引用、AI 使用政策。
- 身份与访问管理（族 C）：收集认证、授权/RBAC、特权访问审批、访问审查/撤销、密码标准、MFA、SSO/OIDC、会话管理等证据，密钥值仅报告位置与状态。
- 数据保护与机密性（族 D）：收集传输中 TLS、静态加密（KMS/AES-256）、租户/数据隔离、数据最小化与分类、保留与安全销毁、驻地披露、DLP、加密备份及恢复测试等证据。
- 安全开发与变更管理（族 E）：收集 SDLC 文档、开发/测试/生产分离、PR 审查与分支保护、经测试与审批的变更、紧急变更路径、依赖/SAST/漏洞扫描、迁移纪律、补丁 SLA 等证据。
- 基础设施与网络安全（族 F）：从 IaC 与配置中收集网络分段/私有子网、WAF/IDS、控制平面审计日志（如 CloudTrail）、流日志与边缘访问日志、日志保留超过 30 天、监控与安全事件告警、托管密钥存储与轮换等证据。
- 漏洞、保证、供应商与交付物（族 G、I、K）：收集生产漏洞扫描、外部渗透测试证明、证据就绪情况、供应商风险审查、分包商流转让、外包开发披露，并盘点信任中心交付物（SOC 2 报告、SIG/CAIQ、渗透测试证明、子处理者列表、状态/信任页面）。
- 事件管理、BCP 与 DR（族 H）：收集事件响应计划与事后复盘、违规通知 SLA、业务连续性与灾难恢复计划年度测试、RPO/RTO 目标、恢复演练等证据。
- 就绪度评分：使用加性证据评分标准计算每族 0–100 分与加权总分，映射到就绪度等级。评分必须在报告撰写前完成。
- 生成 SOC 2 就绪度报告：综合所有证据与评分，产出 19 个章节的报告，包括评分卡、执行摘要、按分数升序排列的 10 个评分详情章节、信托服务准则缺口与覆盖表、CUEC、证据产物与信任中心交付物、整改路线图、项目检测结果、证据索引附录与报告元数据。
- 校验与导出报告：按照结构与 Markdown 格式规则校验报告（恰好 19 个编号章节、评分卡包含 10 条族评分行与 Overall 与 Band、第 18 与 19 章节之间的评分方法说明块、按分数升序排列、缺口表包含必需列、CUEC 与交付物章节存在、无密钥值出现、Markdown 语法正确），并保存到
./reports/<YYYY-MM-DD>-<project>-soc2-audit.md。
评分权重：族 A 8%、B 4%、C 18%、D 16%、E 16%、F 14%、G 8%、H 8%、I 4%、J 4%。
适用场景
- 组织在正式 SOC 2 审计前进行内部就绪度评估
- 需要跨代码、基础设施、CI/CD 与文档全面盘点潜在控制证据
- 希望区分平台可审计控制与组织级政策/流程工作，明确整改优先级
- 需要将 AICPA TSC 常见准则（CC1-CC9）及可选的可用性（A1）、机密性（C1）、处理完整性（PI1）、隐私（P1-P8）映射到可观察证据
限制
- 审计不修改被审计仓库，只将审计产物与报告写入
reports/目录。 - 组织级控制仅检查策略产物是否存在于仓库中（如 SECURITY.md、docs/compliance/、docs/policies/），并报告“策略产物是否存在”，不评估运行时代码。
- 客户/CUEC 控制被列为平台范围之外，不计入平台评分。
- 无法由证据证明的控制一律标记为 gap，不进行假设或推断。
- 不得虚构公司、客户、租户或工单名称。
- 关于收费、价格、平台支持范围等具体信息暂未提供。