这不是SOC 2合规的

# “这不符合SOC 2标准” 来源：https://ampcode.com/notes/thats-not-soc-2-compliant Will Dollman // 2026年8月13日 我们一直在分享更多关于工作方式的内容：用Amp构建Amp、使用orbs (https://ampcode.com/manual/orbs)、砍掉功能、不用拉取请求。最常见的反应不是关于AI工作流程或当下流行的某种环形图工程方法，而是这个： > 等等，你们不用拉取请求？直接推送到主分支？这怎么行？这不符合SOC 2标准。 但事实是符合的。 从第一次提交开始，跳过拉取请求就是深思熟虑的选择。这是我们构建方式的重要组成部分（https://ampcode.com/notes/pave-the-road），也是我们能够持续交付的原因。 因此，当我们开始推进SOC 2认证时，我们直接向审计师提出了这个问题：“拉取要求是必须的……对吧？” ## 控制措施 SOC 2 并不要求必须有拉取请求。它要求你*思考自己的风险*。 这才是我们得出的真正答案。审计师和SOC 2本身比你想象的更灵活。我们的审计师没有要求我们使用拉取请求；他们询问我们的变更流程是什么，并与我们共同制定了一套适合该流程的控制措施。 信托服务准则从未提及`git`或拉取请求。它们要求的是变更经过授权、测试、批准和记录——而拉取请求只是实现这一点的其中一种方式。 以下是我们最终确定的控制措施： - **限制推送访问权限。**对`main`分支的访问遵循业务职能：Amp的每位工程师都能推送，而Amp的大部分成员都是工程师。但拥有访问权限的人数比例并不重要，重要的是能清楚解释谁拥有权限以及为什么。 - **签名提交。**推送已要求身份验证，但提交者信息只是元数据。GitHub在`main`分支上强制验证签名，这使得每次提交的作者都可验证。 - **自动化持续集成。**每次变更都会经过完整的验证流水线：测试、基础设施检查、安全检查。有问题的变更会阻止进入`main`分支。 - **与拉取请求一样完善的审计跟踪。**提交链接到产生它们的Amp讨论线程，因此记录不仅包含差异，还包括导致变更的整个过程。由此，CI/CD记录了从提交到部署的完整路径。 这些都不算新奇。但这也不是简单删减了一个步骤的标准流程。这是一个精心设计的系统，它能为审计师提供与拉取请求工作流相同的东西。 而且不，代码审查并不在列表中。准则并未规定必须有另一个人盯着差异看。 ## 这能扩展吗？ 我们只有20人，大部分是工程师，每个人都熟悉代码。规模小且高度信任是我们的优势，我们不会为了不需要的流程而放弃它。当编码速度很快时，缓慢的流程反而成了真正的瓶颈。但我们不会假装一家2000人的公司应该允许每个人推送代码到主分支。 真正可扩展的是*思考自己的风险*，因为风险在公司内部也不是均匀分布的。Amp是面向客户的生产软件，我们就是这样交付它的。与此同时，大公司里很多代码的风险比这低得多，但每一次变更都经过相同流程——这个流程是针对公司运行的最危险系统校准的。 你无需彻底改造整个公司来解决这个问题。选择一个系统，然后问：*“我们的拉取请求实际上是在管理这里的哪些风险？”*接着思考还有哪些方式可以管理这些风险。 答案不必是拉取请求。