一家做AI编程工具的公司告诉你:他们的工程师可以直接把代码推到main分支,不开Pull Request。这套流程还顺利通过了SOC 2审计的沟通。
这话听起来像是在给"图省事"找借口。但拆开看,反而暴露了一个更值得琢磨的问题:SOC 2到底在管什么风险,又在多大程度上被行业理解成了"必须用PR"这种迷信。
发生了什么:Amp用什么代替PR
Amp是Sourcegraph旗下的AI编程产品。他们在博客里回应了一个常被问到的质疑:"你们不用PR?直接推main?那怎么可能符合SOC 2?"
答案是:可以。团队从第一次commit起就没用PR,这是他们能持续交付的核心方式之一。启动SOC 2审计流程时,他们直接把这个问题带给了审计方。
得到的回答有点反直觉:SOC 2的Trust Services Criteria里根本没提到git,也没提到pull request。它要求的是变更被授权、被测试、被批准、被记录,PR只是实现这一点的一种方式,不是唯一方式。
Amp和审计方一起,设计了一组替代控制:
| 控制目标 | 传统PR模式 | Amp的替代方案 |
|---|---|---|
| 谁能改main | 依赖PR审批 | 按业务角色限制推送权限 |
| 作者身份可核验 | 靠登录账号 | GitHub强制verified signature |
| 变更质量把关 | 人工review | 测试/安全检查跑不过不能进main |
| 事后可追溯 | 一条PR记录 | commit关联Amp thread,再串到CI/CD部署记录 |
拿掉的只是"必须有第二个人盯着diff审查"这一条。授权、测试、记录这些控制目标全部保留,只是换了实现方式。
需要说清楚分寸:原文说的是团队"开始朝SOC 2努力"、和审计方一起设计控制,不是已经拿到认证。这两件事不能混为一谈。
SOC 2管的是风险,不是Git流程
SOC 2从设计上就不是一份"你必须用哪种工具"的清单。它更像一份"你得能证明自己管住了风险"的作文题。审计方关心的是控制目标有没有达成,不是达成手段是不是行业默认动作。
《礼记》讲"礼者,理也"。审计要的也是"理"——一套讲得通、能验证的逻辑,不是照抄一套仪式动作。很多公司把SOC 2和"标准流程"划了等号,把合规当成抄模板,而不是回头审视自己的实际风险点。
有几处Amp原文没展开,这里也得说清楚:公开信息没提到他们申请的是Type I(某一时点的设计有效性)还是Type II(一段时间内的运行有效性),两者对证据要求差别不小。职责分离怎么落地、紧急变更怎么处理、出问题怎么回滚,原文也没细说——这些恰恰是审计方通常会追问的地方,目前还看不清。
谁能学这套,谁不能
Amp能这么干,前提写得很清楚:20人团队,大多数是工程师,每个人都离代码很近。这是高信任、高密度的组织形态,不是普适方案。他们自己也没打算把这套推广给2000人的公司——原文明确说了不会。
| 维度 | Amp·20人团队 | 假设:2000人组织 |
|---|---|---|
| 团队构成 | 高信任,工程师主导 | 角色分散,信息差大 |
| 风险敞口 | 集中,易解释 | 系统风险不均匀 |
| 作者与审查者动机 | 高度一致 | 差异明显 |
| 能否拆PR | 可以 | 不建议照搬 |
小团队的CTO或工程负责人可以照这个思路自查:权限收得住吗、签名开了吗、CI能不能拦住问题、出了事能不能顺着链路查回去。四条都能打勾,PR未必是唯一选项。
大公司的安全和合规团队则该反过来想:不是要不要取消PR,而是能不能按系统风险分级校准审查强度——高风险系统继续多道审查,低风险的内部工具没必要套用最吓人系统的那套标准。
我的判断
这份说明真正有价值的地方,不是教人抄近道。它把"合规"从一份清单,还原成一次风险判断。
流程不是护身符。能不能拆,取决于风险,不取决于习惯。小团队省的是审查冗余;大公司如果照抄,省掉的可能是真实的风险敞口。
Type I还是Type II、职责分离怎么落地、出问题怎么回滚——这些没交代的细节,才是决定这套方案能不能复制的关键。Amp给出的是一个思路,不是一份可以直接套用的清单。真正该问的一句话是:我们的PR到底在管什么风险,有没有别的办法管住它。小团队和大公司都能问,只是答案不一样。