「SOC 2準拠じゃない」— プルリクなしで監査を通したAmpの方法
"That's not SOC 2 compliant"
Ampはプルリクエストを使わずにmainブランチへ直接プッシュする開発スタイルを採用している。SOC 2監査では「リスクを考えよ」という原則に基づき、承認・テスト・記録のプロセスを独自に設計。署名付きコミット、自動CI、監査証跡を整備し、監査を通過した。小規模なチームだから可能なこの手法は、大企業にはそのまま適用できないが、リスクに応じたプロセス設計の重要性を示している。
SOC 2はプルリクエストを要求していない。要求しているのは、あなたが自社のリスクについて考えることだ。
HNでの議論
44- aleda145
この姿勢は新鮮だ。私の経験では、変更管理は、リリースが失敗したときに最初に持ち出されるものだ。
大企業で働いたことがあるが、そこには「変更諮問委員会（CAB）」があり、リンターのメジャーバージョンを上げるだけでも説得が必要だった。その結果、開発速度は亀の歩みになった。変更は大きくせざるを得なかった。小さすぎるとCABに承認されないからだ。遅いだけで無茶苦茶だった。
今の職場では、すべてのPRの説明に「私はコンプライアンスを順守していることを確認します」と大声で宣言しなければならない。なぜそうするのか誰も知らないと思うが、官僚たちは満足している。肩をすくめるしかない。
- abofh
ポリシーを持つことが求められている。そのポリシーは壁に向かってバナナを投げるというものでも構わないが、文書化され、それに従っていれば、ポリシーに準拠していることになる。
- 6ty6thhDJEHDE
これはAmp Codeには簡単だが、異なるタイプのビジネスを展開している他の人々にとってはそれほど簡単ではない。
私は、数億ドル相当の数百万件の顧客取引を行うビジネスで働き始めたが、彼らのプロセス全体は完全に「YOLOプレイグラウンド」だった。その結果、彼らは金銭、人材（すべてが常に壊れるとストレスが高い）、そして最も重要なことに顧客の信頼を失った。
ある程度の正気を取り戻したものは何か？成熟したビジネスのための基本だ：デプロイのレビューと承認、本番アクセス権の削除、コードレビュー、QAの参加。リリースノート。これらすべてが監査で出てくる。SOC1では、顧客が保証を求めるからだ。SOC2では、見込み客に、私たちが真剣で成熟しており、彼らのビジネスを得るに値することを示す必要があるからだ。
これを単なる演劇だと思わないでほしい。ルールを曲げて最低限のチェックマークを得て逃げ切れるなら、それはそれで結構、大いに結構だ。
しかし、あなたが重要なシステム、個人情報、顧客データ、お金などを扱うビジネスを運営しているなら、適切な変更管理ポリシーを厳格に導入することは、実際にあなたの成熟に役立つかもしれない。
その成熟は、顧客を獲得することにもつながる。なぜなら、あなたにビジネスを任せようとするほとんどの顧客は、あなたがどのように船を操縦しているかについて何らかの期待を持っているからだ。
私は自分の会社がAmpのように「単純」であればいいのにと思う。軽蔑の意味はない。彼らのやっていることは好きだ。しかし、それは、最小限のプロセスで重大なトラブルに巻き込まれるような種類のビジネスには見えない。
- jpollock
私は、一部のシステムで二要素認証を使っていない高信頼環境にいた。彼らは横領で25万ドルを失った。
高信頼は、誰かがそれを悪用するまで高信頼であり、悪用（横領、詐欺、政治的発言など）に遭遇する可能性は、総作業時間が増えるにつれて100に近づく。
- fissionworx
SOC2コンプライアンスに関して、無料の証跡収集ツールを紹介します。このプロジェクトはオープンソースです：https://github.com/nurlanyerasyl-jpg/fission-accountant
fissionworx.comから直接ダウンロードすることもできます。
謝意を示したい場合は、近い将来プロライセンスを購入できます。プロは一回限り50米ドルで、DrataやVantaの年間1万ドルとは異なります。また、オープンソース版の上に重要な機能を追加します。
注意してほしいのは、このツールはスタートアップ向けのSOC2コンプライアンスを容易にすることを目的としており、会計士の代わりにはならないということです。
問題が発生した場合は、メールで連絡するか、gitで解決策を提案してください。