Amp объяснила, как проходит SOC 2 без пул-реквестов

Amp, компания, которая с самого первого коммита отказалась от пул-реквестов и позволяет инженерам пушить прямо в main. Когда команда начала готовиться к сертификации SOC 2, она ожидала, что аудиторы потребуют вернуть пул-реквесты, и прямо спросила их об этом. Ответ аудиторов, как его передаёт автор поста Уилл Долман: SOC 2 не требует пул-реквестов, он требует, чтобы компания думала о своих рисках. Критерии Trust Services Criteria вообще не упоминают git или пул-реквесты, они требуют, чтобы изменения были авторизованы, протестированы, одобрены и задокументированы, а пул-реквест, лишь один из способов это обеспечить.

Вместе с аудиторами Amp выработала четыре контроля, заменяющих классический процесс ревью через пул-реквесты. Первый, ограниченный доступ на пуш: право пушить в main привязано к должностным обязанностям, и у Amp это большинство сотрудников, поскольку почти вся компания, инженеры; важнее не процент людей с доступом, а то, что компания может точно объяснить, у кого он есть и почему. Второй, подписанные коммиты: GitHub требует верифицированной подписи для коммитов в main, что делает автора каждого коммита проверяемым, а не просто именем в метаданных. Третий, автоматизированный CI: каждое изменение проходит полный конвейер проверок, тесты, проверки инфраструктуры, проверки безопасности, и плохие изменения блокируются на пути в main. Четвёртый, аудиторский след не хуже, чем у пул-реквеста: коммиты связаны с тредами в Amp, из которых они появились, так что записана не только сама правка, но и всё, что к ней привело, а CI/CD фиксирует путь от коммита до деплоя. Код-ревью в этот список не входит: критерии SOC 2 не требуют, чтобы второй человек буквально смотрел на диф.

Автор подчёркивает, что это работает благодаря масштабу и уровню доверия внутри команды: в Amp 20 человек, почти все, инженеры, и все близки к коду. Такой подход компания сознательно не собирается распространять на организацию из 2000 человек, там это не масштабируется. Общий принцип, который, по мнению автора, масштабируется, это не конкретный набор контролей, а сама привычка думать о рисках: риск неравномерен даже внутри одной компании, и Amp, выпускающая клиентское production-ПО, выбрала процесс под свой профиль риска, а не копирует чужой стандарт «на всякий случай».

Ключевые факты

Amp с первого коммита пушит изменения прямо в main, без пул-реквестов и код-ревью, и готовясь к SOC 2 ожидала, что аудиторы это не одобрят
Аудиторы ответили, что SOC 2 не требует пул-реквестов, только осознанного управления рисками; Trust Services Criteria вообще не упоминают git
Вместо ревью через пул-реквесты Amp с аудиторами выработала четыре контроля: ограниченный доступ на пуш по должностным обязанностям, обязательные подписанные коммиты, автоматизированный CI с тестами и проверками безопасности, аудиторский след от коммита (через треды Amp) до деплоя
Код-ревью в список контролей не входит: критерии SOC 2 не требуют, чтобы второй человек смотрел на каждый диф
В Amp 20 человек, почти все, инженеры; сама компания подчёркивает, что не стала бы давать такой же доступ на пуш в гипотетической компании из 2000 человек

Почему это важно

Пост бьёт по распространённому мифу инженерной культуры: якобы SOC 2 намертво привязан к пул-реквестам и код-ревью как единственно правильному процессу. Amp на своём примере показывает, что сертификация проверяет не конкретный инструмент вроде GitHub PR, а способность компании объяснить и обосновать свои контроли управления изменениями, а значит, у команд с другим рабочим процессом, включая интенсивно использующих ИИ-агентов для написания кода, есть легальный путь к комплаенсу без копирования чужого шаблона.

Кому это важно

В первую очередь техническим руководителям и инженерным командам, которые быстро выпускают код (в том числе с помощью ИИ-инструментов) и рассматривают отказ от пул-реквестов, но опасаются, что это заблокирует прохождение SOC 2 или аналогичного аудита. Также полезно тем, кто уже проходит сертификацию и ищет прецедент, чтобы обсудить с собственными аудиторами альтернативный набор контролей.

Как это применить

Из поста можно вынести конкретный набор контролей взамен пул-реквестов: привязать доступ на пуш в основную ветку к должностным обязанностям и уметь объяснить, у кого он есть и почему; включить обязательную верификацию подписи коммитов на уровне GitHub; прогонять каждое изменение через автоматизированный CI с тестами, проверками инфраструктуры и безопасности, блокирующий плохие изменения; вести аудиторский след, связывающий каждый коммит с контекстом, из которого он появился, и с путём до деплоя. Ключевой шаг, который предлагает автор, не копировать процесс целиком, а выбрать одну систему и спросить, какие риски там реально закрывают пул-реквесты, и можно ли закрыть их иначе.

Можно ли доверять

Это собственный блог Amp, а не независимый отчёт аудитора: имя аудиторской фирмы или конкретного аудитора в тексте не названо, как и дата или срок получения самой сертификации SOC 2, сказано лишь, что компания шла к её получению. Автор поста, Уилл Долман, указан только по имени, без должности. Излагаемые контроли и их эффективность, это интерпретация и пересказ компании о собственном опыте, а не проверяемый внешний аудит.

Риски и подводные камни

Подход прямо описан автором как работающий благодаря маленькому размеру и высокому уровню доверия внутри команды из 20 человек, где почти все, инженеры, близкие к коду; сама Amp говорит, что не стала бы давать такой же доступ на пуш в компании из 2000 человек. Отказ от обязательного код-ревью снимает с процесса «второй пары глаз» на каждый диф, это осознанный компромисс, который подходит не любой команде и не любому профилю риска, и требует калибровки контролей под конкретную систему, а не бездумного копирования набора Amp.

«SOC 2 не требует пул-реквестов. Он требует, чтобы вы думали о своих рисках.»

— Уилл Долман, автор поста в блоге Amp, так компания передаёт ответ своих аудиторов