Чек-лист безопасности релиза перед выкладкой кода

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

Статья опирается на логику направления «Управление изменениями» из методики зрелости Группы Сбер (источник); это методика для крупных компаний, мы используем её как ориентир и пересказываем своими словами.

Что должно получиться

Уровень	Что это значит на практике
2. Гигиенический	Релиз кода проходит обязательную проверку безопасности перед выкладкой, а не полагается только на функциональное тестирование

Критерии сформулированы нами по мотивам методики, это ориентир, а не оценка соответствия.

☐ Секреты и конфигурация

☐ В коде и в файлах конфигурации, попадающих в репозиторий, нет паролей, токенов и ключей — это подтверждено статическим анализом (bandit или аналог для вашего языка), а не только на глаз.
☐ Значения для тестового окружения (тестовые ключи платёжного шлюза, тестовые учётные данные) не остались в конфигурации, которая идёт в продуктив.
☐ Переменные окружения продуктива заданы через хранилище секретов или защищённый механизм CI, а не скопированы вручную из чата или заметки.

☐ Права доступа

☐ Новый функционал не открывает доступ шире, чем задумано (например, новый эндпоинт API проверяет права, а не доступен любому авторизованному пользователю без проверки роли).
☐ Если релиз добавляет новую роль или право — для неё явно описано, кому она выдаётся и кто за это отвечает.
☐ Служебные и тестовые учётные записи, использованные при разработке, не остаются активными в продуктиве.

☐ Зависимые изменения

☐ Проверены зависимости, добавленные или обновлённые в этом релизе (pip-audit или аналог), находок с доступным исправлением нет.
☐ Образ, который будет развёрнут, просканирован на уязвимости (Trivy или аналог), критичные находки с исправлением закрыты или осознанно приняты.
☐ Изменения в базе данных (миграции) обратимы или для необратимых есть явный план и резервная копия перед применением.

☐ План отката

☐ Известно, как откатить именно этот релиз (предыдущая версия образа, обратная миграция, флаг отключения функции), а не абстрактное «откатим, если что».
☐ Откат проверялся хотя бы один раз на тестовом окружении для изменений, где откат нетривиален (необратимая миграция, изменение формата данных).
☐ Известно, кто принимает решение об откате в момент релиза и по какому сигналу.

☐ Журналирование и наблюдение

☐ Новый функционал пишет журнал значимых для безопасности действий (вход, изменение прав, отказ в доступе), если это предполагается архитектурой сервиса.
☐ В журнал и в текст ошибок, видимых пользователю, не попадают пароли, токены и персональные данные.
☐ Есть на что посмотреть сразу после выкладки: дашборд, журнал ошибок — не только «подождать жалоб от пользователей».

☐ После выкладки

☐ Первые минуты после выкладки кто-то целенаправленно наблюдает за ошибками и метриками, а не уходит сразу после нажатия кнопки.
☐ Временные флаги и тестовый код, добавленные для этого релиза, помечены для удаления со сроком, а не остаются навсегда «на всякий случай».

Как встроить в процесс, а не добавить бюрократию

Чек-лист работает, когда большая часть пунктов проверяется автоматически в конвейере сборки (статический анализ, проверка зависимостей, сканирование образа), а вручную остаются только пункты, которые нельзя формализовать (план отката, наблюдение после выкладки). Если весь чек-лист проверяется человеком вручную при каждом релизе, команда быстро начнёт пропускать пункты под давлением сроков — автоматизация защищает от этого лучше напоминания.

Диагностика

Симптом	Причина и что делать
Чек-лист проверяется формально, галочки ставят не глядя	Пункты не автоматизированы и воспринимаются как лишний шаг. Переведите проверяемое в конвейер сборки, оставив вручную только то, что действительно требует решения человека
После релиза в журнале ошибок найден пароль в открытом виде	Нет проверки, что попадает в журнал, до выкладки. Добавьте правило логирования: явный список полей, которые нельзя писать как есть
Откат не сработал, когда понадобился	План отката не проверялся заранее. Для нетривиальных изменений прогоняйте откат на тестовом окружении до релиза в продуктив
Найдена забытая тестовая учётная запись спустя месяцы	Нет пункта об отключении временных доступов после релиза. Добавьте срок жизни для любого временного доступа, созданного для релиза

Где это в модели зрелости

Материал относится к направлению «Управление изменениями» (материалы направления, карта зрелости). Уровень 2 требует, чтобы изменения проверялись на риск перед применением: для релизов кода это означает отдельный от общей карточки изменения набор технических проверок, так как здесь ошибки специфичны именно для разработки, а не для инфраструктурных изменений.

Как проверить

Статический анализ, проверка зависимостей и сканирование образа подключены к конвейеру и блокируют релиз при критичных находках.
Для каждого релиза с нетривиальным откатом план отката описан и хотя бы раз проверен на тестовом окружении.
После выкладки есть период целенаправленного наблюдения за ошибками и метриками.
Временные доступы и флаги, добавленные для релиза, имеют срок и реально удаляются.