不写Pull Request，照样通过SOC 2审计
"That's not SoC 2 compliant"
当外界质疑我们直接推送到main分支不符合SOC 2合规要求时，我们直接询问了审计方。真相是：SOC 2从未强制要求Pull Request，它真正关注的是你是否思考并管理了风险。在Amp，我们放弃了传统的代码审查流程，转而采用受限推送权限、强制签名提交、全自动化CI流水线以及完整的审计追踪。这套量身定制的控制系统，既保留了小团队的高信任优势，又满足了审计标准。对于大公司而言，盲目套用统一流程往往效率低下，关键在于识别具体系统的风险，并找到最合适的管理方式，而非死守Pull Request这一种形式。
SOC 2并不要求你必须使用Pull Request，它要求的是你必须认真思考你的风险。
HN 评论区
44- aleda145
这种立场真是令人耳目一新。就我的经验而言，一旦发布出现事故，变更管理往往是第一个被强行加上的东西。
我在一家大型企业工作过，那里有个“变更咨询委员会（CAB）”，哪怕你只是想升级一下 linter 的主版本号，都得去说服他们。结果就是开发速度慢得像蜗牛。因为如果改动不够大，CAB 根本就不会批准。简直是一团缓慢的烂摊子。
在我现在的公司，每份 PR 的描述里都得大声嚷嚷一句“我确认合规”。我不确定到底为什么，但这能让那些官僚们开心。摊手。
- abofh
你被要求必须有一套政策。这套政策哪怕是“把香蕉往墙上扔”，只要它被记录下来并且你照此执行，你就符合政策要求了。
- jpollock
我曾经在一个高信任度的环境工作，那里有些东西甚至没有双重认证。结果他们被内部人侵吞了 25 万美元。
高信任度就是高信任度，直到有人利用它为止。随着员工总工时的增加，遭遇利用（如侵吞公款、欺诈、政治言论等）的概率会趋近于 100%。
- swiftcoder
> 他们要求的是变更必须经过授权、测试、批准并记录——而 Pull Request 只是实现这一点的其中一种方式。
我很不清楚在你的系统中如何确保“批准”这一环节？
授权和记录在版本控制系统里几乎是开箱即用的，CI 可以保证测试，但在没有任何变更审查证据的情况下，我们如何证明“批准”这一动作呢？
- 6ty6thhDJEHDE
这对 Amp Code 来说很容易，但对其他不同类型的企业来说就没那么简单了。
我曾在一家业务量巨大、涉及数亿美元客户交易的公司工作，他们整个流程完全就是个 YOLO（You Only Live Once，意为“有命玩一把”）游乐场。结果就是他们赔了钱、丢了人（如果系统老是出故障，压力会非常大），最重要的是：客户信心崩塌。
是什么让情况恢复了一些理智？成熟企业的基础：部署审查与批准、移除生产环境访问权限、代码审查、QA 介入、发布说明。所有这些都会出现在审计中。在 SOC1 里是因为客户需要保障，在 SOC2 里是因为我们需要向潜在客户展示我们是认真且成熟的，足以承接他们的业务。
请不要认为这只是作秀。如果你能靠把规则压到最低限度来混个勾号，那恭喜你，随你便。
但如果你经营的是涉及关键系统、个人身份信息（PII）、客户数据、资金等的业务，那么也许严格执行良好的变更管理政策真的能帮助你走向成熟。
这种成熟度也会帮你赢得客户。因为猜怎么着，大多数愿意把业务托付给你的客户，对你如何运营公司都有一定的期望。
我希望我的公司能像 Amp 一样“简单”。无意冒犯，我很欣赏他们做的事。但这看起来并不像是那种因为采用极简流程就会惹上大麻烦的业务类型。