我们允许AI审查低风险PR，同时不违反SOC 2控制

在过去一年中，Mirage Security将代码变更吞吐量提高了146%（按人头调整）。这一突破性增长伴随着架构、开发流程和发布工具的全面革新。然而，一个瓶颈依然存在：人工审查。

作为SOC 2 CC8.1合规的一部分，公司需要可审计的变更管理流程。变更必须经过授权、测试、批准并以受控方式部署。传统上，这意味着每项变更都需要人工审查，以确保无人能单方面将高风险变更推送到生产环境。

随着吞吐量接近翻倍，审批队列成为瓶颈。工程师需要切换上下文、审查并点击批准按钮，导致拉取请求（PR）积压。团队开始思考：是否存在一种既能保持合规、又不拖慢速度、且让人放心的更好方法？

在与审计方Richey May协作后，团队制定了新的策略和技术方案：

• 定义代码库中的高风险和低风险区域。
• 低风险变更由AI代码审查员审查，无阻塞即可合并。
• 高风险变更仍需非作者的人工审查员批准。
• 所有AI批准的合并每周由人工进行全面（非抽样）回顾，作为兜底机制，并将发现反馈到工具迭代中。
• 所有流程编码在CI/CD脚本中，确保可审计且减少人为错误。

风险分类的工作原理

核心思想：并非所有代码变更风险相同。仪表板标签的文本修改与认证中间件或网络基础设施的修改风险截然不同。

团队使用dorny/paths-filter操作在PR打开时和演进过程中进行分类。如果变更文件触及高风险路径列表中的任何一项，整个PR被标记为高风险，需要人工批准。其他情况为低风险。

高风险路径示例包括：基础设施代码（*.tf）、CI/CD流水线、访问控制、容器定义、环境配置、认证令牌、API合约、数据库迁移、请求中间件、租户边界、加密服务、身份服务、依赖文件等。

分类标准脚本和工作流本身也被归为高风险，修改它们需要人工批准。

SDLC门控

分类后，一个名为sdlc-gate的CI工作流在合并前强制执行审批策略。逻辑如下：

• 对于高风险PR：要求非作者的人工审查员批准（通过分支保护强制执行），标记human-review标签，移除之前的ai-approved标签。
• 对于低风险PR：要求至少一个批准（人工或AI）。如果AI批准，标记ai-approved标签。标签用于创建审计跟踪，供每周回顾使用。

AI代码审查

团队使用Claude Code Action（运行Claude Opus）作为AI审查员。AI读取差异，留下内联评论，并发布带有推荐（✅批准或🚫请求变更）的摘要评论。随后一个步骤读取摘要，由专门的审查机器人提交正式的GitHub审查。这对于SOC 2非常重要：批准必须是正式的GitHub审查事件，而不仅仅是评论。如果AI的推荐不明确（例如“有条件的批准”），系统默认请求变更。宁可要求人工复查干净的PR，也不让有问题的PR通过。

每周回顾

这是验证所有其他控制的兜底机制。每周五，一个定时GitHub Action查询所有在过去一周内合并且带有ai-approved标签的PR，生成一个列出所有PR的GitHub问题。人工审查员逐一检查，确认是否有变更本应被分类为高风险，记录任何异常，并通过关闭问题来签收。审查窗口锚定到上一个回顾问题的创建时间戳，确保无空白期。每个生成的问题都包含生成它的脚本的精确提交链接，确保可追溯性。

回顾问题示例包括：回顾周期、AI批准的合并总数、查询方法、完整列表（含PR链接、标题、作者、合并时间），以及审查步骤清单。

GitHub Actions工作流

三个工作流协同工作：

• claude-pr-review.yml：在每个PR上运行Claude Code Action，然后通过机器人提交正式审查。
• sdlc-gate.yml：在每个PR事件（打开、同步、审查提交）上运行，分类文件并执行审批策略。
• sdlc-weekly-review.yml：定时每周五运行，生成回顾问题。

所有工作流、分类标准、强制执行脚本以及限制谁可以修改它们的CODEOWNERS文件，都受代码所有权规则保护，需要CTO批准。

变更管理策略

更新后的策略文档定义了变更风险分类：高风险变更涉及安全控制、处理完整性、可用性或机密性，必须由非作者的人工审查员批准。低风险变更为不影响上述方面的变更，可由AI代码审查系统审查和批准，但需满足条件：分类标准正式记录、版本控制、修改本身视为高风险；修改访问受限制；每周进行全面回顾。

能否信任流程？

AI审查代码听起来令人担忧，但人类也并非完美。大量低风险变更（如文案、移动组件、测试、小型重构）的人工审查会导致审查疲劳，使人类更容易遗漏关键问题。现有证据表明，AI模型在发现安全漏洞方面至少与大多数工程师相当，甚至更优。对于低风险变更，AI审查是合理的门控。对于影响安全态势和供应链的变更（基础设施、认证、租户边界、加密、CI/CD、依赖、关键工作流），仍需人工参与。

流程并非盲目信任AI，而是在最合理的地方使用AI，在最重要的地方保留人类。也许有一天，人类将不被允许在未经AI审查的情况下编写代码。