それはSOC 2に準拠していません

私たちはAmpの構築方法について、Ampで構築する、オーブを使う、機能を廃止する、プルリクエストを使わないといったことを共有してきました。そして、最も一般的な反応は、AIワークフローや、その週の流行りのグラフエンジニアリングについてではありません。「待って、プルリクエストを使わないの？メインにプッシュするの？どうやって？それはSOC 2に準拠していないのでは？」というものです。しかし、実際には準拠しています。 プルリクエストをスキップすることは、最初のコミットからの意図的な選択でした。これは私たちが構築する方法と、継続的に出荷できる理由の大きな部分を占めています。そのため、SOC 2の取得に向けて作業を開始したとき、私たちは監査人に直接この質問をしました。「それにはPRが必要ですよね？」 コントロール SOC 2はプルリクエストを要求しません。それは、あなたがリスクを考慮することを要求します。それが私たちが持ち帰った本当の答えです。監査人、そしてSOC 2自体は、あなたが想定するよりも柔軟です。私たちの監査人はプルリクエストを求めていませんでした。彼らは、私たちの変更プロセスが何であるかを尋ね、それに適合する一連のコントロールを私たちと共に検討しました。 Trust Services Criteriaは、gitやプルリクエストについて一切言及していません。それらが要求するのは、変更が承認され、テストされ、承認され、記録されることです。そして、プルリクエストはそのための1つの方法にすぎません。 私たちが合意したコントロールは以下の通りです。 制限されたプッシュアクセス。 メインへのアクセスはビジネス機能に従います。Ampのすべてのエンジニアはプッシュできますし、Ampのほとんどはエンジニアです。しかし、アクセス権を持つ人の割合は、誰がそれを持っていて、なぜ持っているのかを正確に説明できることよりも重要ではありません。 署名付きコミット。 プッシュにはすでに認証が必要ですが、コミットの作者情報は単なるメタデータです。GitHubはメインへの検証済み署名を強制するため、すべてのコミットの作者が検証可能になります。 自動CI。 すべての変更は、テスト、インフラチェック、セキュリティチェックといった完全な検証パイプラインを実行します。悪い変更はメインをブロックします。 PRと同等の監査証跡。 コミットはそれらを生成したAmpのスレッドにリンクされているため、記録は単なる差分ではなく、それにつながるすべてのものです。そこから、CI/CDはコミットからデプロイまでのパスを記録します。 これらはどれも珍しいものではありません。しかし、それはステップが削除された標準プロセスでもありません。それは意図的に設計されたシステムであり、監査人にPRワークフローが提供するものと同じものを提供します。 そして、コードレビューはリストに含まれていません。基準は、2人目の人間が差分を凝視する必要があるとは述べていません。 これはスケールしますか？ 私たちは20人、ほとんどがエンジニアで、全員がコードに近いところにいます。小さく、高い信頼性を持つことが私たちの強みであり、必要のないプロセスにそれを譲るつもりはありません。コードを書くのが速い場合、遅いプロセスが実際に待っているものになります。しかし、2000人規模の会社が全員にメインへのプッシュを許可するとは pretend しません。 スケールするのは、リスクを考慮することです。なぜなら、リスクは会社内でも均一ではないからです。Ampは顧客 facing の本番ソフトウェアであり、私たちはこの方法で出荷しています。一方、大企業では、それよりもリスクの低いコードがたくさんありますが、すべての変更が同じプロセスを経由し、会社が実行する最も恐ろしいシステムに合わせて調整されています。そして、それを修正するために会社全体をオーバーホールする必要はありません。1つのシステムを選んで、「私たちのプルリクエストはここで実際にはどのようなリスクを管理していますか？」と問いかけてください。次に、他にどのように管理できるかを尋ねてください。答えはプルリクエストである必要はありません。